I'm about to migrate 25.7.8 IPsec configuration from legacy tunnels to the new connections mode. I read the migration hints at https://docs.opnsense.org/manual/vpnet.html#migrating-from-tunnels-to-connections using the sdwanctl.conf download & comparison method. Seemed pretty straight forward. But the new config fails to work at all.
Few important things to notice: my local opnsense sits behind NAT-T, so my CARP-IP and my identifier are not identical. Beside of the installed policy routes, there must be a 1:1 rule in between my local BGP running in the opnsense os-frr module (10.205.11.1) and the BGP peer on the other end (10.205.208.30), otherwise all routes back to my environment wouldn't work - it initially only knows the BGP route and nothing else. The other end claims either the BGP peer on my end could not be contacted (no TCP 179 traffic in logs) and/or the tunnel is not established at all. The shared secret is 100% accurate.
this is my running and working legacy config according to export file:
connections {
con4 {
unique = replace
aggressive = no
version = 2
mobike = yes
local_addrs = 10.205.11.1
local-0 {
id = 195.62.45.163
auth = psk
}
remote-0 {
id = 13.95.14.84
auth = psk
}
encap = no
remote_addrs = 13.95.14.84
proposals = aes256-sha256-modp1024
children {
con4 {
start_action = trap
policies = yes
mode = tunnel
sha256_96 = no
local_ts = 0.0.0.0/0,10.205.11.1
remote_ts = 10.205.208.0/21,10.205.208.30,10.205.72.0/22,10.205.92.0/22
reqid = 63
esp_proposals = aes256-sha256-modp1024
life_time = 27000 s
}
}
}
}
pools {
}
secrets {
ike-p1-0 {
id-0 = 13.95.14.84
secret = xxxx
}
}
this is my migrated counterpart:
connections {
a2840a37-e9f9-413d-804c-27c20b2eb2e6 {
proposals = aes256-sha256-modp1024
unique = replace
aggressive = no
version = 2
mobike = yes
local_addrs = 10.205.11.1
remote_addrs = 13.95.14.84
encap = no
send_certreq = no
send_cert = never
local-36f8606f-f753-447c-b540-f13b16e388d9 {
round = 0
auth = psk
id = 195.62.45.163
}
remote-17e2d106-2cbd-4618-aff5-556002a6d703 {
round = 0
auth = psk
id = 13.95.14.84
}
children {
631762c1-93bc-4c8d-8b85-e632d87d0dab {
reqid = 1000
esp_proposals = aes256-sha256-modp1024
sha256_96 = no
start_action = trap|start
close_action = trap
dpd_action = trap
mode = tunnel
policies = yes
local_ts = 0.0.0.0/0,10.205.11.1
remote_ts = 10.205.208.0/21,10.205.208.30,10.205.72.0/22,10.205.92.0/22
rekey_time = 3600
updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 631762c1-93bc-4c8d-8b85-e632d87d0dab
}
}
}
}
pools {
}
secrets {
ike-246570cb-9b0f-40b9-91d2-eee09afabd4e {
id-0 = 10.205.11.1
id-1 = 13.95.14.84
secret = xxxx
}
ike-159cd80d-4fb5-479f-b263-8a7b74292b33 {
id-0 = 195.62.45.163
id-1 = 13.95.14.84
secret = xxxx
}
}
Can someone give me some advice where my copy & paste artwork has gone in such faulty wrong direction? Do I have to put in more details in case of NAT-T? I added the shared secret with both the local IP and the NAT identitier, just to make sure. With just one of both, it worked even worse for phase 2. The original legacy-based configuration was created using the opnsense UI years ago, with no customizations beyond that.
I'm lost.
Thank you!
Thorsten
BTW: 25.7.8