#18141: UDP and established TCP connections/NAT holes get terminated
----------------------+-----------------------------------------------
Reporter: mravouk | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: kernel | Version: Trunk
Resolution: | Keywords: UDP TCP NAT connection terminated
----------------------+-----------------------------------------------
Comment (by anonymous):
I am getting the same thing and can replicate the experience on any
OpenWRT device.
What happens in a bidirectional UDP audio stream (such as Webex,
GotoMeeting or Zoom) is that the NAT-flushing is barely noticeable on the
outbound audio stream because it just continues on the newly-minted port.
However, the inbound audio stream now takes typically 10 seconds to re-
establish on the new UDP return NAT hole.
On an OpenVPN (UDP) connection, the behaviour is the same, re-establishes
in 10 seconds. At that moment, my data centre VPN end-point suddenly
registers a new remote UDP source port.
On Skype, however, the latest clients disconnect a call immediately when
OpenWRT does its NAT flush. The longest call I've ever had is about 20
minutes.
In short, OpenWRT NAT is very aggressive in NAT cleanups. Other gateways
including Astaro/Sophos also have aggressive NAT cleanup routines, but
none are as bad as OpenWRT is right now.
--
Ticket URL: <https://dev.openwrt.org/ticket/18141#comment:2>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
