<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I found the problem with the UDP port 93 unreachable message:  JNOS is (incorrectly) requiring the source port to also be 93 in AXUDP connections.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>When I connect outbound from my JNOS system, through my firewall, the firewall is changing the source port when it performs the outbound NAT.  But this is normal for a firewall.  In fact, it HAS to do this if it’s going to allow for multiple connects of the same protocol from different machines.  Many consumer-grade firewalls will leave the source port alone for the first connection (if it’s not already in use) and only change it for subsequent connections.  SonicWall is a bit more strict, frequently changing the source port, making it harder for intercepted packets to be tracked to any one machine.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Normally, this doesn’t matter.  Applications/services listen on a particular port and respond to whatever incoming connections use that *<b>destination</b>* port.  They don’t care what the source port is.  Firewalls then use different source ports to track multiple conversations so that when the packets return, all addressed to the same external NAT address, it can direct them to the proper place by the port number.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But when JNOS receives an AXUDP packet, apparently it doesn’t behave like a normal UDP application.  JNOS apparently rejects the connection if the *<b>source</b>* port is not 93, even if the destination port is correctly set to 93.  This is unusual, to say the least.  But even worse, it issues an ICMP “udp port 93 unreachable” message which is completely wrong, since port 93 is definitely reachable.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It seems the following is needed:  Remove the source port restriction for AXUDP.  JNOS should not care what the source port is.  And, just like any other UDP app, when responding it should use whatever source port was specified as the destination port when it constructs the return packet.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Michael<o:p></o:p></p><p class=MsoNormal>N6MEF<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>