testing different OpenVPN options, Bridged tap to local DMZ allows only ICMP but not TCP connections
-
Hi All,
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
https://forum.netgate.com/topic/114098/solved-openvpn-2-4-tap-bridge-problem-access-to-lan -
@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
