testing different OpenVPN options, Bridged tap to local DMZ allows only ICMP but not TCP connections
I'm trying to learn more about different VPN options, especially complex setups.
I'm now testing bridging an OpenVPN to a DMZ.
this is all happening in a lab environment.
the lab pfsense has three interfaces, a WAN getting a DHCP directly from an internet facing router, no public IP tho on this interface (and none can be added, basically it's there just as a placeholder and for future tests), a DMZ which is effectively a WAN because it has a default gateway set to an upstream firewall (192.168.2.254) that has a public IP address and forwards some ports from that public IP to the pfsense in the lab. it also has a LAN interface which sits on our internal LAN.
WAN has IP 192.168.1.12 (dhcp)
DMZ has IP 192.168.2.16 (static)
LAN has IP 192.168.0.160 (static)
I made an OpenVPN server (tls/ssl+user auth) listening on DMZ on a port forwarded from the upstream firewall to the pfsense box DMZ IP, tap interface, bridged to DMZ (the OpenVPN interface has been assigned and bridged to DMZ), DHCP-server range is 192.168.2.161-192.168.2.162 (those are free)
If I connect to this OpenVPN server through the public IP it works and OpenVPN assigns me 192.168.2.161 as expected,adds the correct routes to the OpenVPN client, I can tcpdump from the OpenVPN client and see all ARP and broadcast packets across 192.168.2.0/24, I can ping to and from any other client on that subnet.
I can't open any TCP connection to any server on 192.168.2.0/24 tho, I have very open firewall rules, basically allowing any to any (protocols, IP, gateways, anything) on LAN/DMZ/OPENVPN_IFACE/OpenVPN.
why is this behavior happening?
I thougt the culprit was having a DHCP server on 192.168.2.1 which is also the default gateway for 192.168.2.0/24 clients, the thing is if I manually setup clients on .2.x to use either the pfsense box or the upstream firewall as default gateway I can ping them either way but I can't open any TCP connection to them.
what am I missing here?
i don't think that bridging is the right way to do it, usually routing is the suggested way to go for vpn, use of tun is almost always a better choice.
is it a virtual machine ?
@kiokoman I know and agree, but this is a lab and I'm trying all possible setups, including bridging with a tap, there are situations in which you need broadcast packets or you want to see the MAC address of the VPN clients, rare enough but they exists.
I find it really odd that I can tcpdump from the client and see the traffic on .2.x, ICMP are getting through but no TCP connections can be established over the tunnel.
yes it's a VM, running on KVM.
uhm maybe search the forum for possible solution, this one is for esxi idk if you need to do something similar for KVM
@kiokoman thanks for the tip, I have configured a bridge with linux tools (brctl) and I'm using virt-io and I thought that would be enough but it is in fact very reasonable that it would actually introduce limitations and weird behaviors like what I'm seeing, I will dig further the issue