Bug #3266
closed
Synchronize OpenVPN + Site-Site = Fail
0%
Description
The 'Synchronize OpenVPN' HA checkbox prevents site-site OpenVPN from working in primary/backup setups. Two enabled clients trying to provide routes to the same subnet to two enabled servers on the same far subnet with identical settings creates intermittancy and routing confusions.
Next the 'Disable this server' and 'Disable this client' button should be forced 'ON' when HA Sync / copying connections from the primary to backup boxes.
Those two small changes would allow for the user creation of scripts that would bring the backup OpenVPN instances online when a CARP VIP changes to Master from Backup and off when changing to Backup from Master.
Best would be if PFSense would allow in the OpenVPN client and server setup GUI to allow the option to specify a CARP VIP and set whether the OpenVPN instance is enabled or disabled based on whether the specified CARP VIP is master or backup.
Of course 'most best' would be to allow all instances to be 'up and running' all the time, with the server side tied to a CARP VIP on the wan, two boxes acting as clients to the same subnet up and running on the far side and all four to not clash. Yeah, good luck with that. Watch the PFsync traffic explode as four boxes think they've got routes and active states to and from the same place for the same subnet. If that's possible the checkbox 'Duplicate Connections' should be forced 'on' on server setups when the 'Synchronize OpenVPN' is checked.
Better I think to bring the OpenVPN instances up and down when the carp vips go up and down.
Updated by Harry Coin over 10 years ago
Update: Should have written: the 'Disable this server' and 'Disable this client' button should be forced 'ON' when HA Sync / copying .... Site to site .... connections from the primary to backup boxes.
Updated by Jim Pingle over 10 years ago
- Status changed from New to Rejected
This works fine on 2.0.2+ if you select a CARP VIP as the "Interface" for the VPN, the system automatically stops the service on the backup node, and starts it when the VIP transitions to master status.
Updated by Harry Coin over 10 years ago
Jim, welcome news indeed. Please then change
"Interface : Whichever interface you want the server to use for incoming connections. Typically WAN, but may be an OPT WAN. You may also use "any" and then it will bind to all interfaces. "
on https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_%28Shared_Key,_2.0%29
to
"Interface : Whichever interface you want the server to use for incoming connections. Typically WAN, but may be an OPT WAN. You may also use "any" and then it will bind to all interfaces. In Master/Backup setups, choose a CARP VIP"
Updated by Harry Coin over 10 years ago
Jim,
Doing as you suggest does solve the problem for the site-site server side in a Master/Backup HA situation with one wan.
Consider issuing a warning if both the 'HA Sync' button and choosing a 'GW Failover xxx' on the client side OpenVPN exist at the same time.
In a multi-wan in a master/backup client situation, The HA button works on the client side only if I specify a single WAN's VIP, but fails if a GW Failover group is chosen.
Updated by Harry Coin over 10 years ago
And in the category of 'somewhat evil hack that works':
If you have a master/backup pfsense setup AND
you have more than one WAN, that is, a multi-ISP, setup AND
you want to run site to site or site-site OpenVPN as a client:
You probably have a CARP-VIP on the LAN side with all kinds of good rules about wan and failover and whatnot. If you set the interface of the Openvpn should bind to to be the LAN and NOT the really cool failover gateway group that shows up there in the client GUI, you can check the 'Sync OpenVPN' box in the HA section and not have it fail as it does had you chosen the failover GW and not have Open VPN fail if one of the WANs you chose fails. You have to set up the firewall rules to allow tunnel ip traffic on the lan.
If the server has more than one WAN, you can do all sorts of configs to do with "--remote' on the clients and a server for each of the wan VIPS-- or leave the client simple as above and try setting up a server on the LAN carp VIP (so server shop OpenVPN master/backup failover works) and then NAT/port forward incoming openVPN traffic on the wans to that.
What a ride!