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