Ad Schellevis

In most cases you can bind the service to a loopback address and use a `rdr` (port forward) to offer the flexibility, which is a best practice anyway. Bindings (such...

@Zerophase upstream is FreeBSD ports (https://github.com/freebsd/freebsd-ports/tree/main/net/shadowsocks-libev), their bug tracker is available at https://bugs.freebsd.org/bugzilla/ (https://www.freebsd.org/support/bugreports/)

doesn't look like anything changed here in this version, but the rule suggests a protocol mismatch between the legacy phase 1 entry and the remote gateway address. https://github.com/opnsense/core/blob/57184b24e6591be09d438a19351b2cc8ded749c0/src/etc/inc/plugins.inc.d/ipsec.inc#L272 When using...

best check the phase one settings first, my assumption would be that remote host is a dns entry which doesn't resolve on ipv4 (anymore?)

how is `Site1_Site2_IPV6` configured? specifically `Remote gateway` and `Internet Protocol` are relevant in this case.

the `Site1_Site2_IPV6` is the tunnel triggering the error (and preventing the ruleset to load)

> Is the commit a modification to source code? yes, but most likely to prevent misconfigurations to generate faulty rules (which prevent the firewall loading the configuration). The (exact) settings...

as mentioned earlier, code seems to be the same on the IPsec part, sharing the settings of `Site1_Site2_IPV6` might help debug your issue, if the `rules.debug` errors are causing your...

a screenshot of the `Site1_Site2_IPV6` phase one settings might already be enough.

I would expect internet protocol being set to ipv4.... hence the question