@jimp Thanks Jim

https://redmine.pfsense.org/issues/11526

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.

Just as an update, this is working well now.

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?!!!

Thanks again :)

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. user@example.com) – 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 "user@example.com" and got it working.

@sgw I can confirm disabling hw crypto on our SG-1100 running 21.02 fixed our tunnels to a Sonicwall. We had the same issues as the OP, tunnels connected but no traffic flowing inside.

Check the detail of the firewall states (pfctl -vvss) between the IPsec endpoints (so the WAN/public addresses) and see if there is any change in the states from when it works vs when it doesn't.

~5 minutes is suspiciously around a default state timeout for a state which only has traffic in one direction, which sounds sort of like asymmetric routing somehow.

Also are these IPsec tunnels all on the WAN with the default gateway? Or are they on an alternate WAN?

@4920441-0 said in IPsec IKE secrets not written properly:

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.

@4920441-0 said in IPsec IKE secrets not written properly:

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:

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.

Thanks again!

-LamaZ

@ldoodle

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.

Cheers.

4920441

1. Floating IP

Solution: add the floating IP as virtual IP and then it can be chosen in IPsec Phase 1 "Interface" dropdown.

I split this off into its own thread.

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.

I opened https://redmine.pfsense.org/issues/11446 to fix the validation.