Messages

I observed a similar behavior as I did some tests with Wireguard. But, in between there have been several updates applied to my Opnsense instance. So, I do not know whether this is the reason that Wireguard interfaces now begin with "wg1". This behavior initially has no negative effects as long as the assignment of the interface in the firewall is correct.

Der Lancom ist Exposed Host der  Fbox also sollte Portforwarding ok sein.

Sollte auf der Fritzbox der IPsec-Dienst aktiv sein, wird die Fritzbox den UDP-Port 500 (und ggf. 4500) terminieren und nicht an den exposed Host weiterleiten. Dann wäre eine Initiierung des IKE-Handshake nur ausgehend möglich.

Der Lancom kann Ipsec Tunnel zu anderen Lancoms aufbauen - also funkt die Fbox offensichtlich nicht dazwischen.

Siehe oben.

Nattraversal ist auf beiden Seiten OPNsense und Lancom aktiv.

Laut Doku der OPNsense ist man IKE2 verwendet Nat-T standardmäßig  immer aktiv.

Nein. Die Erkennung für NAT-T ist bei IKEv2 standardmäßig aktiv. Damit NAT-T funktioniert, müssen es beide Endpunkte jedoch im IKE-Handshake signalisieren und eine Kommunikation über UDP-Port 4500 möglich sein.

Am einfachsten ist es, ein Netzwerkdiagramm und die Konfiguration bereitzustellen. Weiterhin kann eine Überprüfung der IKE-Kommunikation mittels Wireshark hilfreich sein. Ohne detaillierte Informationen ist eine Hilfe schwierig.

I had a similar issue some days ago. The bare metal LAN interface (intel) of my VoIP network lost the carrier and dropped its IPv4 address. A reboot solved the issue. But I don't know if this issue is related to yours.

Hast Du IPsec auf der Fritzbox deaktiviert und die Ports UDP/500 und UDP/4500 an den Lancom-Router weitergeleitet? Auf der Opnsense und im Lancom bitte zusätzlich NAT-T aktivieren.

Falls es dann nicht läuft, bitte zunächst prüfen, ob die UDP-Pakete der o.g. Ports auch beim Lancom-Router ankommen

Info: ticket raised in the strongswan project: https://github.com/strongswan/strongswan/issues/1635

Update:
As discussed with one of the strongswan maintainers raising an issue in the strongswan project is not correct, because the IPsec stack is covered by FreeBSD itself. I'll try to discuss the bug via the FreeBSD bug tracker

[$]

I did an additional test with the failing command on Opnsense:

  $ dig +notcp -b 10.2.100.1 @192.168.1.1 fritz.box

I redirected the DNS request from Opnsense to the Fritzbox (through the IPsec tunnel) to a transparent UDP proxy running on a client computer which itself forwards the requests. Doing so, everything works well. So my conclusion is, that there is something broken with correct processing of the IPsec security policy in conjunction with the routing to a local endpoint. I think, I have to raise a ticket in the strongswan project.

I don't really understand what you try to do. IPsec has nothing to do with OpenVPN, these are completely different technologies. Regarding IPsec the client has to connect to the Opnsense endpoint 192.168.178.3

As mimugmail already mentioned for roadwarrior you need to set the start_action to "default" (or "none"). Additionally, if authentication fails, please remove "my identifier" in phase 1.

Indeed, this behavior is really strange. The only idea I actually have is that somewhere probably a race condition occurs. The next step I'll try is to enable sysctl "net.inet.ipsec.debug" to get more insights via dmesg, provided that the kernel or the ipsec module has debugging support compiled in.

No, it is not less secure.

The only more theoretical aspect can be that an attacker manipulates the DNS used for establishing the IPsec tunnel to your endpoints. But, this only affects availability and not confidentiality and integrity of exchanged data.

[without any secrets]

The easiest way is to post your tunnel configuration without any secrets.

see file '/usr/local/etc/swanctl/swanctl.conf'

An IPsec tunnel is agnostic of the protocol inside. As long as it's IP. Use tcpdump to trace the packets:

Thanks for your answer. That's clear but does not solve the problem

source incoming interface
source tunnel interface
destination tunnel interface
destination outgoing interface

They get lost or are blocked SOMWHERE. Depending on that somewhere a firewall rule, NAT rule, ... might be at work here.

It looks like you haven't read the whole thread because the issue only occurs sporadically and firewall rules, NAT rules and state table entries are fine.

Is anybody using IPsec site-to-site connections together with UDP inside the tunnel or can anybody give me a hint how to debug further?

I did some further investigation but still not have a clue why the response packets do not reach the socket.

• I decoded and checked integrity of all IPsec packets in wireshark:
  
  
  
  • The MAC (Message Authentication Code) was valid
  • Wireshark was able to successfully decode all IPsec packets
  •    -->Result: Fritzbox operates correctly
  
  
• Dumping the SPD entries (setkey -DP) of the IPsec connection on the Opnsense console showed the following:
  
  
  
  • DNS request with UDP: "last used" entry of SPDs is only update in direction Opnsense -> Fritzbox, not in the other direction. This shows the response packet has been dropped
  • DNS request with TCP: "last used" entry of SPDs are updated in both directions. Response packets are successfully delivered back to the socket (dig command)

Does anybody have an idea how to debug further?

no IPv6 - pure IPv4

What do you exactly mean with above statement? If I read the log correctly, you are trying to establish an IPsec tunnel over IPv6 with NAT-T.

I switched of NAT-T in the OPNsense GUI and restarted strongswan.

AFAIK charon does not support disabling NAT-T even if the parameter is set/unset. You can try disabling MOBIKE or forcing the client to disable NAT-T.