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
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 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. 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.
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
Simon,
thanks a lot for the hint re outgoing port!
I'm using 460.18 but this is not helpful. What fails is the 1st message from GK to an EP behind NAT.... ouch, I just thought about something... I'm using VCS as external GK and I have a traversal zone on it using Assent ... but then I have 460.18 activated for locally registered endpoints.... hmm, I had priority set to Assent - let me try again. Here is my difficulty, though. The failing connection to the receiving EP is the first Q.931 message. Is is only preceded by an outbound RRQ. RRQ open a pinhole (response arrives!) but then either the pinhole closes or the NAT table entry disappears, or both - no way to find out. How is VCS going to entice NATed EP to open the pinhole again? Looks like catch-22 to me.
Anyway, I will try again and report results.
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 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. 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.
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
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
participants (2)
-
Marek Podgorny -
Simon Horne