Problem migrating from Legacy to current IPSEC, VPNs don't survive reboot

[NevadaTech]

I believe I built the VPN properly, it seems to work for a few weeks or so without issue. Then I reboot a router on one side of the VPN and I cannot get the IPSEC back up. I've kinda resolved to deleting both sides, restarting the IPSEC service on both routers, and then rebuilding the VPN again.

Big picture, I'm trying to convert the Legacy VPNs over to the new Connection type. This VPN issue is my big hold-up. I can't get a VPN that survives a reboot.

Mainly it is 6 routers connecting to a main office. Some of the remotes also connect to each other. The multi-connected routers can have one new Connection style VPN that works while another does not.

The log file shows

• generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
• received AUTHENTICATION_FAILED notify error
• received 1 cert requests for an unknown ca

The setup is rather basic.

• build a PSK on each side with matching key
• build a new VPN> IPSEC> Connection
• the Parent/phase1 is only updated with a description
• the Child/phase2 has the local segment IPs and encryption scheme, all other info is default/empty
• some VPNs (Child/phase2) connect to multiple segments on one side, most are single segment
• some public IPs are static with a DNS entry somewhere vpn.acme.com or vpn.roadrunner.com
• other public IPs are DHCP from ISP, these are linked to DDNS like coyote.duckdns.org

The hardware is old - AMD 5350 CPUs and HP NC364T quad LAN cards (Intel 8253?) and APU-2E4 AMD Embedded GX-412TC i210AT.

• is the issue the encryption scheme doesn't work with these devices
• with 'Legacy' VPN configuration they work fine
• most OPNsense are 25.7_9
• my home router is 26.1_10

A bunch of questions that have come up from my troubleshooting

Should LocalID be the same as LocalIP?

• I've read some posts which say it doesn't matter
• others that say they need to be different
• I haven't been able to get the VPN to work using a FQDN like vpn.acme.com

Should PSK be PSK or EAP?

• one post said the failure (AUTH_FAILED) is tied to no address info in a PSK and to try EAP
• I did change one link to EAP on both sides, no change, still failed

Do I need to import a cert or ca into Trusts then select it in the Parent/phase1?

Again the big frustration is everything works, data flows back and forth until a reboot.

[sweepingkitchen]

I believe I built the VPN properly, it seems to work for a few weeks or so without issue. Then I reboot a router on one side of the VPN and I cannot get the IPSEC back up. I've kinda resolved to deleting both sides, restarting the IPSEC service on both routers, and then rebuilding the VPN again.

Big picture, I'm trying to convert the Legacy VPNs over to the new Connection type. This VPN issue is my big hold-up. I can't get a VPN that survives a reboot.

Mainly it is 6 routers connecting to a main office. Some of the remotes also connect to each other. The multi-connected routers can have one new Connection style VPN that works while another does not.

The log file shows

• generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
• received AUTHENTICATION_FAILED notify error
• received 1 cert requests for an unknown ca

The setup is rather basic.

• build a PSK on each side with matching key
• build a new VPN> IPSEC> Connection
• the Parent/phase1 is only updated with a description
• the Child/phase2 has the local segment IPs and encryption scheme, all other info is default/empty
• some VPNs (Child/phase2) connect to multiple segments on one side, most are single segment
• some public IPs are static with a DNS entry somewhere vpn.acme.com or vpn.roadrunner.com
• other public IPs are DHCP from ISP, these are linked to DDNS like coyote.duckdns.org slope 2

The hardware is old - AMD 5350 CPUs and HP NC364T quad LAN cards (Intel 8253?) and APU-2E4 AMD Embedded GX-412TC i210AT.

• is the issue the encryption scheme doesn't work with these devices
• with 'Legacy' VPN configuration they work fine
• most OPNsense are 25.7_9
• my home router is 26.1_10

A bunch of questions that have come up from my troubleshooting

Should LocalID be the same as LocalIP?

• I've read some posts which say it doesn't matter
• others that say they need to be different
• I haven't been able to get the VPN to work using a FQDN like vpn.acme.com

The fact that you cannot get it working with FQDN makes me wonder if the ID mismatch is the problem.
Should PSK be PSK or EAP?

• one post said the failure (AUTH_FAILED) is tied to no address info in a PSK and to try EAP
• I did change one link to EAP on both sides, no change, still failed

Do I need to import a cert or ca into Trusts then select it in the Parent/phase1?

Again the big frustration is everything works, data flows back and forth until a reboot.

[NevadaTech]

Sure enough, yesterday was a maintenance day. I took the main router down for 20mins. When I got home my VPN to the main site was offline. Tried a couple changes, nothing. Completely deleted the PSK and the Connection on both sides, restarted the VPN/IPSEC service on my side, rebuilt on both sides, and it connected.

Sadly, my home office also has a link to a remote site (not main) which has been up and working for weeks is now down.

[NevadaTech]

Today's testing was one of the remote sites dropped their IPSEC VPN

• I tried going into IPSEC> Connections and de-selected the Enable option; I gave it 5-7 mins, hoping the a new timed key would regenerate, enabled both sides; nope, still bad
• I tried changing just the PSK (just the key, not the IDs) on both sides; nope, still bad
• restarted the IPSEC service on the remote site's side a couple times; nope, still bad
• gave up, deleted the PSK and the Connection; rebuilt on both sides; back up

Currently I'm using the 'default' in proposal. Someone said if you have an Intel nic you can select the whole AES256GCM16 type of encryption and it will offload the processing to the nic, not the CPU. Does anyone know if this it true? When AI'd if the i210AT supports this mega-mind said NO, then I rephrased the question and it said YES. I don't see this support in Intel's doc so I'm guessing no.