Possible NAT problem with SIP softphones on Tiger Server

[rcrcr]

On one particular site with an XServe (10.4.4 Server),

the XServe is acting as the DHCP server and NAT gateway for the LAN.

en0 is the WAN interface on a public IP.
en1 is the LAN interface on a private IP.

Everything works fine in that clients pull private IPs from the XServe’s DHCP service, and the
XServe routes their internet traffic over its NAT service.

All client services seem to work fine over NAT except for VoIP (SIP) softphones. Specifically,
outbound packets reach the destination, but inbound packets make it to the XServe, but not to the
clients.

The traffic is UDP and the ports vary, but range between 10000 and 30000 or so.

These softphones work fine over a cheapo Linksys NAT router in a test scenario, so I know this
traffic can work over NAT. It just doesn’t seem to work with the XServe as the NAT gateway.

Here is a tcpdump sample from en0 (the public interface) showing that this traffic flows fine in
both directions through the public interface:

17:47:25.378382 IP 64.81.XXX.XXX.31198 > voip-gw01. XXX.com.19254: UDP, length: 172
17:47:25.394576 IP voip-gw01.XXX.com.19254 > 64.81.XXX.XXX.31198: UDP, length: 172
17:47:25.394772 IP 64.81.XXX.XXX.31198 > voip-gw01. XXX.com.19254: UDP, length: 172
17:47:25.408629 IP voip-gw01.XXX.com.19254 > 64.81.XXX.XXX.31198: UDP, length: 172
17:47:25.414760 IP 64.81.XXX.XXX.31198 > voip-gw01. XXX.com.19254: UDP, length: 172
17:47:25.428987 IP voip-gw01.XXX.com.19254 > 64.81.XXX.XXX.31198: UDP, length: 172
17:47:25.434096 IP 64.81.XXX.XXX.31198 > voip-gw01. XXX.com.19254: UDP, length: 172
17:47:25.449744 IP voip-gw01.XXX.com.19254 > 64.81.XXX.XXX.31198: UDP, length: 172

And a tcpdump sample from en1 (the private interface) showing that only the outbound traffic is
passing over this interface:

17:45:43.692905 IP computer-137.XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172
17:45:43.713033 IP computer-137.XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172
17:45:43.732973 IP computer-137 XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172
17:45:43.752985 IP computer-137.XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172
17:45:43.772918 IP computer-137.XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172
17:45:43.792946 IP computer-137.XXX.private.31190 > voip-gw01.XXX.com.10854: UDP, length:
172

And by the way, ipfw rules are pretty non-restrictive. All outbound traffic from en1 is allowed to
pass, and that is all that should be needed for these softphones to work.

Are there some natd/ipfw issues in Tiger Server of which I should be aware? Is there any natd
tweaking I might need to do? Does anyone have any ideas on this?

Thanks.

[rcrcr]

[QUOTE BY= macshome] By default all incoming UDP is blocked by ipfw, but it should allow incoming replies to your requests because of the default keep-state rule.

What’s a sudo ipfw show spit out on your server?[/QUOTE]

Great question. I could have sworn that I didn’t see a problem in the ipfw logs, which is why I was honing in on natd as the problem, but sure enough, last night I discovered this:

Feb 7 18:28:29 nyc-server ipfw: 12341 Accept UDP 10.200.1.137:31134 63.116.XXX.XXX:10658 in via en1
Feb 7 18:28:29 nyc-server ipfw: 65534 Deny UDP 63.116.XXX.XXX:10658 10.200.1.137:31134 in via en0
Feb 7 18:28:29 nyc-server ipfw: 12341 Accept UDP 10.200.1.137:31134 63.116.216.15:10658 in via en1
Feb 7 18:28:29 nyc-server ipfw: 65534 Deny UDP 63.116.XXX.XXX:10658 10.200.1.137:31134 in via en0
Feb 7 18:28:29 nyc-server ipfw: 12341 Accept UDP 10.200.1.137:31134 63.116.XXX.XXX:10658 in via en1
Feb 7 18:28:29 nyc-server ipfw: 65534 Deny UDP 63.116.XXX.XXX:10658 10.200.1.137:31134 in via en0
Feb 7 18:28:29 nyc-server ipfw: 12341 Accept UDP 10.200.1.137:31134 63.116.XXX.XXX:10658 in via en1
Feb 7 18:28:29 nyc-server ipfw: 65534 Deny UDP 63.116.XXX.XXX:10658 10.200.1.137:31134 in via en0
Feb 7 18:28:29 nyc-server ipfw: 12341 Accept UDP 10.200.1.137:31134 63.116.XXX.XXX:10658 in via en1
Feb 7 18:28:29 nyc-server ipfw: 65534 Deny UDP 63.116.XXX.XXX:10658 10.200.1.137:31134 in via en0

So it looks like ipfw is indeed denying the inbound traffic.

Confusing thing is, the following rule is in place:

12303 allow log logamount 1000 udp from any to any out keep-state

So… why is this happening? Any idea how I might fix it?

rcrcr

[rcrcr]

Following up on my previous post,

it looks like the outbound packets are being accepted not by rule 12303, but instead by rule 12341:

12341 allow log logamount 1000 ip from 10.200.0.0/22 to any

…which was put in place by Server Admin, and does not have a keep-state. So it seems to me (can you confirm?) that since the outbound traffic is being accepted by 12341 instead of 12303, the state is not being kept and that’s why the inbound UDP in this case is being denied.

If all that’s true, a followup question would be this:

Why is 12341 taking precedence over 12303, which comes before it in the rule list?

rcrcr

[haxie]

Were you ever able to resolve this issue?

I am having similar issues with my Tiger server and some VoIP hardware on my internal network. When I allow all traffic through the firewall the VoIP talks fine with the SIP server and I can process my audio and video calls just fine. When I only allow the traffic I want through the firewall that communication fails.

I have UDP Port 5060 open as per the devices documentation and UDP ports 10000 – 20000 as per customer supports help desk advice, but still no dice. If I disable the last advanced rule 65341 (it think) communication then works again, so I am pretty confused. i have opened these ports up, which I am assuming should allow access through the firewall, but for some reason this last rule keeps being used.

Does anyone have any suggestions as to what I am doing wrong here?

thx,

haxie

[Author]

Posts