[Asterisk-bsd] RTP destination address with NAT

[Mike Durian]

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