Messages

Its just a hunch but can you try this if you are on 25.7.1

# opnsense-patch https://github.com/opnsense/core/commit/e18a9e9261146b16bf10d937df123681c3640a0d

My Caddy plugin was really slow too and we tracked it down to this.

ISC dhcp does not occupy port 53.

DHCP - Port 67
DNS - Port 53

So probably Unbound.

Follow this:

https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

Bitte auch die ESP regel nicht vergessen, sonst nix geht.

I think that makes sense, I do not think it should return true when it is still connecting, and not connected.

Best to ticket that to github if you can.

The widget shows the same status as:

/ui/ipsec/sessions

Which calls

/api/ipsec/sessions/search_phase1

And in there if:

"connected":true

Then it shows Phase1 as green.

Maybe it could be refined by checking

"connected":true,"install-time":null

that install-time is not null as well?

Sure it sounds a little weird, best to track it in an issue.

You can open an issue, but generally its explainable:

Charon binds to:

root@opn-dev-01:/var/lib/php/tmp # sockstat -l | grep 500
root     charon     41968 13  udp4   *:500                 *:*
root     charon     41968 14  udp4   *:4500                *:*
root     charon     41968 15  udp6   *:500                 *:*
root     charon     41968 16  udp6   *:4500                *:*

Which means it uses the wildcard interface.

Then it uses these defaults to determine where to send traffic:

https://github.com/strongswan/strongswan/blob/master/conf/plugins/socket-default.opt

This here is enabled:

charon.plugins.socket-default.set_source = yes
   Set source address on outbound packets, if possible.

This means it will use the IP address in "local" if it exists on the system, otherwise it falls back to the current routing table, thus using the current default gateway route (usually WAN).

I just tested it and the least to reproduce is to create a Connection with an IP address that is not locally bindable by the OPNsense

root@opn-dev-01:/src/git/core # swanctl --list-sas
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
1f464073-5838-4257-83ff-d380e51b3ef0: #4, CONNECTING, IKEv2, 52b58b71a1a741db_i* 0000000000000000_r
  local  '%any' @ 10.20.30.1[500]
  remote '%any' @ 192.168.2.3[500]
  active:  IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG IKE_AUTH_LIFETIME IKE_MOBIKE IKE_ESTABLISH CHILD_CREATE

I don't have "10.20.30.1" on a firewall interface, but strongswan tries to connect anyway.

It uses the current WAN interface:

WAN
hn1   2025-08-12
09:20:33.926844   00:15:5d:00:ad:06   f4:90:ea:00:d9:f4   IPv4, length 1014: 172.16.1.110.39503 > 192.168.2.3.500: UDP, length 972

It looks like even if there is no bindable address it will fall back to the default gateway and send packets out.

Mobike does not influence this. So no clue yet, but wanted to share.

Please ensure your setup follows the best practices outlined here:

https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

You probably leak multicasts/broadcasts due to tagged and untagged vlans on same interface.

What I assume is that the backup got the CARP IP of the "local" in the SA at some point and strongswan tried to establish phase 1 during that (maybe brief) timeframe. And now it is just stuck trying to connect.

Does it still try to connect if you disable and enable the IPsec service on backup?

What does:

swanctl --list-sas

show on the backup?

Is that cors block always the same or application dependent?

Here is a setup that might be interesting for reference:

https://docs.opnsense.org/manual/ndproxy.html#offering-services-behind-nat-cloud-setup

Its okay I might add it to the subdomain as things have changed in the template in the latest caddy versions.

Just create another wildcard domain.

E.g you have

*.example.com:443
*.example.com:8443

then you create the subdomain you need under the 8443 wildcard domain. Then create the handler for that subdomain.