SOLVED - Can I use bridging to get a public network available across OpenVPN?



  • Okay, here's what I want to do: I would like to have a pfSense box at my colo facility, where they will provide me with a public IP range, and then I want a pfSense box at the office, with a cable modem connection. I would like to create a layer 2 VPN across the internet that would let me assign the public IPs to machines here at the office (on an OPT most likely).

    I've tried following the bridging tutorials, and I've been doing all sorts of tests for about 2 days now, and at this point I'm so utterly confused about what I should be doing to achieve this that I'm pulling my hair out.

    I am able to test this here in the office. I have a cable modem, I have T1 lines with public IPs, I have two pfSense boxes. So I've been having one set up as the one that will go at the colo facility, and one setup with the cable modem connection, so the OpenVPN connection goes across the cable modem/T1s so that it's a real test (isn't just being done locally).

    Anyway, I think I need some help here, some direction, maybe even just a starting point. I have no one here to bounce these kind of ideas off of and I need a fresh perspective.

    Also if it helps, doing 1:1 NAT on the public IPs on either end would be a very acceptable solution for me, if it means getting this working.

    Thanks.



  • To be honest…. i never actually used OpenVPN with pfSense in a bridged scenario myself.
    I had a bridge working between two windows machines once, but more to play around.

    As far as i understand bridges, they are transparent to a device as long as you allow traffic from both sides.
    --> A device doesnt actually see any difference if it's connected via a bridge or via a switch.

    Could you maybe provide more info what doesnt work, and how you expect it to work?
    What doesnt work and how did you test?

    Did you follow this guide?:
    http://doc.pfsense.org/index.php/VPN_Capability_OpenVPN#Advanced_Hackery
    If you bridge two locations together they become essentially the same broadcast domain.

    Things to check:
    Do you have the same subnet on both sides of the bridge?
    Do you have firewall rules in place that allow traffic between the two sites for the same subnet?



  • Hi Gruens,

    Thanks for your input. After reading your message and went back and started working on it again. I'm really close now; in fact I may have been this close before and never realized it but this time I did!

    Basically, I have the openvpn bridging tunnel up, it appears to be working, but only one way. Let's say machine A is on the "colo" side, it has the public IP range. Its WAN is bridged to the openvpn tunnel's tap0. The public IP range is 1.2.3.0/24, its gateway is 1.2.3.1 (connected to machine A's WAN).

    Machine B is the pfSense box on the "office" side. It has an OPT with the same subnet bridged to tap0 on its side of the VPN. The OPT has a laptop connected (machine C) with a statically defined address from within the public subnet (1.2.3.50).

    Here's where it's not quite working right. I'm running a continuous ping from machine C to 1.2.3.1. The progression should look like this (hopefully this makes sense without labeling the arrows):

    Machine C (1.2.3.50) –-> Machine B (OPT) ---> Machine B (tap0) ---> Machine A (tap0) ---> Machine A (WAN) ---> gateway (1.2.3.1)

    (and then back the other way for the replies)

    The pings are timing out, and a packet capture on machine A reveals that the ARP who-has requests are indeed not only getting all the way to machine A, but are getting to the gateway; machine C is asking for the MAC address of 1.2.3.1, as it should be. In addition, 1.2.3.1 is replying, and I can see the reply in machine A's packet capture. But it's never getting back to machine B. I've also set a static ARP entry on machine C but no matter what, packets don't seem to be sent over the tunnel if they originate from the machine A side of things, but they get through just fine from the machine B/C side of things. I've checked the firewall rules a dozen times; everything is allowed.

    In case you're wondering, a packet capture on machine B only shows the ARP who-has requests being sent, but never shows any replies.

    I though maybe machine B might need something set on the firewall but everything is allowed there too.

    I don't know if this is related, and I don't think so, but on machine B I had to set a static route. Machine A's IP is 1.2.3.2 and it uses this as its WAN connection. Machine B has a cable modem, so an OPT is given 1.2.3.3/24. Problem is that the public address for the VPN tunnel is 1.2.3.2, so I just had to create a static route to tell it to always route 1.2.3.2 through the cable modem connection. I doubt this has anything to do with it, but it's worth mentioning.

    I've checked the status of the bridge on both machines (ifconfig bridge0) and all seems fine. Both bridges must be working in some capacity since the ARP request from machine A indeed gets all the way to the gateway.

    I had to use a PKI tunnel (doesn't seem to work with shared secret type, probably because of restrictions in the pfSense UI that force some options that don't work right with bridging), and so the server config is quite different than the client. Machine A is the server, machine B is the client. I though it might have had something to do with this config difference, but I couldn't find anything wrong with it. There isn't much to look at since it isn't routing.

    Any ideas as what could be causing the traffic from the server (colo side) to not get sent across the tunnel? Thanks!



  • I got it!

    My god.. all this hair pulling. The problem was that the tap0 interface on machine B did not have an IP address assigned to it. That was it. It works, wonderfully. I am way behind schedule on what I need this for, but with any kind of luck I'll have some time in a few weeks to write up a start to finish guide.

    Until then, I'll try to check the thread as often as I can to answer any questions.


Log in to reply