Why a Shared TAP VPN Still Needs HTTPS on the Portal
A TAP VPN authenticates the peer, not the service behind it. Keep hostname validation on the portal and isolate neighbours you do not trust.
Two devices hold valid VPN credentials and share one bridged Ethernet segment. Only one of them is supposed to answer for the office portal, and the other can still claim the portal address on that segment. The tunnel did its job: it authenticated both peers and encrypted each path to the server. What it did not do is certify which of them owns a service name, and that gap is why the portal still needs a valid certificate.
What the VPN actually authenticates
A VPN handshake answers one question: which peer completed this tunnel, with which key material. That answer is per peer and per connection, and it says nothing about the services that peer exposes afterwards. On a TAP segment the peer is not even a single address, because it can present any MAC and any IP the bridge is willing to learn. Authentication stops at the tunnel endpoint, not at the application.
Separate the three questions instead of collapsing them into one. Each has its own mechanism and its own failure mode.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
A deployment can have a perfectly authenticated tunnel and a completely unauthenticated service behind it. It can also have a validated certificate on a host whose layer-two address is being claimed by another peer, which is why both controls belong in the design rather than one replacing the other. The table is the whole argument in three rows.
ARP on a shared segment is not a directory
ARP maps an IPv4 address to a MAC on the local link and accepts replies from anyone on that link. On a permissive bridged segment a peer can claim an address that belongs to another device, and the bridge forwards frames to whoever answered most recently. Encrypting each client path to the server does not change that, because frames are decrypted before they reach the bridge. The trust boundary of ARP is the segment, not the tunnel.
Look at what the host actually learned: ip neigh show lists current mappings and their state, and an entry that flips between two MAC addresses during normal operation is a symptom worth investigating rather than dismissing. On a healthy small segment those entries stay stable for long periods.
Peer isolation and bridge policy exist for exactly this case. A routed design is usually the better answer when the service is IP-only and the devices have no reason to see each other frames at all.
Keep certificate validation where the service is
Application TLS answers the question the tunnel cannot: is this the service I intended to reach. The browser checks the hostname against the certificate, and that check is the only part of the chain that names the portal rather than the peer.
Inspect what the server presents before deciding the warning is cosmetic. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal prints the chain and the subject alternative names. If the name you typed is absent from that list, the warning is correct and the certificate is what needs fixing. Teaching users to click through it turns a working control into decoration.
The OpenVPN bridging guide describes the Ethernet model and the policy options around it, and it is the right reference for what the segment is meant to permit. Read it before loosening a bridge rule, because the model it describes is what every check above assumes.
Decide whether those peers should share a segment at all
The cheapest fix is usually to stop sharing layer two when the requirement is only IP reachability. A routed VPN gives each client its own address, removes the shared broadcast domain, and turns peer-to-peer traffic into a policy decision instead of a default. The portal then has one address to protect and no neighbours that can claim it.
If the segment has to stay, check the server-side setting that lets clients reach each other: grep -n client-to-client /etc/openvpn/server.conf. With it disabled, client traffic passes through the server and can be filtered there. With it enabled, peers exchange frames directly through the bridge and your filtering points are the bridge and the host firewall.
Write down which protections each host actually relies on: tunnel authentication, segment isolation, or application TLS. A host that depends on all three is fine. A host that depends on the first and assumes the other two came with it is the one that ends up serving the wrong content.