Opened 15 months ago

Last modified 5 months ago

#931 accepted Bug / Defect

TAP mode can loop packets back to the originating client

Reported by: marcan Owned by: Gert Döring
Priority: major Milestone:
Component: Networking Version: OpenVPN 2.4.3 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Antonio

Description

In TAP mode with client-to-client enabled, if the server learns a MAC address as being at client A and then client A sends a packet with that MAC address as a destination, the packet is routed back to client A. This is wrong and not what real switches do. It causes issues as the packet bounces back and corrupts other switches' learning tables. If two OpenVPN clients are involved, it could also cause an infinite switching loop.

This can be reproduced by setting up a TAP server with --server-bridge --client-to-client, and a client with --dev tap-cli, and then running the following two Python one-liners on the client (requires scapy):

# python2 -c 'from scapy.all import *; sendp(Ether(dst="00:00:00:00:01:aa",src="00:00:00:00:01:bb",type=0xaaaa)/"test", iface="tap-cli")'
# python2 -c 'from scapy.all import *; sendp(Ether(dst="00:00:00:00:01:bb",src="00:00:00:00:01:aa",type=0xaaaa)/"test", iface="tap-cli")'

The first packet causes OpenVPN to learn 00:00:00:00:01:bb for the client. The second one shows up twice in a tcpdump of tap-cli: the OpenVPN server resolves the 00:00:00:00:01:bb destination to the same client and loops it back. Doing this test on a real switch (or a linux bridge) does not yield the same behavior, which is expected, as normal switches never "hairpin" packets back to their source.

This issue is particularly insidious because it randomly breaks connectivity between hosts which are on the same physical switch (not across the VPN link) just because an OpenVPN client TAP is also bridged to the same network. If Host A sends a packet to Host B and the real switch's MAC table entry for Host B has expired, it floods the packet to Host C which bridges it to OpenVPN, it gets looped back, and now the physical switch thinks Host A's MAC address lives on Host C's port and things break until Host A decides to talk again.

Attachments (1)

openvpn-2.4.3-tap-loopback-fix.patch (773 bytes) - added by marcan 15 months ago.
Tentative patch

Download all attachments as: .zip

Change History (4)

Changed 15 months ago by marcan

Tentative patch

comment:1 Changed 13 months ago by marcan

Ping? Has anyone taken a look at this issue and the patch?

comment:2 Changed 9 months ago by marcan

Hello? Is this thing on?

comment:3 Changed 5 months ago by Gert Döring

Cc: Antonio added
Owner: set to Gert Döring
Status: newaccepted

Sorry. This "thing" was on, but everybody was busy breaking and fixing other stuff so it got overlooked.

This is related to #626 and both need fixing. Maybe it's also the root cause of #1070 (waiting for logs on that one, but it smells related)

Note: See TracTickets for help on using tickets.