[Asterisk-bsd] RTP destination address with NAT

[Brian Buhrow]

	Hello.  What SIP phone are you using?  If you're using a Linksys SPA
(formerly Sipura Technologies), then I think you can enable all the nat
detection  code in the phone and have it "just work" through your natted set
up, pf and all.  We do this here on a number of segments, and the only
nod to SIP we make in our pf configurations is to use the static-port
parameter on the nat lines.  The SPA's,  which are inside the natted
environment, punch the necessary holes  through pf for Asterisk to get back
through.  This way, we can run multiple phones behind a single nat, and we
don't even have to plan for a phone to be present  when we set up the
network.
	I've not been able to make this work with Cisco or Polycom phones, so
if you're running those,  I apologize for blathering on uselessly.
	Although I haven't investigated this thoroughly because it's just
worked, I think what happens is that the phone tells asterisk to send rtp
packets to it on its public IP address on a specific port number.  Then, it
generates outbound rtp packets on the same port number destined for the
other end.  When the return packets come back, pf already has a mapping
because the outbound packets from the phone set up the state table
correctly.  I've even seen this work right for phones with reinvite turned
on because , again, the phone generates outbound traffic which sets up pf
for the media traffic.

-Brian

On May 29,  1:22pm, Mike Durian wrote:
} Subject: Re: [Asterisk-bsd] RTP destination address with NAT
} On Thursday 29 May 2008, Adam Vande More wrote:
} > Mike Durian wrote:
} > > Following up to my own post.
} > > When I updated asterisk, I also updated FreeBSD from 6.x to 7.x.
} > > I believe this had a subtle effect on some PF behavior (I know
} > > I had to enable IPSEC_FILTERTUNNEL to get cups to work) and made
} > > the system more sensitive to the asterisk behavior.
} > >
} > > Previous versions of asterisk might have also sent the initial
} > > few RTP packets to the wrong address too, but I just didn't notice.
} > > I do believe that finding a way to prevent asterisk from sending
} > > RTP packets to a destination before it has received one (at least
} > > for NAT peers) will fix my problems.
} > >
} > > If anyone has advice on how to do this, I'd quite appreciate it.
} > >
} > > mike
} >
} > Your firewalling is much more complicated than my setup, however have
} > you checked into sip.conf settings ipaddr and rtpkeepalive?
} >
} > It's been awhile since I set it up, but I believe I had to had in a rule
} > like:
} >
} > set timeout { udp.first 300, udp.single 300, udp.multiple 900 }
} >
} > for pf to keep the port open.  That was at one location, my other
} > location uses ipfw and natd which didn't require any mods I can recall.
} 
} Thanks for the advice Adam.
} I do have a "set timeout" line similar to yours in my pf.conf.  As
} for rtpkeepalive, I believe I'm experiencing the opposite condition.
} My PF state information isn't going away, it is applied to the
} wrong connection (sorta).
} 
} Here's bit more detail on my setup:
} I've got a remote server.  This server runs asterisk in addition to
} a few other server things.  I also have a remote office (more than
} one, but it is one in particular I'm having problems with).
} 
} The remote office has two internet connections.  1) a cable link
} for high rate data traffic, 2) a DSL link for low-jitter traffic.
} I don't use the cable link for VoIP all the time because the cable
} network has flapping routers that wreck havoc with the VoIP traffic.
} I can't use DSL for VoIP all the time either.  The office is so far
} from the CO that I had to beg a field worker to give me DSL.  On
} hot days, the copper stretches so much that I lose DSL entirely.
} It is also only 1.5 DSL line (at the best of times), so I only route
} VoIP traffic over it.  Normal data traffic only goes on the cable
} interface.
} 
} When the DSL is up, it is better for VoIP traffic.  The far end of
} the DSL is on the same local network as our asterisk server and the
} packet jitter is very good.  So I use DSL when I can, but when DSL
} goes down, I flip the VoIP traffic to the cable line (I use net/ifstated
} in conjunction with a PF anchor rule that does source routing).
} The phone has a low registration period so it will reregister over
} the new link quickly enough that there isn't much down time when
} the switch occurs.
} 
} To further complicate things, I've got a VPN between the home office
} and the asterisk server running across the cable link.  It uses
} a gif tunnel and ipsec as described in the FreeBSD handbook.
} 
} Since I want to be able to easily move the phone from the home
} office to some arbitrary field location (while travelling), I don't
} route VoIP through the VPN.  The phone uses the asterisk server's
} routable IP address, not its unroutable VPN address.  It then
} accesses the asterisk server through a NAT interface on either the
} cable or DSL line as required.
} 
} Is anyone still reading?  You must have a high pain threshold.  SIP
} packets on port 5060 always work as expected.  They go through the
} DSL link or the cable link and get their NAT address assigned
} properly.  PF keeps track of the state and I've got solid bidirectional
} SIP connectivity.
} 
} The problem occurs with the RTP packets.  The asterisk server sets
} up a call and starts receiving packets from the PSTN interface.  It
} then starts forwarding these packets to the phone, using the phone's
} real address as listed in the SIP packet (the 192.168.1.10 address).
} These packets gets routed through the VPN interface.  I'm getting
} a bit iffy here, but I believe PF sees the incoming packets and
} creates a state table entry for them between the phone's IP and the
} asterisk server's public address.
} 
} Eventually the phone starts sending its RTP packets.  These go out
} through the appropriate NAT interface.  Once the asterisk server
} receives one of these packets, it detects the phone's NAT address
} and starts sending RTP packets to it.  But now PF is confused and
} the packets don't actually make it to the phone.  I'm not sure
} exactly why, but I think it has to do with state tracking.
} 
} Since my SIP packets work properly, and never go through the VPN
} tunnel, I think I can solve my problem if I can configure asterisk
} to avoid sending packets that will get routed through the tunnel.
} 
} I do admit, it is a bit of conjecture.  Maybe I'm barking up the
} wrong tree.  Perhaps the problem is solely with PF and not with
} asterisk at all.  I did discover I had to enable IPSEC_TUNNELFILTER
} on the asterisk server to get cups to work.  Without that option,
} cupsd could write some data to a printer through the VPN and then
} suddenly get an EPERM error from write(2).  I didn't have to do
} this before I upgraded from 6.x to 7.x  Maybe some related PF oddity
} is messing with my VoIP.
} 
} mike
} 
} 
} _______________________________________________
} --Bandwidth and Colocation Provided by http://www.api-digital.com--
} 
} Asterisk-BSD mailing list
} To UNSUBSCRIBE or update options visit:
}    http://lists.digium.com/mailman/listinfo/asterisk-bsd
>-- End of excerpt from Mike Durian