I recently updated asterisk from the FrssBSD ports collection to
1.4.19.2. I've been trying to track down some strange routing
interaction with the RTP packets from my asterisk server, which is
not behind a NAT, to my phone, which is behind a NAT. I also have
a bunch of funky pf routing rules to route the phone traffic over
a cable line or a DSL line depending on some conditions. My routing
rules used to work, but now they fail after the update. I think
the problem might be related to the IP address used by asterisk
when sending RTP packets to my phone.

Despite having nat=yes enabled for my phone peer, asterisk is using
it's unroutable address (192.168.1.10) for the first few packets
it sends to the phone. I verified this by turning on rtp debug.
Only after asterisk receives an RTP packet from the phone, does it
switch to using the NAT address. I won't get into the messy details
(partly because I don't fully understand all the interactions), but
I believe the first few RTP packets to the 192.168 address are
causing routing problems for me.

All that said, my question is rather simple. How do I keep
asterisk from sending out any RTP packets until it receives one?
If I can prevent asterisk from sending RTP packets until it learns
the NAT address by receiving one, I think I can solve my problems.

I recently updated asterisk from the FrssBSD ports collection to
1.4.19.2. I've been trying to track down some strange routing
interaction with the RTP packets from my asterisk server, which is
not behind a NAT, to my phone, which is behind a NAT. I also have
a bunch of funky pf routing rules to route the phone traffic over
a cable line or a DSL line depending on some conditions. My routing
rules used to work, but now they fail after the update. I think
the problem might be related to the IP address used by asterisk
when sending RTP packets to my phone.

Despite having nat=yes enabled for my phone peer, asterisk is using
it's unroutable address (192.168.1.10) for the first few packets
it sends to the phone. I verified this by turning on rtp debug.
Only after asterisk receives an RTP packet from the phone, does it
switch to using the NAT address. I won't get into the messy details
(partly because I don't fully understand all the interactions), but
I believe the first few RTP packets to the 192.168 address are
causing routing problems for me.

All that said, my question is rather simple. How do I keep
asterisk from sending out any RTP packets until it receives one?
If I can prevent asterisk from sending RTP packets until it learns
the NAT address by receiving one, I think I can solve my problems.

Thanks,
mike

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.

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.

Just so you know I have done extensive testing on fbsd 7.0 and find itis till
not up to par. Asterisk on fbsd 7.0 seems to have issues and I went back to
6.3 and asterisk and the issues went away.

I am now working to do more testing. once I can find all the issues and
outline them then we can work to fix them.

On Thursday 29 May 2008 12:28:54 Adam Vande More wrote:

Quote:

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.

Richard Neese wrote:
> Just so you know I have done extensive testing on fbsd 7.0 and find itis till
> not up to par. Asterisk on fbsd 7.0 seems to have issues and I went back to
> 6.3 and asterisk and the issues went away.
>
> I am now working to do more testing. once I can find all the issues and
> outline them then we can work to fix them.

Dear Richard,

What kind of problems you have encountered with Asterisk on FreeBSD 7.0?
I'm planning to upgrade some servers to it and would like to test for
these issues you've mentioned before I do so.

Actually, I already have a test box running 7.0 with the latest Asterisk
1.4 installed from ports, been running without issues for 2 weeks.

Regards,
Vahan

I have also been running FreeBSD 7.0 (i386) with asterisk-1.4.18.1_1
and it has worked flawlessly.

I will build a list . I have been testing 1.6 and it has had the issues.

including compile issues and performance issues.

On Thursday 29 May 2008 13:37:43 Marc Smith wrote:

Quote:

On Thu, May 29, 2008 at 1:30 PM, Vahan Yerkanian <vahan@arminco.com> wrote:
> Richard Neese wrote:
>> Just so you know I have done extensive testing on fbsd 7.0 and find itis
>> till not up to par. Asterisk on fbsd 7.0 seems to have issues and I went
>> back to 6.3 and asterisk and the issues went away.
>>
>> I am now working to do more testing. once I can find all the issues and
>> outline them then we can work to fix them.
>
> Dear Richard,
>
> What kind of problems you have encountered with Asterisk on FreeBSD 7.0?
> I'm planning to upgrade some servers to it and would like to test for
> these issues you've mentioned before I do so.
>
> Actually, I already have a test box running 7.0 with the latest Asterisk
> 1.4 installed from ports, been running without issues for 2 weeks.
>
> Regards,
> Vahan

I have also been running FreeBSD 7.0 (i386) with asterisk-1.4.18.1_1
and it has worked flawlessly.

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.

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