Nope, that's the protocol handler trick I mentioned I already tried. Didn't work. But thanks for the link; I appreciate the effort.
ghost16825
· 10 months ago
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?
RafalWeglarz
· 10 months ago
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 :)
RafalWeglarz
· 10 months ago
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 ;)
Daniel Miessler
· 10 months ago
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.
Augusto Paes de Barros
· 10 months ago
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.
Daniel Miessler
· 10 months ago
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?
TabTwo
· 10 months ago
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?
All Comments
maybe this will help
http://blog.sekiur.com/2008/12/checkpoint-firew...
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?
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 :)
Besides it seems that VOIP is broken in the first place ;)
For some stuff like this one, Check Point should have more granular controls, like UDP virtual session timeouts per protocol and/or rule.
Any additional ideas?
Why should a NAT-device user the same source port? What if a second connection uses the same?