Messages

I tried `-1` in `keyingtries` to get the `%forever` in swanctl.conf with the current OPNsense production version, but the GUI tells me `-1` is not allowed.

Can anyone point me to the correct setup here for Site-to-Site IPSEC connections to keep trying after any WAN failure?

Yes, my issue was rather that the use of FQDN did not work as PSK Identity. I had to put a user in front of it. Not sure if this is related to the other side, where I use pfSense and maybe the FQDN for PSK ID is first resolved to an IP and then send over, where the match fails. Anyway, with User Distinguished FQDN, this works now.

All seems to work now. Updated my blog post here:
https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/

Doh, I just found out that the new IPSEC Implementation seems not to support FQDN anymore (like I am trying to do)

https://github.com/opnsense/core/issues/6781

> you mentioned your setup worked before this change, dynamic addresses weren't supported before 21.1.4 for the new connections.

After extensive testing today, it seems I am confirming it does not work having a dynamic IP attached to a FQDN/CNAME entry, the connections are failing with "no matching peer config found".

See also this comment: https://linuxnews.de/verschlimmbessertes-vpn-ein-wort-der-warnung-zu-opnsense-deciso/

The problem seems to be that using an dynDNS FQDN CNAME entry as `Local addresses` (e.g.  jashdejvmiuqlachhsqaxs.siteb.example.com), is not acceptable, as the other side sends an actual IP (41.41.41.41), for which the comparison fails.

If I compare the swanctl.conf form legacy to the new, I can see that in the legacy conf, the actual IP was written:

Code Select Expand

        local_addrs = 41.41.41.41
        remote_addrs = 31.31.31.31

whereas if I download the new swanctl.conf, I see the FQDN entry:

Code Select Expand

        local_addrs = jashdejvmiuqlachhsqaxs.siteb.example.com
        remote_addrs = 31.31.31.31

What I am observing here is that if a packet comes in addressed to 41.41.41.41, and the config is jashdejvmi..., even though that resolves to the same IP, the match seems to still fail because strongSwan has not resolved it to 41.41.41.41 and stored that value.

This behavior is mentioned in the GitHub issue #6781. Resolving and using FQDNs in "Local addresses" can cause peer mismatches unless the resolved IP aligns perfectly and is interpreted correctly by the daemon at that moment.

Any suggestions?

[Edit2]

One step further... I changed the FQDN to User distuinguished FQDN (simply put a user in front of my FQDN for PSK identity): user@jashdejvmiuqlachhsqaxs.siteb.example.com).

This came up immediately. I will observe this further and see if it helped..

Interesting. Thanks for the classification! I just started the new connections and it went up flawlessly immediately!

[Edit] After testing, this was probably a leftover observation from a previous (legacy) connection.

Ok, I would have preferred keeping my current WAN IP as the identifier, but I can use the FQDN from the dyndns-url I am using to tell the other side my identity. It will be somewhat off between the time my provider sends me a new WAN address and the time my script was able to update the FQDN dyn dns. I will try. Thanks!

[If both ends should use their own identifier, fill in both local and remote values.]

Thank you. I am reading this section over and over and I can't seem to find the information you're trying to point me to.

There are two paragraphs regarding PSK:

When migrating Pre-Shared Key type tunnels to connections, make sure to add an entry in the "Pre-Shared Keys" module as well. If both ends should use their own identifier, fill in both local and remote values. The legacy module requested this information in the phase 1 page and wrote the same information to the secrets.

This tells me to "fill in both local and remote values", but not how.

Further down it says:

Since OPNsense uses the new Strongswan format also for legacy tunnels, it is rather easy to convert a tunnel manually when downloading the swanctf.conf file from the machine.

But when I download my Legacy swanctf.conf, I can only see my current WAN IP Address - I can't set this IP address as "My identifier", as it will regularly Change. I need some automation to replace the former (legacy) "My IP Address" Feature, which is not available in the new PSK-dialogue.

I heavily rely on my IPSEC site-to-site policy VPN and waited until now to do the legacy migration.

I got until the pre-shared Key step, where in my legacy setup I used "My IP address" for phase 1 (Auth) in the field "My identifier".

In the new IPSEC setup, there is no drop-down for selecting "My identifier". I have a dynamic IP-address on one side, so I cannot enter a static ip address here.
It says:
> This can be either an IP address, fully qualified domain name or an email address.

What do you suggest selecting here, going forward with the migration?

Great, thank you for the confirmation!

I think this was new, which is why radvd not starting caught my eye and got me worried.

Thank you. So this means this is normal and should be expected, when IPv6 is disabled?

Since the last update, my radvd is not starting. It looks like playing with IPv6 (and finally disabling it again), I have  recurring problems with the DHCPv6 and radvd service.

Tried to reset everything following https://forum.opnsense.org/index.php?topic=34584.0 this did not solve my issue. radvd still not starting, even if clicked manually. There is also no error in logs.

When following the above guide, I got:

Code Select Expand



2023-12-17T08:06:34 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb3'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:31 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb2'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:27 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb1'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'


But I cannot assign this to any specific action.

Where would I start debugging starting of radvd?

@Patrick M. Hausen, @franco - many thanks for the explanation! Indeed, I expected I was _wrong_, was just looking for this piece of information. Maybe discussions like these help at some point make the gui or docs more self-explanatory. Of course, nothing helps against ignorant users (I hope I am not one of them).

You can create your own script to push/update using a custom DNS API. I've added an example (Cloudflare) here:
https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/#dns-setup

(because the Cloudflare implementation available through OPNsense plugins did not work)

Thanks for the clarification. There were a lot of changes and bug fixes to IPv6 recently and it is difficult to find the correct answers, as everybody seems to have different issues.

Yes! That was it - I had to set the Prefix to /56, as Telekom apparently hands out 56 Prefixes:
https://www.heise.de/news/Details-zu-IPv6-ueber-Telekom-DSL-1762367.html

I used the standard ID 0 for my LAN subnet and it works! Note that I had to completely restart my OPNsense.

Thank you very much, @bartjsmit

[igb1:]

I have continuing problems with IPv6 setup in OPNsense. It works for 1-2 days after a restart, but then stops working.

Today I found the following logs under:
/ui/diagnostics/log/core/routing

> Warning   radvd   prefix length should be 64 for igb3
> Warning   radvd   prefix length should be 64 for igb1
> radvd   sendmsg: Network is down
> Warning   radvd   prefix length should be 64 for igb3
> Warning   radvd   prefix length should be 64 for igb1
> radvd   sendmsg: Network is down
> ...

Since I use "Track WAN" for IPv6 on both, and WAN is setup with /64, this does not make sense to me.

Under /status_interfaces.php, I see the following values:
igb1:
IPv4 address   192.168.100.1/24
IPv4 gateway   auto-detected: 192.168.100.1
IPv6 link-local   fe80::2e0:67ff:fe2a:72e4/64
IPv6 address   2003:e7:1f0c:8e00:2e1:37ff:fe2a:72e4/56

igb1 (lan) is configured with:
IPv6 Configuration Type - Track Interface
IPv6 Interface - WAN

wan:
DHCP           DHCPv6 up 
PPPoE                up
MTU                    1492
IPv6 link-local   fe80::2e0:67ff:fe2a:72e3/64
IPv6 address   2003:e7:1fff:d24:2e1:37ff:fe2a:72e3/64
IPv6 prefix   2003:e7:1f0c:8e00::/56
IPv6 gateway   auto-detected: fe80::224e:71ff:fe11:2cfe

My IPv6 configuration for WAN follows the DHCPv6 instructions in the docs:
IPv6 Configuration Type - DHCPv6
Request only an IPv6 prefix - yes
Prefix delegation size - 64
Send IPv6 prefix hint - yes
Use IPv4 connectivity - yes
Use VLAN priority - Disabled

How can I go further to debug this? Why does my LAN (igb1) has a /56 IPv6 address, when WAN has a /64 IPv6 address?

The same is reported here on Reddit, for the exact same ISP (Telekom).