Open VPN 2.7 Site to Site Odd Routing Issue
-
-
@viragomann now here's the working 2.6. The obvious problem and difference between the 2.6 and 2.7 appears to be the GATEWAY. Where would I correct this? Same config restore file onto new 2.6 and 2.7.
-
@charlieblalock
Are you running the clients in tap mode by any chance?Did you assign interfaces to the clients? If yes, how did you configure these?
Otherwise would need to see the configurations to get a step beyond.
-
@viragomann I used the default TUN. As you see between 2.6 and 2.7 - the difference is that 2.7 had 255.255.255.0 as the gateway and all the OpenVPN client connection they all used OVPNC4. Just do not know exactly how to correct that. Since the configuration is exactly the same 2.6 /2.7.
-
@charlieblalock
So you haven't assign interfaces to the VPN clients obviously.Shared key is deprecated and should no longer be used. It will not be supported as of OpenVPN 3.
But I'd expect, that it would still work on pfSense 2.7, since this include OpenVPN 2.6.
But I believe, it's already removed from the pfSense docs.I haven't set up a shared key for years yet. Hence I'm not experienced with it.
And even if it was a configuration issue, your screenshot might not show the relevant section.I saw another member complaining the same issue a view days ago:
https://forum.netgate.com/topic/183644/site-to-site-with-shared-key-gateway-bug -
@viragomann Under Interface Assignments since 1.2 version, I never assigned any for OpenVPN. Under 2.7 requires this? It's just perplexing that a configuration I emulated but did from scratch on 2.7 works on 2.6 after restoring that config.
My questions is what ensure that the proper GATEWAY is pulled/ propagated correctly for 2.7? And are you indicating that Shared Key is the possible reason GATEWAY is not working and that using SSL/TLS will fix it?
-
-
@charlieblalock said in Open VPN 2.7 Site to Site Odd Routing Issue:
Under 2.7 requires this?
No. The guy in the quoted thread assigned a gateway and had the same issue.
I suspected that you did something, when doing this. And I didn't know that you have a shared key set up, before I saw your settings screenshot.
-
Just converted all the connections and rebooted all to Peer SSL/TLS instead of Shared Key and still no go, but the gateway info in Routes appear correct now instead of just 255.255.255.0. Connections shows up as up but there's no ability to ping or connect to remote hosts at each end. Looks like 2.7 is not compatible with 2.6 and before.
Routes and Interface now show up as correct when you convert from Shared Keys to SSL / TLS but there is still no connectivity from 2.7 to 2.6. All tests above should help Netgate / OpenVPN. Perplexing bug.
-
@charlieblalock the outcome so far from my side:
is that 2.6 server and 2.7 client, is not working ok on the gateways (using the subnet mask instead of the other pear ip).
i tested this initially with shared key, and then i test it with SSL/TLS certificate authority configuration etc.... same issue accours with both configurations.
everything was resolved when downgrade the client to 2.6. -
@charlieblalock
With a SSL/TLS configuration, you have to configure client specific overrides for each client on the server. There you have to specify a unique client tunnel IP and the remote networks behind the client.If you run a separate server for each client you can alternatively set a /30 tunnel network mask on the server. However, consider that this is not compatible with CDO, if you want to use it in future versions. So the recommended set up is to configure CSO.
-
SOLVED
@viragomann Thanks for the ideas that got me to solve the entire thing.
I started with 2.6 using Peer to Peer (Shared Keys) on the site to site peer clients. I converted all the client sites fine with SSL/TLS but the key piece was Client Specific Overrides on the various servers I was connecting to needed. I did not need this before 2.7 to get everything working.
My various servers were 2.6 and my firewall peer clients that connected to those 2.6 is a new 2.7. It now works. I had 4 Server 2.6 I was connecting to using a new 2.7 Client firewall.
As long as you have the certs correctly set up which I did not have a problem with, you should be good. The key change or use for me was the CSO per @viragomann. CSO on the OpenVPN Server fixed the routing by populating the necessary routing / gateway configurations for my peer client connections for each corresponding sites.
Steps on OpenVPN Server pfSense firewall
1 - Create CA on Peer to Peer Server (export CA cert)
2 - Create Server Cert on Peer Server
3 - Create Client Cert for EACH Peer to Peer Client (export cert and key)
4 - Create OpenVPN Server setup selecting SSL/TLS on Peer to Peer and add the IPv4 Tunnel Network, IPv4 Local network(s), and IPv4 Remote network(s)
5 - Create Client Specific Overides for EACH peer client firewall connecting to this server
6 - Name Common Name same as the corresponding cert for the specific peer client, and fill in IPv4 Tunnel Network, IPv4 Local Network/s, IPv4 Remote Network/sSteps on OpenVPN Peer Client pfSense firewall
1 - Import the CA (from step 1 server section above) and the corresponding peer Client cert and key (from step 3 server section above)
2 - Go to VPN / OpenVPN / Clients tab and begin adding your peer client for each Open VPN Server you need to connect to (maybe you are just connecting to one)
3 - Peer to Peer (SSL/TLS)
4 - Choose the proper port if you have several peer client setting up
5 - Select your imported CA in Peer Certificate Authority (from Step 1 in Server section) and the imported corresponding Client Certificate (from Step 3 above in Server section)
6 - Fill IPv4 Tunnel Network, IPv4 Remote network(s)Firewall / Rules / OpenVPN
1 - Add Pass for ANY protocol on IPV4 and ANY/ANY Source / Destination to verify flow and then you can filter more if need to later
** You may need to restart the services for OpenVPNServer and OpenVPN Peer Client firewalls....connections should be made if the proper Network and Subnets were created.
-