Hi all,
I've got OpenVPN running in bridged mode (with the "--dev tap" and "--server-bridge" options enabled) on a homemade FreeBSD 13.0 router.
When I attempt to ssh TO one of the OpenVPN clients from one of the non-clients inside my LAN, it works and it doesn't.
If the connection originates from BSD-based systems (MacOS, FreeBSD, and FreeNAS) or Win10 systems, I have no problems.
If the system is running a recent Linux kernel, I have problems.
ICMP and UDP work fine but when I sniff a TCP connection attempt from my various Linux machines (Arch, Manjaro, Debian, etc.), I see:
SSH is just one example. It seems any TCP service will exhibit the same behavior, wholly contingent on whether the originating system is running Linux or not.
I would surmise that modern Linuxen verify the MAC addresses of response frames to ensure that they are coming from expected hosts and refuse them if they do not.
It seems to me that the bridge may be misconfigured on the router.
It doesn't make sense to me that my LAN clients should ARP the MAC address of the OpenVPN client (and not the bridge) yet get the MAC address of the bridge (and not the OpenVPN client) when frames are returned.
Is that the correct and expected behavior?
Is there a way to pass through link-layer frames so that the source MAC address remains unaltered?
Or would I want to have OpenVPN alter the ARP table on the router so that the IP address of the OpenVPN client gets associated with the MAC address of the bridge? (I wouldn't think so, but if so, how can I accomplish that?)
The only other option I can think of is to disable the MAC verification feature on each Linux machine in my LAN. I've asked on the ArchLinux Forums how to do this and so far gotten no response.
Do I have any other options?
I've got OpenVPN running in bridged mode (with the "--dev tap" and "--server-bridge" options enabled) on a homemade FreeBSD 13.0 router.
When I attempt to ssh TO one of the OpenVPN clients from one of the non-clients inside my LAN, it works and it doesn't.
If the connection originates from BSD-based systems (MacOS, FreeBSD, and FreeNAS) or Win10 systems, I have no problems.
If the system is running a recent Linux kernel, I have problems.
ICMP and UDP work fine but when I sniff a TCP connection attempt from my various Linux machines (Arch, Manjaro, Debian, etc.), I see:
- A SYN sent to the MAC address of the OpenVPN client's tap interface,
- A SYN+ACK sent from the MAC address of the FreeBSD bridge interface, and
- A RST sent to the MAC address of the OpenVPN client's tap interface.
SSH is just one example. It seems any TCP service will exhibit the same behavior, wholly contingent on whether the originating system is running Linux or not.
I would surmise that modern Linuxen verify the MAC addresses of response frames to ensure that they are coming from expected hosts and refuse them if they do not.
It seems to me that the bridge may be misconfigured on the router.
It doesn't make sense to me that my LAN clients should ARP the MAC address of the OpenVPN client (and not the bridge) yet get the MAC address of the bridge (and not the OpenVPN client) when frames are returned.
Is that the correct and expected behavior?
Is there a way to pass through link-layer frames so that the source MAC address remains unaltered?
Or would I want to have OpenVPN alter the ARP table on the router so that the IP address of the OpenVPN client gets associated with the MAC address of the bridge? (I wouldn't think so, but if so, how can I accomplish that?)
The only other option I can think of is to disable the MAC verification feature on each Linux machine in my LAN. I've asked on the ArchLinux Forums how to do this and so far gotten no response.
Do I have any other options?