Howto: Bridged L2 VPN without "tunnel network" / Control over "server"directive

  • How to ignore the "Tunnel network" field and use your own "server …" command, for creating true TAP bridges.

    In pfSense 2.0, the way the web configurator handles tap-interfaces is a bit wonky. You should be able to not fill in a tunnel network; making a true layer 2 interface (You still got to bridge the interfaces, ofcourse)

    By following this guide, you will edit two configuration files. After that, the "server [ip address] [subnet]" directive won't be written out in the config file, as well as the "tunnel network" not being parsed. You can add your own directives in the additional configuration field.

    I'm not responsible for bricked systems, by the way :-)

    You might want to use the nifty Diagnostics -> Edit file for this.

    First, edit /usr/local/www/vpn_openvpn_server.php. I have commented out the following three lines (Placed the // in front of them):

    // $reqdfields[] = 'tunnel_network';
    // $reqdfieldsn[] = gettext('Tunnel network');
    // do_input_validation($_POST, $reqdfields, $reqdfieldsn, &$input_errors);

    Good. The field can be kept empty now. You might want to change the text underneath it to remind yourself of the modifications. Search for a snippet of it (Let's say "hosts expressed using CIDR") and change it to something. I did the following:

    Use caution! You need the advanced configuration to define your network settings (e.g. mode server), The VPN will not work when you don't do so. -Jarpse"); ?>

    Normally, the system would write out something like this in the configuration file (say, /var/etc/openvpn/server1.conf):
    server (Whatever you have configured :-))

    When you modify the script to ignore the "tunnel network" input, it would write out:

    Not exactly what we want, since we want to type out a server directive by ourselves. The good thing is that you are halfway done.

    The next step is to modify /etc/inc/, to make sure  the whole "server" part doesn't get written to the configuration file.

    I commented out the following lines (underneath the "If the CIDR is less than a /30" piece of text, I //'t them out here already):

    // if ($cidr < 30) {
    // $conf .= "server {$ip} {$mask}\n";
    // }

    And added

    Also, I commented out the line after "case 'server_tls_user':"
    // $conf .= "server {$ip} {$mask}\n";
    Kept the client-config-dir and break; there.

    Not sure if this keeps pf happy:
    While we're at it, we could neutralize the CIDR check as well (The modified text tells you did so ;-)), so you can put a reminder for yourself in the "tunnel network" field. Might want to use your real used subnet as well.

    I commented out everything between "function openvpn_validate_cidr($value, $name) {"
    and }.

    Maybe someone could write this in a nicer way (By checking if the tap interface is selected, and then make the tunnel network optional), but this is a semi-geek solution. I can put the modified files online as well. They might (will) be wiped out when you upgrade your pfSense.

    Note: You always need to type out a server-directive now, for all your vpn's. The wizard won't make those directives either (but you need to enter a valid subnet).

    For example: "mode server" or "server-bridge [ip] [netmask] [start ip] [end ip]" iirc.

    pf will give an error now (scrolling text in the upper right corner), but once you bind the VPN interface to a OPT adapter, that should be gone (or when you define an IP  / not put in garbage in the "tunnel network" field- I'm not quite sure yet).

  • Now, just- If anyone can give me an insight in how to filter on the bridge (blocking certain kinds of traffic), I would be grateful ;)

    -edit- Fixed. That's where the OpenVPN tab under the firewall rules comes to play. (:

  • Rebel Alliance Developer Netgate

  • Looks good. :) Any harm in applying the modified code there to a 2.0 installation?

  • Rebel Alliance Developer Netgate

    Not really, it just won't apply cleanly due to other differences in the files on 2.1. Due to the code paths being touched there is the possibility that some other scenario might break, which is why it didn't make it into 2.0.1.

    I'll make a patch that does apply cleanly and then make a package out of it, hopefully I'll have time to get that done today.

  • That's great! Thanks for the effort you put in. :)

  • Rebel Alliance Developer Netgate

    Coming soon to a package repo near you (as in the next 10 minutes or so)

  • Rebel Alliance Developer Netgate

    Some notes on using that:

    First, read all of the text descriptions on the new fields that show up when you switch to TAP. The notes are important.

    Add a new VPN instance, select tap, fill in all your other info as you want, If you want to provide DHCP to clients, check the box to bridge DHCP, select the interface you will be bridging to, and (optionally) fill in the DHCP server pool. If you fill in the DHCP server start/end it should be a range of IPs outside of your existing DHCP pool. If you leave the IPs blank, it will pass DHCP through to your LAN DHCP server.

    After you save the VPN settings, go to Interfaces > (assign), assign the new VPN interface. Go to Interfaces > OPTx, enable, leave IP type as "none", save. Go to Interfaces > (assign), bridges tab, bridge the VPN interface and your LAN or whatever internal interface(s) you want.

    Go to Firewall > Rules, on the VPN interface be sure to add rules there that will pass DHCP and whatever other traffic you want (or just pass any/all).

Log in to reply