OpenVPN site-to-site tunnel, multi-WAN setup?
-
Hello,
Most of my branch offices have two internet connections, configured with load balancing. Is it possible to configure OpenVPN tunnels from my datacenter to these branch offices, with the VPN tunnel configured with load balancing or failover? If so, how?
Thanks,
Todd
-
A basic way to do failover is discussed here: http://forum.pfsense.org/index.php/topic,49033.0.html
That configuration just has a single OpenVPN link between the sites, in which the client can exit through either link at a site and connect to the server, which is listening on both links at the other end. No load-balancing in that though - the single logical link uses whatever physical link it finds is up first.
For load-balancing you would need 2 OpenVPN links in tandem. Then I guess you could put them into a gateway group etc - I think that sort of gateway group for OpenVPN stuff is in 2.1. I should try it sometime :)
The tricky thing about having 2 lOpenVPN links in tandem is that they don't cope with all failover conditions.
e.g. Site A link 1 & 2, Site B link 1 and 2. OpenVPN links from A1 to B1 and A2 to B2. If A1 and B2 are down, then there is a path from A2 to B1, but the load-balancing links won't find it. -
Hi,
Yes, I've seen this post. However, only my branch/satellite offices have two internet connections, e.g.:
Site WAN A1
OPT A2Site WAN B1
OPT B1…etc.
Main endpoint (VPN concentrator if you will)
Endpoint CARP WAN ZSo, I'm not sure these other instructions fit. I am using IPSec now, and it is embarrassing when one of the connections goes down and the VPN tunnel expires completely while internet access is unaffected.
-
The article really just applies to failover, but with dual internet at both ends. Your situation is simpler, one end has no failover possibility.
It might be easiest to put an OpenVPN server instance at each branch office. Port forward the port you want to use for the server (e.g. 4330 - pick a port you don't need for anything else) from both WAN and OPT to LAN. Then have the OpenVPN server listening on LAN.
For each link, have a client at "main endpoint" that connects to WAN (public ip w.w.w.w) and OPT (public ip x.x.x.x) - put w.w.w.w as "Server or host address". In Advanced put:remote x.x.x.x 4330
Of course, if you have DNS names for these public IPs, then you can put names in rather than IP addresses.
By having the servers at the branch office end:- Your can use the same port number everywhere (no need to keep a record of which branch connects to which port number on a central device).
- No hassle getting the client to find its way out whatever link is up - the server is at the failover end and happily listens for connects from WAN and OPT, whether they are up or not.
One day I will play with dual OpenVPN links and load-balancing, as that will be useful for me as I get more users traveling between sites and accessing data back at their "home" site. If I could do something like "MLPPP" a bundle of OpenVPN links, that would provide a single logical pipe between sites that actually load-shares 2 OpenVPN links, and even load-balances a single data flow. This week I have a bunch of other stuff on, so no time to play with pfSense!
-
Hey
did you every get the multi openvpn bonding working?
Thanks
-
One day I will play with dual OpenVPN links and load-balancing, as that will be useful for me as I get more users traveling between sites and accessing data back at their "home" site. If I could do something like "MLPPP" a bundle of OpenVPN links, that would provide a single logical pipe between sites that actually load-shares 2 OpenVPN links, and even load-balances a single data flow. This week I have a bunch of other stuff on, so no time to play with pfSense!
Hi,
Any suggestions how to achieve this? Currently I have Alix boxes at two sites and OpenVPN failover (one server listening on LAN, NAT forwarding on both WAN connections to the LAN address). I would like to increase bandwith.
Thanks
-
I am finally setting this up, with OpenVPN listening at the offices on LAN interfaces, and port forwarding from each WAN.
Would traffic from the users at the remote offices establish the OpenVPN tunnels, or would I have to generate traffic from "main endpoint" in order for the tunnel to establish?
-
I guess it does not matter which side is server or client, traffic can initiate in either direction.
I found that OpenVPN's failover works OK (remote x.x.x.x 4330), but it's not failing back at all once the original WAN comes back online.
I'm assuming OSPF routing wouldn't make sense for this scenario.
It seems like it would work to have Dynamic DNS update a Gateway Group, instead of using a single WAN. This way you could choose what gateway is preferred and it would automatically update the DNS record accordingly. The OpenVPN client could then be configured to connect to this dynamic DNS address.
It seems like it's missing the point to use public DNS records, though, if the point of a VPN is to communicate in secret.
-
It should be possible to make the OpenVPN server listen on a gateway group - that will make the server move back to the tier 1 primary WAN when it comes back up.
If both the WANs at the server have static public IP addresses then you can still put both those addresses in the client config. Then the client will try each one in turn. When the server primary WAN is down, the client will get a timeout, give up and try the server secondary WAN, which is hopefully working. When the server primary WAN comes back up, the server-end OpenVPN will be moved, "pulling the rug" from under the connection. That will make the client end timeout and start again trying the IP addresses it should connect to. This time it will succeed connecting the the server primary WAN.Note: No, I never got to trying to mangle up some sort of MLPPP of a couple of PPP links running inside a couple of OpenVPN links.
-
Having the OpenVPN server listen on the gateway group does work.
It's taking over 2 minutes to failover or fail back, though. Is there any way to reduce the failover or failback time for OpenVPN?
For example, here the OpenVPN server's WAN1 connection was restored at 16:14:05, but this caused an additional outage for the tunnel until 16:15:10 in order to fail back to it:
Apr 17 16:15:10 openvpn[39517]: Initialization Sequence Completed Apr 17 16:15:09 openvpn[39517]: Peer Connection Initiated with [AF_INET]sr.vr.wan.1:xxxovpnportxx Apr 17 16:15:09 openvpn[39517]: UDPv4 link remote: [AF_INET]sr.vr.wan.1:xxxovpnportxx Apr 17 16:15:09 openvpn[39517]: UDPv4 link local (bound): [AF_INET]cl.ie.nt.ip Apr 17 16:15:09 openvpn[39517]: Preserving previous TUN/TAP instance: ovpnc4 Apr 17 16:15:09 openvpn[39517]: Re-using pre-shared static key Apr 17 16:15:09 openvpn[39517]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 17 16:15:07 openvpn[39517]: SIGUSR1[soft,ping-restart] received, process restarting Apr 17 16:15:07 openvpn[39517]: Inactivity timeout (--ping-restart), restarting Apr 17 16:14:07 openvpn[39517]: UDPv4 link remote: [AF_INET]sr.vr.wan.2:xxxovpnportxx Apr 17 16:14:07 openvpn[39517]: UDPv4 link local (bound): [AF_INET]cl.ie.nt.ip Apr 17 16:14:07 openvpn[39517]: Preserving previous TUN/TAP instance: ovpnc4 Apr 17 16:14:07 openvpn[39517]: Re-using pre-shared static key Apr 17 16:14:07 openvpn[39517]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 17 16:14:05 openvpn[39517]: SIGUSR1[soft,ping-restart] received, process restarting Apr 17 16:14:05 openvpn[39517]: Inactivity timeout (--ping-restart), restarting Apr 17 16:07:51 openvpn[39517]: Initialization Sequence Completed Apr 17 16:07:51 openvpn[39517]: Peer Connection Initiated with [AF_INET]sr.vr.wan.2:xxxovpnportxx
-
Is there any way to reduce the failover or failback time for OpenVPN?
You should be able to modify the keepalive like suggested in: https://forum.pfsense.org/index.php?topic=59319.msg318751#msg318751
That will let OpenVPN detect a real failure quicker.
But when pfSense detects a gateway status change it rewrites the OpenVPN conf file and restarts the process anyway. You could change the gateway parameters (System->Routing, edit the gateway/s, click on Advanced) to make the down time shorter. But then you might get more false alarms when thereis a minor issue with the monitored gateway IP. -
Failover/Failback seems to work much better with the following on the client side:
remote sr.vr.2n.wn xxxxx;
keepalive 1 4;Are there any repercussions for having the keepalive timing this tight?
In case of a false outage, does restarting an OpenVPN tunnel cause loss of traffic?
-
If you have a reliable WAN at each end with a short/low latency path then it should work. I am in Nepal and we don't have anything like that :)
If it feels like restarting then there will be some interruption to users. For the majority of users that use TCP-based apps, they will just see their app stall for a bit and then keep going, because TCP will retransmit packets that got lost while the VPN was restarting.