@dalicollins Sad but true! There is nothing quite like a tongue lashing from one of the Gurus. Ted Quade

@renegade said in IPSec Issue After 23.01 Upgrade: I have an ios device with ipsec to my 4100. After activation the tunnel works fine. When the iphone gets in standby (no user interaction) the 4100 reboots without any error message or crash dump :-( That wouldn't be related to this thread, so you should start a new one just for that. And there would have to be either an error message or a crash dump somewhere, even if it's only printed to the serial console. You should attach a serial console client and log all the output while you try to make the crash happen again.

I was finally able to solve this by: Setting my Local Network as my actual local network rather than the Virtual IP in the Ph2 config. Then, I set the NAT/BINAT translation option to what the required source IP must be for the IPsec tunnel. Didn't even need Virtual IP or NAT rules for any of it 🥴

@viragomann thank's again! I will try it asap and come back with the results!

Turns out my issue was within phase 2 on the tunnel. I mistakenly unchecked "SHA384". Smh...... Just wanted to share.

hi @efriedman ，thank you for your advice. I will try to switch to WireGuard.

@itou-0 glad to hear it but that doesn’t make much sense. The drive isn’t involved in routing unless the firewall rule is logging every packet. (Shrug). Maybe the drive was dying?

The log the problem is in con4 pfsense_erro_ipsec.txt Someone can help?

Hi Jeff In the Advanced Settings tab of the IPSec tunnel under Advanced IPSec Settings change "Configure Unique Ids as " from Yes to Never. This should ensure that for each new connection it doesnt kill the previous connection for same user. Kind Regards Description of Setting "Whether a particular participant ID should be kept unique, with any new IKE_SA using an ID deemed to replace all old ones using that ID. Participant IDs normally are unique, so a new IKE_SA using the same ID is almost invariably intended to replace an old one. The difference between no and never is that the old IKE_SAs will be replaced when receiving an INITIAL_CONTACT notify if the option is no but will ignore these notifies if never is configured. The daemon also accepts the value keep to reject new IKE_SA setups and keep the duplicate established earlier. Defaults to Yes."

@geyser So the remote site says that it doesn't accept the additional phase 2. So I'd suspect that it's not configured there or has different parameters.

Changing the MTU to 1460 & MSS to 1432 solved the problem

I had similar problems and changing the MTU to 1472 allowed traffic to pass

@dehaas I had similar problems and changing the MTU to 1472 allowed traffic to pass