OpenVPN client showing 100% packetloss following 2.5.0 upgrade
-
@hypnosis4u2nv
Wireguard works ok? I would love to set that up but I am missing some information. Like on pfSense when I enable wg0 what do I need to enter in the Address field? And then when I generate the Wireguard config on Torguard do I need to enter that information in wg0 peers? Maybe you can share some settings/screenshots? Would be greatly appreciated. -
@vjizzle There's a "general guide" recipe on Netgates site:
http://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html
In short, your VPN provider will give you the IP address to stick in the config.
-
@vjizzle Use the configurator on Torguard, choose Wireguard from the drop down box. Choose a server location. Have pfsense generate the private and public keys. Enter them in the Torguard configurator and it will spit out a configuration. Use the server IP generated and enter that in the address field in pfsense. Click "Add Peer", fill in the keys generated by the configurator and all the other settings it spit out. Save. Add NAT rule for Wireguard. Add interface wg0 and create a firewall rule to allow any for all. Go to LAN and create your PBR to use Wireguard.
-
@vjizzle where can i find info about setting up several tunnels in a gateway group? it may come handy for future use.
-
@nevar
I would suggest this awesome blog: https://nguvu.org/pfsense/pfsense-multi-vpn-wan/It is initially for AirVPN but it should give you the general idea of how it works.
-
@hypnosis4u2nv
Thank you for sharing this information! I set it up this morning and Wireguard seems to work fine! Lower latency as well :) -
@vjizzle said in OpenVPN client showing 100% packetloss following 2.5.0 upgrade:
And another update. I just spoke to the guys at Torguard and they keep telling me that everything should be working on pfsense 2.5.
So I decided to do a backup of the 2.4.5 setup, do a clean install of 2.5 and restore my backup. Guess what....everything is working! Torguard is working as expected, routing as expected monitor gateway is doing it's thing with 1.1.1.1 or 8.8.8.8.
Lessons learned: I strongly advise do not do an in-place upgrade from 2.4.5 to 2.5 if you have OpenVPN tunnels running. Just take the time, backup your 2.4.5 config and do a clean install of 2.5. Then restore your configuration and that should have your firewall running up again!
Just to report back: with the clean install approach and restore your 2.4.5 backup everything on OpenVPN seems to work. VPN tunnels are up and running for about 12hours now with no downtime. It is stable :)
-
@vjizzle be interesting to know what PfSense team did between upgrading and clean install that borked this.
I needed a clean install anyway ;)
-
@vjizzle I'm on a clean install, restore didn't help. The VPN stayed down, even on reboot. Got rid of all my OpenVPN configs and set up Wireguard, no issues. I'm frustrated because I'm trying to find the cause but everything points to a service being the issue, not me lol.
-
Wow I don't know what to say. Are you also using Torguard OpenVPN? Make sure you have the monitoring ip set to 1.1.1.1 or 8.8.8.8. Mine works with those but also with 9.9.9.9. I just checked and it also comes up after reboot of pfSense. Everything works here :|
-
@vjizzle YEah, i tried setting it up yesterday and the certifications were crashing and I couldn't get rid of the offending CA - https://redmine.pfsense.org/issues/11489 so I just restored from previous config.
I gave up, shouldn't be this difficult to get working, i had it working first time on 2.4.5...
-
@vjizzle Just wanted to give an update. I got it working and I finally figured out what it was.
I'm using Torguard, and with the newest version of OpenVPN there were some settings that were added and/or removed since their last guide to setting up a client. The issues I was experiencing all fell on one setting that their guide says to leave unchecked - "Dont pull routes".
I never had this setting enabled on version 2.4.5. Plus some new settings that didnt get applied properly, so obviously it explains why everything went down after the upgrade.
With the "Don't pull routes" disabled, EVERYTHING was being routed via the VPN client, no matter what PBR I had in place. So if the client was configured wrong and not up, my entire network would go down as well. Once enabled, PBR would only route via the VPN client and everything else through the WAN.
What a fucking shit show the last week has been trying to figure this shit out. -
@hypnosis4u2nv my part is mainly on the fallback which was default to AES-256-GCM instead AES-128-GCM and gateway monitor. Once I set fallback to AES-128-GCM and gateway monitor either disable or enable. If you want to monitor it, as @vjizzle pointed out that use public domain. I recently just enable monitor and monitor my two vpn connection. I also checked "Don't pull routes" and "Don't add/remove routes" to avoid conflict with the two torguard vpn connection that i'm using. Otherwise, i will have situation where user A will have same public ip address of user B but both user are assign to different VPN connection.
-
@hypnosis4u2nv
Good to hear that you got it working :). Maybe I should have mentioned it but I always have the "Don't pull routes" option enabled (in version 2.4.5 and 2.5) because I use several VPN tunnels and rely on pbr to route the traffic where needed. -
@vjizzle Weird that it didn't cause me issues on 2.4.5, worked just fine with it unchecked. Question, do you also enable "Don't add/remove routes" on your configuration?
-
@nevar I knew about the gateway monitor IP to get it not showing a loss, which is why I initially responded to this problem. Thankfully, it also helped me start looking into what could be the cause of my unrelated routing issue. I didn't enable "Don't add/remove routes" but sounds like I should if I'm using more than one vpn client. I was considering adding another one and creating a gateway group for a fail safe if one gateway goes down, the other will continue to provide internet access.
-
@hypnosis4u2nv
Hi. I only have Don't pull routes enabled. -
@vjizzle I used that how-to as well. Worked out pretty good for me.
-
Ok, so my application is probably quite a bit different to what most of you are using OpenVPN client for - multiple pfsense clients doing peer to peer to a single pfsense server, carrying a guest network across many sites. But, perhaps my solution will also work for you....
system > routing > tunnel_gw > advanced > use non-local gateway
I already had non-negotiable AES-128-GCM for encryption.
This allows me to continue using gateway monitoring - I'm actually monitoring the far-end IP of the tunnel, ie the server tunnel address.
-
My solution is easy, don't specify a 'Monitor IP'.
- Disable Gateway Monitoring = unticked
- Disable Gateway Monitoring Action = unticked
- monitor IP = empty
What happens is that if not monitor IP is set pfSense uses the 'Virtual IP' presented by the OpenVPN client to PING and this only becomes available after the OpenVPN client has successfully connected.
I suspect that PINGs to the outside world are happening before the client/route is initialised or that the PING is not being routed and this is why if you use a real IP the monitoring is not working and because of this failure, pFsense flags the Gateway as offline.
My pf version: 2.6.0-RELEASE (amd64)