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 ( 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 (dhcp)
    DMZ has IP (static)
    LAN has IP (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 (those are free)

    If I connect to this OpenVPN server through the public IP it works and OpenVPN assigns me 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, I can ping to and from any other client on that subnet.
    I can't open any TCP connection to any server on 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 which is also the default gateway for 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?

  • LAYER 8

    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.

  • LAYER 8

    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

Log in to reply