Messages

anyone?!?

BTW: 25.7.8

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:

Code Select Expand

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:

Code Select Expand

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

We're using the squid module on 25.1.5_5 and require user authentication. An access server of type Radius is configured and this was working properly before upgrading OPNsense somewhere around the April timeframe. The NPS Radius server (Microsoft Network Policy Server) now logs "An Access-Request message was received from RADIUS client x.x.x.x with a Message-Authenticator attribute that is not valid." and therefore all requests are denied. Any idea how to rollback or change otherwise?