OpenVPN Site-to-Site fully broken after upgrade from 2.3.5p2 to 2.4.4
-
Hello,
we use in our company many site-to-site OpenVPN tunnels, everything works fine. But with EOL of 2.3 branch we stand face-to-face to a big problem. OpenVPN Interfaces and gateways IP's in 2.4.4 are set automatically. I tested version upgrade from 2.3.5p2 to 2.4.4 on one site-to-site line and our setup was fully broken.
Before upgrade: OpenVPN server has IP address 10.0.X.1, remote OpenVPN client 10.0.X.2 (X=3-14). Client tun interface is set alone as gateway for routing to another subnets connected to remote OpenVPN server (star network topology). This means IP address of tun interface and his gateway is the same.
After ugrade: Tun interface IP address is set to 10.0.X.1 and cannot be changed, conflicting with remote server tun interface. New VPN gateway is automatically created with IP address 10.0.X.2 . Connection to headquarter is completely broken.I cannot change settings of OpenVPN server without downtime, but this is impossible. Is it any resolution of this problem? Please help. :-)
Thank you very much for constructive answers.
-
please provide screenshots of tunnel config on both sides
-
Network diagram:
OpenVPN Server
OpenVPN Client
When I tested 2.4.3 to 2.4.4 upgrade, everything went fine. No new gateway created, no IP's changed.
-
How do the VLANS on WAN work?
Are those VLANS present on your remote sites also?
Regarding the tunnel setup, I think you want to use a /30 for your tunnel networks.
So you have a mix of 2.3 and 2.4? The 2.4s upgrade ok, but the 2.3s don't?
-
How do the VLANS on WAN work?
There is one physical Interface (WAN) with one-for-all wire between our firewall and provider infrastructure. On top of this physical interface 12 virtual network adapters are created with its own individual VLAN tag and IP address. OpenVPN server session runs on each virtual interface on dedicated port (e.g. virtual adapter with VLAN id 4 named VLAN4 has OpenVPN server on port 1204 with tun adapter named TUN4, VLAN id 5 named VLAN5 has OpenVPN server on port 1205 with tun adapter named TUN5 on port 1205 and so on).Are those VLANS present on your remote sites also?
No. On client side is "pure" network connection for each remote office.Regarding the tunnel setup, I think you want to use a /30 for your tunnel networks.
So you have a mix of 2.3 and 2.4? The 2.4s upgrade ok, but the 2.3s don't?
Our VPN infrastructure is fully 2.3.5-p2 version, both in headquarter and in remote locations. Upgrade to 2.4.4 version on Remote Office (fortunatelly I tested it on one remote gateway only :) ) destroyed VPN setup and we had to rollback to old version. Because is it impossible to download 2.3.5-p2 ISO directly, I had to install 2.3.4, upgrade to 2.3.5-p2, set network connection and restore old configuration from backup (upgrade from 2.3.5 ISO to 2.3.5-p2 is also broken, no updates was found, restore 2.3.5-p2 config on fresh 2.3.5 installation ended with some PHP missing files. Ahhh, Catch-22!!!). Main firewall remained intact, still same version and setup.
2.4.3 version is only in headquarter on separate firewalls (OpenVPN for Remote Clients only, not site-to-site). Upgrade to 2.4.4 went fine with no changes in OpenVPN IP's/Gateways, VPN connection is still possible. -
After a long time we decided to try "second servis" upgrade from pfSense 2.3.5-p2 to 2.4.4-p3 on our remote offices. Everything went fine, so there is a little survey:
OpenVPN site-to-site (shared key) tunnel has so called "dynamic" gateway in 2.4.x on client side, which is created automatically on the system startup. So if your old version has a manually created VPN gateway (routes to headquarter not included in OpenVPN config...), you have to remove this gateway before upgrade. My best practice was backup old configuration, upgrade, login to the upgraded pfSense and completely remove the old OpenVPN client and his TUN interface. Then I created new OpenVPN client. VPN gateway was created by system and a I could set up required routes again.