• Hello everyone.
    Got a question about VLANs over L2 OVPN tunnel for home setup.
    I have two separate locations with pfsense boxes in each. Both run pfSense 2.4.5-RELEASE-p1.
    This how my network looks like:
    network 2f init.png
    I have used a this guide as a baseline. I did not introduce custom firewall rules and vlans yet.
    Two locations have separate ISPs and gateways to the internet. There is an OpenVpn layer 2 tunnel between two pfSense boxes. One is a host, another is a client. Each location has its own dhcp, dns and etc.

    I managed to connect two subnets together (a dotted rectangle across two locations) so I can access some devices across locations including pfSense boxes.

    Now, since both WiFi access points supports multiple SSIDs with VLAN tags I want to pass VLANs over OpenVPN tunnel, so it would look like a direct tunnel to another location (including DHCP, DNS and all traffic). For example:
    network 2f vlans.png
    VLAN 1002 from Yellow Access point leads directly to the Red location, while VLAN 1021 from Red access point goes to the yellow one.

    Given that there is Layer 2 tunnel, I guess it's theoretically possible? If yes, is there any guide for this?

    Thank you

  • @ncat

    My understanding is OpenVPN doesn't support VLANs. However, I have no experience with that.

  • Minimum OpenVPN version 2.5 is required.
    Take a look at


    In manual 2.5:

  • @pippin Thanks, looks like I have to wait for pfSense 2.5 official release.

  • Just curious... what problem are you trying to address with this setup?

  • @marvosa
    I want to setup a separate SSID which will allow me to connect to another location directly, use its DHCP, DNS and etc.
    Imagine, in my Yellow location I have "RED" SSID with 1002 vlan. When I connect to it, all frames go to the pfSense in Red location and are processed according to the Red location rules.
    Not sure if it is possible and what the performance would be with L2 tunnel.
    Another option would be picking up 1002 vlan in yellow location and redirecting all traffic to the red, but that would be layer 3 filtering as far as I understood.

  • @ncat
    I understand what you want to do, but the solution you're suggesting will add unnecessary complexity.

    If you want certain devices in the yellow location to use the rules from the red location, then just route the traffic over there.

    What I would do:

    • Re-configure your bridged tunnel into a routed tunnel
    • Create a separate VLAN for the devices you want using rules from the remote location
    • Create a separate SSID and tag the VLAN you just created
    • Policy route traffic sourced from this VLAN over the tunnel to the remote end
    • If you want these devices using DNS from the remote end, just have the local DHCP server for this subnet assign DNS servers from the remote end

    This would be a cleaner setup IMO. Also, the routed tunnel will give you better performance over a bridged solution.

  • @marvosa thanks for the suggestion. Already tried implementing that.
    The only issue I got is DHCP. Is it possible to use DHCP of Red location with this solution? That's why I decided to try L2 tunnel.

  • @marvosa thanks for the suggestion. Already tried implementing that.

    The only issue I got is DHCP. Is it possible to use DHCP of Red location with this solution? That's why I decided to try L2 tunnel.

    This sort of builds no my previous question... What issue are you trying to address by using a DHCP server that's across a VPN tunnel? I mean, if you're using Cisco switches you could just add an ip-helper-address to send the requests anywhere you want, but it'd be interesting to hear why you're looking to do that instead of leveraging a local DHCP server.

  • @marvosa
    reg DHCP: some routing rules based on IPs and subnetworks currently exist. So, placing a known MAC device within existing DHCP pool range gives some convenience.

  • @ncat
    I understand the convenience factor, however, instead of adding complexity, you could also address those issues by adding the appropriate routes as needed.

    I have yet to hear anything that couldn't be addressed with a routed solution.