[nos-bbs] UDP Port Unreachable - problem found

Bob Tenty bobtenty at gmail.com
Sat Nov 16 18:38:52 EST 2013


Michael,

You are making a thinking error here.

If I make a link to another jnos system the destination ip number is
different.
Also the return route from that second jnos system uses another ip
number as the first jnos system so there is no problem it all.
Even with the same port.  It is the combination of ip number + port.

Those consumer router/firewall boxes are cheaply designed and targeted
for the average Joe customer user needs.
Install dd-wrt in it if available for it and you will be much happier.


73,

Bob VE3TOK






On 13-11-16 12:35 PM, Michael E. Fox - N6MEF wrote:
>
> Yes, Linux leaves the source port alone on the first connection.  But
> that only works for the first JNOS system.  Even a firewall that
> initially leave the source port alone will need to change the source
> port if a second JNOS system exists so it can track connections to two
> different machines.
>
>  
>
> M
>
>  
>
> *From:*nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] *On
> Behalf Of *Bob Tenty
> *Sent:* Friday, November 15, 2013 11:37 PM
> *To:* TAPR xNOS Mailing List
> *Subject:* Re: [nos-bbs] UDP Port Unreachable - problem found
>
>  
>
> Yes, I have seen that with those boxes.  That is why I always replace
> the firmware with linux when possible.
>
> Bob
>
>
> On 13-11-16 01:33 AM, Michael E. Fox - N6MEF wrote:
>
>     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.
>
>      
>
>     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.
>
>      
>
>     Normally, this doesn't matter.  Applications/services listen on a
>     particular port and respond to whatever incoming connections use
>     that **destination** 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.
>
>      
>
>     But when JNOS receives an AXUDP packet, apparently it doesn't
>     behave like a normal UDP application.  JNOS apparently rejects the
>     connection if the **source** 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.
>
>      
>
>     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.
>
>      
>
>     Michael
>
>     N6MEF
>
>      
>
>
>
>
>     _______________________________________________
>
>     nos-bbs mailing list
>
>     nos-bbs at tapr.org <mailto:nos-bbs at tapr.org>
>
>     http://www.tapr.org/mailman/listinfo/nos-bbs
>
>  
>
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> http://www.tapr.org/mailman/listinfo/nos-bbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20131116/8f953b7e/attachment.html>


More information about the nos-bbs mailing list