Opened 9 years ago
Closed 8 years ago
#642 closed Bug / Defect (fixed)
Disabling network adapter causes packet flood
Reported by: | stipa | Owned by: | stipa |
---|---|---|---|
Priority: | major | Milestone: | release 2.4 |
Component: | Networking | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | Gert Döring |
Description (last modified by )
On certain OSes (Windows, OS X) when network adapter is disabled (ethernet cable pulled off, WiFi? hardware switch disabled), operating system starts to use tun as an external interface. So outgoing packets are routed to tun, UDP encapsulated, given to routing table and sent to.. tun.
As a consequence, thousands of packets are been sent to the twisted nether, traffic counters skyrocket and user is not happy.
As a fix, let's detect packets going to "my current destination tunnel address + port" and drop (+log) them ("recursive routing detected, dropping tun packet to $destination:$port").
Thanks, Lev.
Change History (3)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
comment:3 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Patch v2 was not good, v3 was still not good enough :-) and v4 has been sent, tested and merged!
commit e8c42658ff8df10ad56659788a73900648b9d92d (master)
commit 748974b960a099ef4fdf083f25226659775603b9 (release/2.3)
Author: Lev Stipakov
Date: Thu Nov 3 23:28:23 2016 +0200
Drop recursively routed packets
Acked-by: Gert Doering <gert@…>
Message-Id: <1478208503-25929-1-git-send-email-lstipakov@…>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12894.html
Signed-off-by: Gert Doering <gert@…>
this will be in 2.3.14 - closing the ticket, everything is done.
Just as a side note: it will still not *work* if we drop the packets, but the system won't start talking to itself on full power, but eventually it will find a new default gateway, or openvpn will abort the session (--ping timeout) and try to reconnect.
In any case, easier to see what is happening.
(What we *really* want is the sort of socket fd protection that android has - "packets on this socket are never to be routed inside the VPN"... but that's not going to happen :) )