TAP mode can loop packets back to the originating client

[marcan]

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.

[marcan]

Tentative patch

[marcan]

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

[marcan]

Hello? Is this thing on?

[Gert Döring]

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)