OpenVPN Shared Key Bridged Site-to-Site Strangeness



  • I am setting up a test bed for a VPN between two 2.01 pfSense boxes in our production and development sites.  We need to have access to the WAN interfaces at either site so that we can use the WAN subnets at either site for the test boxes in our development site.

    I set up two firewalls (each built from the same CD!).  I have a DSL connection on each for WAN connectivity.  On one system I also have a Cable modem as an additional WAN connection.  Each firewall is working and gets a client to the Internet with no issues.

    I set up a Peer-to-Peer (Shared Key) OpenVPN tunnel, protocol UDP, Dev Mode TAP, Interface WAN, AES-256-CBC encryption, with a tunnel network set to a private IP/29.  I set up the appropriate firewall rules, enabled the OpenVPN interface, and added the interface to a bridge group with the LAN interfaces on each firewall.

    The LAN interfaces are on the same network (192.168.0.0/24) across the bridge.  From behind one firewall, I can ping machines off the LAN interface of the other firewall.  I can set the default gateway of one machine to the LAN interface of the firewall on the other end and I go out the WAN interface on the far firewall - but the opposite does not happen.  There seems to be a preferred firewall and the client attached to that directly will not go out through the othe firewall no matter what I do.

    If I need to explain this more, let me know.  I am going to play around with this some more and I will try and provide more details.

    Thank you!



  • OK…

    So, giving the non-preferred pfSense box the lowest IP address in the bridged internal network did not alter the behavior (it already had the lowest WAN IP address).

    I cannot understand why there is a preferred pfSense box at all.  If I make the default gateway the IP of one pfSense box and every client will work through that box, why should it make a difference if I make the other pfSense box the default gateway?  Why will all traffic not flow out that box when it works for the other?  The only difference I think might matter now is the order the boxes were created, so I am about to blow away both and re-create them in reverse order from the way I did it the first time.

    Has anyone else observed this behavior or am I a trail blazer here?  :-\



  • You're not alone, but using Shared Key is a REALLY BAD IDEA.  Use Certs and create the tunnel that way.  On the openvpn server, allow the clients to contact each other.

    Another interesting question I have to ask is why Bridge?  It just causes unnecessary traffic.  If you need to Access Windows shares, either call them by IP or better yet, set up a NetBios Server.

    Bridging has it's uses, but you're eating bandwidth for absolutely no reason.

    Pre-shared key is a bad idea as there is no real way to transmit the preshared key successfully unless you pre-encrypt the file and that can be done with AES crypt. Remember Deep Packet Inspection will be able to see the key. (If they are monitoring for that).. If they have the key, they can snoop.  Not exactly secure.  Defeats the purpose of VPNs.

    Lots of VPN and cloud info. :)

    Read more on my blog about these issues:  http://swimminginthought.com

    Cheers.


Locked