@jimp I applied the patch, verified that split_include was no longer in included in /var/etc/ipsec/swanctl.conf and connected the android VPN client. The Android IPSec client now connects successfully regardless of the Network List setting. Thanks.
Here's the ones from the post I believe you are thinking of. Just would hate to miss one, the one because they're all over the place.
Both can coexist OK on 2.5.0/21.02, but something in your settings may be causing that. You need to provide a lot more information about your configuration, plus connection logs when it does/doesn't work to compare what happens.
Typically that kind of thing happens when there is some overlap in the remote addresses on the tunnel or if the identifiers can't be matched.
There are also a few known issues in 2.5.0 which could affect this, look at the other threads here in the IPsec category for a list of patches to try.
@viktor_g Thanks for the super fast response. Unfortunately no improvement, DNS servers still not pushed. If uncheck the "Provide a virtual IP address to clients" like the above workaround, the mobile pool is not loaded despite the patch.
However, when RDPing to computers we get a warning that the Revocation check for our cert couldn't be completed. So I created a CRL in pfSense, exported it and imported it to computers and the warning has gone away.
However on the CRL page it shows an X for the 'In Use' column for the CRL. Do I need to force this on the IPsec Mobile Client VPN? OR does X indicate it is in-use?!!!
I know it's an old topic, but specifically because it's old I am asking that you actually update the official Docs with these conclusions and replace the "Set Peer Identifier to User Distinguished name, enter an e-mail address style identifier (e.g. firstname.lastname@example.org) – This isn’t used, but is currently required by the GUI" with "Set to Any".
I would do this myself, but you don't seem to be hosting the Docs on GitHub anymore.
I spent some 2 hours today at my wits end trying to figure this out before I set the Local ID on my mac to "email@example.com" and got it working.
I tried breaking my tunnel which uses certs in various ways but the only way I could do it was to use identifiers which were not a part of the certificate, or to not have the correct matching CAs present on one side or the other.
The status problem is already known and fixed. To ensure you have all of the current known and fixed IPsec issues corrected, You can install the System Patches package and then create entries for the following commit IDs to apply the fixes:
I go 9 (!) IKE secrets despite the fact in the webinterface there is only one defined....
Secrets entries are also defined by user keys under user accounts and on the PSK tab, not just from tunnel.
Sorry for the fuss but @netgate this is not good at all...
Some key feature which is essential like IPSec should be tested more thouroughly....
We did test it thoroughly but there are only so many configuration variations we can test. We all use IPsec on 2.5.0/21.02 on our edges and have for many months during development. We use it for remote access IPsec. We use it in our labs. I personally have about 20 lab systems and most of them have interconnected IPsec tunnels with a variety of configurations.
When I look in the secrets section on the pfsense site I see a different key in the resulting swanctl.conf file /var/etc/ipsec/swanctl.conf which is completely different like so...
secret = 0sVGF.......................dg==
(the '.' are a several dozend of random characters)
Not all, but many start with '0sVGF' and end wih '=='
I haven't seen other reports of anything like that. The secrets are base64 encoded and prefixed with 0s so in your case, the part starting with VGF all the way to the end (including the ==) is the encoded form of the string. If it didn't match, then the config didn't match in some way. Without seeing the whole keys it's hard to say what might have been the case there, but some top suspects would be extraneous characters in the field (extra whitespace, quotes, etc) which made them not match.
That said, I tried running a few different strings through a base64 encoder and I didn't see any that started with VGF.
Is there any way you can try at least loading the IPsec portion of that configuration in a non-AWS system?
It's difficult to tell if it's related to IPsec or if there is a general problem with AWS.
The only other potentially-related report I've seen is a report of a kernel panic on AWS with someone that has even more IPsec tunnels than you, but as far as I'm aware they were not experiencing any slowness or boot delays.
@jgraham5481 This solved my issue where I was seeing something like:
[ESP] ESP sequence number verification failed:
in the Android Strongswan app, but now I can't recreate the error log in the app by removing the Reauth Time. I wanted to recreate the log so I can add it here for accuracy. That's what I get for not even taking screenshot.
I added a value to "Reauth Time", then I removed it. Now Android Strongswan app doesn't show ESP errors in 21.02 after I changed P2 hash to SHA384. More on the hash issue here.
SNATting everything could help, but administer the firewall rules with sourcenatting... I would not like to go down this rabbit hole...
Sure, if the Network of the SA is also directly attached to an interface of the firewall, it should work.
Are you certain this worked on previous versions? It may have been silently rejected / not sent to clients.
I can reproduce the config parsing problem here but I can't find any info in strongSwan about that being allowed. It may have been accepted by the old ipsec.conf config parser and now rejected by the swanctl parser.
I also don't see it mentioned in the IKEv2 config payload RFC that it would be allowed.
If nothing else we could add input validation to reject entering those values since they are now known not to work.
Seems there are several issues here all getting confused.
Identifier issues with "Distinguished Name" (Which is a bug -- see https://redmine.pfsense.org/issues/11442 -- for a quick workaround, apply the patch there or just set your IDs to KeyID in the meantime)
Identifier issues from incorrect use of Key ID in the past (which fell back to automatic guessing at the type, so may not now match a remote not set specifically to Key ID) -- To fix this, set the right ID type and value on both sides to match
Configuration issues where the configuration is failing to load (with errors)
Tunnels loading but not connecting
Other things that haven't yet been identified
Having one thread for all of this is a giant mess that's hard to follow. It's better for the moment if everyone makes their own thread here in the IPsec category and includes as much detail as possible.
If someone else does have a thread for the exact same root issue then you can combine those threads, but this one is far too generic to be useful.
For those of you who say re-creating the tunnel worked, be sure to grab the config.xml and compare before/after as well as /var/etc/ipsec/swanctl.conf -- something must be different if it suddenly started working, and if it's something done by the upgrade process then we can identify and fix it.
For troubleshooting, first apply patches to fix known issues which have already been resolved:
After that, edit/save/apply an IPsec tunnel, then stop and start (not restart) the IPsec daemon, or reboot instead.
If problems persist, do the following:
Edit/save a tunnel
Go to Status > Services and stop, then start the IPsec service (don't click restart)
Go to Status > IPsec on one end and attempt to initiate the tunnel if it doesn't come up automatically.
If it works, great. If not:
Run swanctl --list-conns to see what the IPsec daemon loaded for the connections
Run swanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1 and see if it reports any problems
Get the config from /var/etc/ipsec/swanctl.conf
Get the most recent logs from both sides
With that in hand, check for an existing thread which matches the symptoms exactly. If one exists, post there. If there isn't one, create one.
Locking this so it doesn't keep growing and making things more confusing.
Well, for anyone else that may run into this... the problem was that a Firewall Rule is needed. I was wrong to think that the VPN creation took care of that.
Firewall Rules, IPsec is where it had to be created.
And does this network printer have a gateway set.. I have seen it countless times on customer sites from very small.. To huge corps with hundreds of vlans - printers don't have gateway set. So no you can not talk to it from another vlan.
Had 1 customer - hundreds of printers in the building. Not freaking 1 of them had a gateway.. Only reasons printers worked was of proxy arp set on their core switch..
Bet you beer - printer doesn't have gateway set ;)
@clarknova we saw this in opnsense as after switching to VTI. SMB stopped working over ipsec. hard to track down. it worked like half a year, then problems started and it was kind of reproducible. pings works, SMB browsing too. SMB access timeout. reverting to classic ipsec solved the issue. i assume we did tunnel VTI back then, although the freebsd bug mentions transport mode. maybe it hurts both modes. why i wonder how pfsense is affected by this open freebsd bug as well. i would like to use VTI soon...
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.