[nos-bbs] UDP Port Unreachable - problem found
Bob Tenty
bobtenty at gmail.com
Sun Nov 17 01:33:16 EST 2013
Yes but I mean it in the context that you encapsulate the relevant 44
addresses at both sides.
(in the local lan addresses).
Bob VE3TOK
On 13-11-17 12:08 AM, Michael E Fox - N6MEF wrote:
> We are. But the addresses don't matter since both ends are behind a
> firewall. The addresses could be anything and the problem would be
> the same.
>
> Michael
> N6MEF
>
>
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
> -------- Original message --------
> From: Bob Tenty
> Date:11/16/2013 8:44 PM (GMT-08:00)
> To: nos-bbs at tapr.org
> Subject: Re: [nos-bbs] UDP Port Unreachable - problem found
>
> I don't believe you mentioned about two jnos systems behind the same
> firewall but may be I missed it.
>
> Why are you not using 44 addresses in your axudp link at both sides?
>
> Bob
>
>
> On 13-11-16 09:20 PM, Michael E Fox - N6MEF wrote:
>> No Bob, I'm talking about two JNOS systems behind the same firewall.
>> The firewall has to change the source port of at least the second
>> one on the way out. Otherwise, the destination IP and destination
>> port are all the same on the way back in. I believe I've already
>> mentioned this a couple of times. This is basic firewall connection
>> muxing.
>>
>> Sonicwall happens to change the source port all the time, instead of
>> after the first connection. And it works just fine for everything
>> but JNOS. If JNOS behaved like a normal UDP app, it would work fine,
>> too.
>>
>> The point is that there is simply no reason to require a specific
>> source port. It's just not the way the UDP world works. And doing
>> so renders the system unworkable when placed behind 10s of 1000s of
>> commercial firewalls.
>>
>> The whole point of axudp is so it can be used in situations where
>> axip can't be used. But with this bizarre restriction, it's
>> defeating that purpose.
>>
>> M
>>
>>
>>
>>
>> Sent from my Verizon Wireless 4G LTE smartphone
>>
>>
>> -------- Original message --------
>> From: Bob Tenty
>> Date:11/16/2013 3:38 PM (GMT-08:00)
>> To: TAPR xNOS Mailing List
>> Subject: Re: [nos-bbs] UDP Port Unreachable - problem found
>>
>> 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/20131117/719fdb32/attachment.html>
More information about the nos-bbs
mailing list