Finally I have resolved with the installation of various packages:
network-manager-strongswan (I have to download and install the 1.4 version because the stock package, 1.3, has a bug)
Remember to restart the client before try the connection.
@timmzahn said in IPSec Down after Upgrade to 2.3:
ou ever find a more elegant solution to the issue, or are you sti
I know this topic is old, but since I found it via google I will post my solution.
I did replace OpenBGP with FrrBGP. I have been able to restore my IPSEC tunneling with AWS and also use the BGP services on PfSense for my needs.
@derelict a few things were mentioned in the thread
2.3 was unaffected yet 2.4 was crashing
issues appeared on VM and bare metal
there was a bug in the kernel
this "issue" first appeared 10 months ago
usr @RMB is using Netgate product yet he was experiencing the issue
Maybe I suggest:
Let us know if that particular patch was merged
Can you try running AES-GCM with any EC (say nist ecp384)
What do you suggest for us the users to get to the bottom of this?
Bummer, it does add a noticeable amount of throughput on my line, which is bandwidth limited and has a monthly data cap.
Still, with the preference setting turned into a no-op, did anyone actually try if it would work? There have been substantial changes in the underlying software, that it may work, after all, in a time long ago, it used to work fine, too.
I reverted the commit I made to allow changed on that field for now, since it was broken.
There seems to be two possible paths here:
Still allow the field to be changed but (a) add input validation to prevent different masks and (b) ignore the mask bits when running ifconfig -- this could be confusing to the user though
Prevent the field from being changed and inject the local mask bits into rightsubnet in the strongSwan config.
Option #2 is much easier, but I am left to wonder how well that will interact with third party implementations that work now when the remote is an address. It may be fine, but needs testing.
If you want to try that, use the system patches package to revert da54e84ae79328a87b4a319239bb1b14d7ed2ce6 and then add the attached patch as another entry.
Ah, should have thought about LAN bypass. Oh well. In the end I went and renumbered everything out of 10.40/16 and into another Class C 192.168.201.0/24.
I am looking forward to 2.4.4. however, routed IPSEC sounds like the real solution. This is how the Juniper SRX on the other end handled things. Creates and extra interface and you simply route down that interface.
Thanks again for the input it is appreciated.
I don't recall the history there specifically. I'm not familiar with that plugin myself. In the past, however, there were a number of strongSwan plugins that were not supported on FreeBSD or did not work properly there. It would not surprise me to find that was the case here, or that SPDs behaved in a more consistent and predictable manner.
Based on the article above, the settings below seem to be stable on both sides so far
Key life: 14400
DH Group: 14 (modp 2048)
DPD (Dead Peer Detection): disable
Key life: 14400
DH Group: 14 (modp 2048)
The only thing on the USG side is selecting Enable Perfect Forward Secrecy (PFS) checkbox.
Been up for 19 hours solid
I noticed how the official guide says
"Users have reported issues with Windows L2TP/IPsec clients behind NAT. If the clients will be behind NAT, Windows clients will most likely not function. Consider an IKEv2 implementation instead."
Wouldn't that almost always be the case, aren't the vast majority of home networks running nat by default?
But doesn't look like a better option, as the guide mentions that mobile clients needs to download a third part vpn app. And you need to transfer ca files between clients.
Good day Folks,
Walked everything through again to figure out what’s going wrong here.
The remote subnet is 10.230.248.0/21. When I calculate this, the amount of host will be 2046. The host range will be 10.230.248.1 till 10.230.255.254. Correct me if I am wrong but 10.230.252.125 should be reachable as well, right? Very strange that I can ping and reach 10.230.252.114 but not 10.230.252.125?
Again, when I am at work, 10.230.252.125 van be pinged and the webhost is reachable correctly.
Does this make sense to anybody?
Having a similar situation and wondering if you every resolved this, can't find much of any response or help for the issue on this forum. Established tunnel without issue to the AWS hosted PFSense from a sonic wall. Can watch the inbound pings hit the system but no progress from their or response.
@stevetoza Off-Topic but here goes. We've experienced all sorts of things with the Cisco RV325 series. Stability however isn’t one of them when running several heavy traffic IPSec tunnels. We swapped out our RV320/325's for virtual pfSense appliances. After a lengthy support thread with a very helpful Cisco support guy they swapped all our units for the new RV340 which is a significantly better hardware platform but since we've been bitten quite a few times by RV320's just going dark on us we now use them as expensive switches. SNMP showed that each time they went offline it was because of pure memory starvation. An RV325 unit with 5 IPSec tunnels and a bunch of local attached stuff would keep running for max 2-3 weeks and then would slowly die, first the web-console would stop responding (and it's already painstakingly slow) and a few hours later all the IPSec tunnels would become unresponsive. There's no automation for these boxes and we don't have managed PDU's so instead of driving to the site location to switch them literally off & back on I rolled some selenium GUI manipulation to power-cycle them every week like that. Seriously. Also had to power cycle twice because sometimes the first reboot wouldn't bring up the IPSec tunnels and when that happened they would never become active, only a secondary reboot would fix that.
Seeing your print screen of the web-console throws me back to a lonely, dark and painful place ;)
I've done such a setup with two PFSenses. each has a seperate WAN Provider.
The other site is a single HA Vmware NSX Edge Firewall.
I made a scripts which checks the WAN Connection. If the internet fails, the script will switches to the backup PFSense and start there the VPN Tunnel.
There is nothing much you can do else.
I'm also waiting for VTI Tunnel Support on 2.4.4
Ahh.. Got it. But I have 7 interfaces LAN I have to apply this to, not just one. In the pfSense website, I found Bug 5826 that describes the problem I'm having. https://redmine.pfsense.org/issues/5826 . I'll do some research to see if I get into the strongSwan config if I might be able to do this for multiple interfaces manually.
Thanks again for the help. I never noticed the Auto-exclude LAN address feature in IPSec.
I have sort of bypassed my problem by downgrading my mikrotik routeros version, but of course that opens me up to possible exploits with may have been fixed since. I have not considered that client connecting/disconnecting could be causing this though, so I will careful note what happens next time I have a disconnect.
I've 50 phase 1 and 150 phase 2 on my pfsense server (hp G8).
CPU Type Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz
8 CPUs: 2 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
Hardware crypto AES-CBC,AES-XTS,AES-GCM,AES-ICM
The last tunnel I created is causing trouble. Phases 1 and 2 UP from time to time and when they are UP, I have no traffic passed.
I tested this vpn on a virtual machine pfsense and everything is OK.
I wonder if I'm reaching a tunnel limit. If yes, how to properly modify the ikesa_table_size value to 1024 so that it is taken into account in case of reboot / upgrade?
Thank you for your help.