Opened 3 years ago

Last modified 2 years ago

#2467 accepted defect

Do not use isValidPort() on inbound connections

Reported by: jogger Owned by: zzz
Priority: major Milestone: 0.9.43
Component: router/transport Version: 0.9.39
Keywords: Cc:
Parent Tickets: Sensitive: no


My traffic just broke down and I saw 100s of log messages like

ERROR [ Establisher] ter.transport.udp.UDPTransport: The router [Hash: aQJqcFiwno-Evv~AhP6XgEw7ZAi8WX5IWaE5Vu8FSeY=] told us we have an invalid IP - my.ip.add.ress:reservedport. Lets throw tomatoes at them

UDP packet pusher CPU was near zero.

Root cause is that I am sitting behind NAT and my router accidentally chose a port reserved by i2p for outgoing UDP. Since most users simply can not change their routers behaviour, this check has to be removed.

Workaround if you run one of those beautiful $49 EdgeRouters? (highly recommended):
Set NAT protocols for the default rule to TCP/UDP only and then use the command line to "set service nat rule 5010 outside-address port 40000-50000"

After committing the workaround SSU peer count and UDP packet pusher CPU went up immediately.


Change History (4)

comment:1 Changed 3 years ago by zzz

what port did it choose?

comment:2 Changed 3 years ago by zzz

first report we've ever gotten on this, been like this for years, I assume most firewalls pick a high port value by default, or else this would have happened lots of times and been reported.

comment:3 Changed 3 years ago by jogger

My router picked one in the 76xx range.

RFC 2663 does not give details about valid port numbers. Wikipedia says "router picks any free port", so it indeed appears that use of isValidPort() leads to blocking valid connections in this case.

The fact that this was not reported before can be attributed to the fact that this is highly implementation dependent. If it infrequently appears in the logs, no one cares. In my case the router reused the very same port again and again. Others may behave differently.

The code used by Ubiquity (Vyatta code base) certainly is used by other vendors too as it it based on Debian.

comment:4 Changed 2 years ago by zzz

Milestone: undecided0.9.43
Sensitive: unset
Status: newaccepted

Using the IANA guidance from to recommend 49152-65535.
Will stop marking the outbound as unreachable and will log the recommendation. Will not change the inbound check yet, not sure if necessary. Leaving open for now.

In d0cbec576ab2c9741a858d8cf89cf1e52b4ec03f to be 0.9.42-3

Note: See TracTickets for help on using tickets.