<div dir="ltr">Simon,<div><br></div><div>thanks a lot for the hint re outgoing port!</div><div><br></div><div>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.</div>
<div><br></div><div>Anyway, I will try again and report results.</div></div><div class="gmail_extra"><br clear="all"><div><br>Marek Podgorny<div>+1 315 373-6345</div></div>
<br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 4:25 PM, Simon Horne <span dir="ltr"><<a href="mailto:s.horne@spranto.com" target="_blank">s.horne@spranto.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I assume you are using H.460.18/.19 ?<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">To test as you requested<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">H323EndPoint::SetUDPPorts(1718,172x);<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">This will set the first UDP port for RAS to 1719. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Simon</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:h323plus-bounces@lists.packetizer.com" target="_blank">h323plus-bounces@lists.packetizer.com</a> [mailto:<a href="mailto:h323plus-bounces@lists.packetizer.com" target="_blank">h323plus-bounces@lists.packetizer.com</a>] <b>On Behalf Of </b>Marek Podgorny<br>
<b>Sent:</b> 16 November 2013 06:29<br><b>To:</b> <a href="mailto:h323plus@lists.packetizer.com" target="_blank">h323plus@lists.packetizer.com</a><br><b>Subject:</b> [h323plus] SonicWall/Dell wreck of a NAT<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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.<u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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:<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Is it possible to order H323Plus to only use outgoing UDP port 1719 for RAS signalling?<u></u><u></u></p></div><div><div><p class="MsoNormal">
<br>Marek Podgorny<u></u><u></u></p><div><p class="MsoNormal"><a href="tel:%2B1%20315%20373-6345" value="+13153736345" target="_blank">+1 315 373-6345</a><u></u><u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">
<u></u> <u></u></p><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><u></u> <u></u></p></blockquote></div><p class="MsoNormal">
<u></u> <u></u></p></div></div></div></div></blockquote></div><br></div>