Marek Podgorny +1 315 373-6345
On Fri, Nov 15, 2013 at 4:25 PM, Simon Horne s.horne@spranto.com wrote:
I assume you are using H.460.18/.19 ?
The fact it is letting 1719 through indicates the firewall might be doing deep packet inspection. If so this might indicate that an ALG might be in play.
I'm quite sure there is no DPI on SonicWall. My guess is that checking the "H323 support" box modifies the treatment of few well-known ports for NAT.
I suggest you check when registering the IP address used to register with the gatekeeper. Basically check the RRQ from the NATed endpoint with the RRQ received at the gatekeeper and make sure the IP addresses match.
I did. They match, but this does not mean - to me - that there is an active ALG in play. This is just the basic NAT - gatekeeper only sees FW WAN IP.
On the 2nd thought though, here is what I see:
Call signaling address 209.217.218.37:30842 RAS address 209.217.218.37:4096 Apparent RAS address 209.217.218.37:4096
I never got to the bottom of the probably deep significance of these 3 addresses.
If an ALG is in play then the addresses get changed on the way through from
internal to external addresses. If that is the case then simply turn off H.460.18/.19 in the endpoint behind the NAT and let the ALG do what is maybe is supposed to do. (I have low confidence in ALGs) . The other alternative is to try to turn off the ALG and deep packet inspection in the firewall off.
I tried to latter to no effect but didn't think of the former.
I hate SonicWall. My $100 SOHO router handles all this w/o a hitch.
To test as you requested
H323EndPoint::SetUDPPorts(1718,172x);
This will set the first UDP port for RAS to 1719.
Simon
*From:* h323plus-bounces@lists.packetizer.com [mailto: h323plus-bounces@lists.packetizer.com] *On Behalf Of *Marek Podgorny *Sent:* 16 November 2013 06:29 *To:* h323plus@lists.packetizer.com *Subject:* [h323plus] SonicWall/Dell wreck of a NAT
I have a problem with firewall that I cannot replace or reconfigure. The FW is a SonicWall, public IP on Internet side (of course), NAT on the LAN side, gatekeeper on a public address outside FW. Calls from EPs on NAT to outside world work but incoming calls fail. I wiresharked the traffic and found that the Q.931 setup ServiceControlIndication packet bounces from the FW. The reason for this is that while this particular packet is sent to UDP port previously used by the NATed EP RRQ, the FW fails to preserve NAT mapping table. SonicWall also ignores port preservation setting.
Astonishingly, bi-directional access to UDP port 1719 works (SonicWall claims to support H.323 and it is possible to "activate" it. Maybe port 1719 becomes special). Therefore, here is my question:
Is it possible to order H323Plus to only use outgoing UDP port 1719 for RAS signalling?
Marek Podgorny
+1 315 373-6345