dmiessler.com | grep understanding - Latest Comments in Problems with Check Point, NAT, and SIP

Re: Problems with Check Point, NAT, and SIP

TabTwo — Sat, 21 Feb 2009 15:53:03 -0000

The basic issue here: SIP just sucks with NAT

Why should a NAT-device user the same source port? What if a second connection uses the same?

Re: Problems with Check Point, NAT, and SIP

Daniel Miessler — Wed, 18 Feb 2009 14:00:12 -0000

Ok, I tried this and it looks like it's solved a good portion of my problem, but not all of it. I am now able to receive calls more often, but it's still inconsistent. For some reason Check Point is still having trouble with some of the incoming high-numbered UDP connections (even though it was Check Point that gave the provider that port).

Any additional ideas?

Re: Problems with Check Point, NAT, and SIP

Daniel Miessler — Wed, 18 Feb 2009 12:59:56 -0000

The problem isn't the incoming port mapping; it's the outgoing SIP connection coming from the Asterisk system. The Check Point system doesn't give the packets back to port 5060 on the Asterisk box (the original source port); instead it gives it to the Asterisk box as the high level port IT created, which of course isn't accepting traffic--hence the ICMP unreachables.

Re: Problems with Check Point, NAT, and SIP

RafalWeglarz — Wed, 18 Feb 2009 11:42:13 -0000

I think I get the problem now ;). I'm not the VOIP guy, but isn't there any setting in Asterisk that says how external servers should reach it? So that you could do a mapping of extip:port->intip:port?
Besides it seems that VOIP is broken in the first place ;)

Re: Problems with Check Point, NAT, and SIP

Augusto Paes de Barros — Wed, 18 Feb 2009 11:32:29 -0000

It should be handled by the "UDP virtual session" concept. The problem would be if the interval between UDP packets is too big, as the firewall will clean the state tables and will not understand the incoming packet as part of a previous "virtual session". If the communication is something regular it can be solved by increasing the UDP virtual session timeout, but if the packet flow is not constant (i.e. there are long time intervals between each UDP packet) it won't help at all.

For some stuff like this one, Check Point should have more granular controls, like UDP virtual session timeouts per protocol and/or rule.

Re: Problems with Check Point, NAT, and SIP

RafalWeglarz — Wed, 18 Feb 2009 09:30:19 -0000

Hi,
I have tested it. And although CheckPoint does change the source port, it does properly handle messages coming back. It properly changes the ports.
You mentioned that it is during the initial phase. If it not be during initial phase than I would guest that the problem might be that the UDP session times out. But it should be alive for at least 40 seconds (which is default). Could you provide me with pcap dumps? I do not want to install the whole asterisk thing :)

Re: Problems with Check Point, NAT, and SIP

ghost16825 — Wed, 18 Feb 2009 08:31:02 -0000

Er....are you serious?
So you mean you can't create an inbound port forwarding rule? (which on most devices implies that the outbound source ports will be preserved)
Also are you sure the device doesn't have any SIP Application Layer Gateway functionality enabled?

Re: Problems with Check Point, NAT, and SIP

Daniel Miessler — Wed, 18 Feb 2009 07:19:11 -0000

Nope, that's the protocol handler trick I mentioned I already tried. Didn't work. But thanks for the link; I appreciate the effort.

Re: Problems with Check Point, NAT, and SIP

RafalWeglarz — Wed, 18 Feb 2009 03:27:16 -0000

Hi,
maybe this will help
http://blog.sekiur.com/2008...

Re: Problems with Check Point, NAT, and SIP

Daniel Miessler — Wed, 18 Feb 2009 00:15:35 -0000

Hopefully I missed something. If anyone knows a solution for this I'd love to hear about it.