Messages

[Recommendations:]

• Site-to-Site with IKEv2: Authentication based on "Mutual RSA"
  
  
  
  • "My Certificate Authority" has a confusing description and maps to "rightca" configuration option. The parameter should be named to "Remote endpoint authentication CA"

In fact, I think the naming could be improved in some points. The current naming is sometimes confusing.

• ...
• Roadwarrior with IKEv2: Authentication based on "Mutual RSA + EAP-MSCHAPv2"
  
  
  
  • There is no possibility to configure which remote endpoint certificates are acceptable (neither leaf certificates or certification authorities) and no corresponding "rightcert" or "rightca" configuration options are placed in the ipsec configuration file. I do not know, how this is handled by strongswan. I guess, in this situation all remote endpoint certificates which belongs to any trusted CA are accepted. This could be a big security risk.

You're right! I checked my ipsec.conf and neither "rightcert" nor "rightca" are configured.  :o
According to StrongSwan docs any valid certificate issued by one of the trusted CAs in /etc/ipsec.d/cacerts can be used by the peer if no rightca parameter is present.

Indeed, we shouldn't like that.

Recommendations:

• Adapt the gui to follow the strongswan configuration file in ways that parameters like "leftauth, rightauth, leftcert, rightcert, rightca" etc. are configurable on a per connection basis
• Separate authentication rounds for IKEv2 (xauth for IKEv1 respectively), e.g. "Auth 1: Mutual RSA" and "Auth 2: EAP-MSCHAPv2" instead of "Auth: Mutual RSA + EAP-MSCHAPv2"
• Allow configuring multiple dedicated roadwarrior connections with their own IP pools
• Move from deprecated "ipsec.conf" to "swanctl" (swanctl.conf and strongswan.conf")
• Make strongswan aware of revoked certificates (can be challenging). For now, users probably feel secure in case they revoke certificates of compromised private keys within the trust center. ???

Very good recommendations.

A revision of the StrongSwan implementation and improvement of the configuration options in OPNsense is definitely required. On this occasion we should switch from deprecated ipsec.conf to swanctl.conf.

Ok, mein erster Test war natürlich Müll. Netzwerkkabel vom Glasfasermodem abziehen war zu einfach gedacht. Da verschwindet ja das ganze pppoe0-Interface.

Mal schnell das ganze über den Switch geleitet, so dass das pppoe0-Interface nicht verloren geht, wenn ich das Netzwerkkabel ziehe.

Und ja, die alten Adressen werden nun als deprecated markiert. Funktioniert also wie gedacht.

Sorry für die Verwirrung.

Lass mich kurz noch was testen...

Mal eben kurz getestet auf OPNsense 21.1.7_1.

Sieht gut aus. Die alten (ungültigen) IPv6-Adressen wurden restlos von der Schnittstelle entfernt.

I've done a few tests with OPNsense 19.7 to rule out that the problems were introduced with a newer version of OPNsense.

However, the results are the same. While the IPsec tunnel runs smoothly with IPv4, it does not work when using IPv6. Packet dump shows IPsec traffic arriving on the WAN interface. However, somehow packets are not processed and passed on by OPNsense.

Does anyone have any idea what a detailed analysis might look like? Is there some kind of debug mode?

Which NIC is affected? Both or just the X553 or I210?

Maybe related to this...
https://forum.opnsense.org/index.php?topic=18754.msg109387#msg109387

I've found a similar issue regarding slow transfers with iflib in TrueNas which has been solved.

Maybe we're facing the same issue here in OPNsense.

Please have a look at the following links/commits:

• https://jira.ixsystems.com/browse/NAS-107593
• https://reviews.freebsd.org/D27683
• https://reviews.freebsd.org/R10:81be655266fac2b333e25f386f32c9bcd17f523d

Maybe there is an expert here who can review the code snippets.

I really hope this issue can be solved soon.

I had similar issues with Win 10 RDP in the past.

In my case it was the following problem:

In Windows 10 there is a issue where once you establish RDP connection to the machine the screen will freeze after some time randomly and you have to disconnect and re-connect the RDP session. To fix RDP connection freezes in Windows 10 you need to disable UDP protocol from RDP client using local Group Policy.

https://www.mustbegeek.com/rdp-connection-freezes-in-windows-10/

For the Strongswan Android app we have to keep in mind that the app runs with reduced privileges. It can't open RAW/PACKET sockets. Hence, it is limited to use UDP-encapsulated ESP, which it sends/receives via the UDP sockets used for IKE. So UDP-encapsulation is always enforced, even if there is no NAT between client and server, by sending a random NAT-D payload.

Sill no problems on my end with AES-NI and SHA256.

Have you ever tried AES-GCM instead of AES?

Seems to be an issue with AES-NI and/or SHA256.

https://forum.opnsense.org/index.php?topic=18918.msg104535#msg104535

Interestingly, I am not having these issues on my Supermicro A2SDi-4C-HLN4F. Currently, running multiple IPsec tunnels with AES-NI and SHA256.

Have you ever tried AES-GCM?

Ich kann das Problem bei mir reproduzieren.

Wie schnipp ausgeführt hat, bleiben die bisherigen (ungültigen) IPV6-Adressen weiterhin an der Schnittstelle hängen und führen zu Problemen.

Bei einer Neueinwahl sollten daher wie vorgeschlagen alte IPv6-Adressen restlos von der Schnittstelle entfernt werden.

Den Code-Vorschlag aus dem Github-Ticket kann ich soweit nachvollziehen. Damit würde es funktionieren. Evtl. hat jemand noch einen eleganteren Vorschlag, damit man nicht in einer Schleife alle IP-Adressen nacheinander durchlaufen muss...

Github ticket can be found here now: https://github.com/opnsense/core/issues/4942

[Auto-added VPN rules do not take the global firewall setting "Disable reply-to on WAN rules" into account.]

Dear all,

I have a working IPsec VPN setup with multiple site2site and roadwarrior tunnels. Currently, I only use IPv4 for my IPsec connections. Works like a charm. To make my setup more future-proof I'm a currently testing IPv6 IPsec connections. This is exactly where the problems start...

To make a long story short: IPv6 IPsec connections cannot be established.

A packet capture shows that the OPNsense responds to incoming ISAKMP traffic. However, response packets never reach the IPsec originator. It looks like the IPv6 gateway drops the packets for whatever reason.

Further research in the forum put me on the right track. The problem seems to be related to reply-to which by default is added to every WAN rule.

Hence, I disabled reply-to on WAN rules under Firewall -> Settings -> Advanced. However, that did not bring the desired success. ISAKMP response packets still do not reach the IPsec originator.

I digged a little bit deeper, disabled all auto-added VPN rules and started from scratch with my own firewall rules. And lo and behold... it works!

In the end I could pinpoint the problem. Auto-added VPN rules do not take the global firewall setting "Disable reply-to on WAN rules" into account.

Despite disabling reply-to auto-added VPN rules are still being generated with a reply-to expression:

pass out log on pppoe0 route-to ( pppoe0 fe80::xxxx:xxxx:xxxx:xxxx ) proto udp from {any} to {any} port {500} keep state label "37[...]c7" # IPsec: Mobile Devices

pass in log on pppoe0 reply-to ( pppoe0 fe80::xxxx:xxxx:xxxx:xxxx ) proto udp from {any} to {any} port {500} keep state label "27[...]81" # IPsec: Mobile Devices

Unless someone provides a good reason why that is so, I have to assume that this is a bug.

Guter Hinweis bzgl. MOBIKE. Die FritzBox spricht ja kein IKEv2, insofern ist das unproblematisch.

NAT Traversal ist zwar nicht zwingend erforderlich, behindert den Tunnel aber auch nicht wirklich. Hab es gerade ausprobiert. Funktioniert.

Ansonsten kann ich nicht wirklich viel Falsches an Deiner Konfiguration entdecken.

Aber ein paar Anmerkungen hätte ich. Connection method würde ich von "default" auf "Start on traffic" umstellen. Die Einstellung "default" setzt den strongswan-Paramter auto auf "start". Das führt u. U. zu folgendem Problem:

CHILD_SAs configured with start_action=start (or auto=start) will automatically be established when the daemon is started.  They are not automatically restarted when they go down for some reason. You need to specify other configuration settings (dpd_action/dpdaction and/or close_action/closeaction) to restart them automatically, but even then, the setup is not bullet-proof and will potentially leak packets.

Bei den Einstellungen für den Mobile Client würde ich auf IKEv2 und MOBIKE setzen. Das sollte das IPhone beherrschen, oder?

Kann es daran liegen das ich gleichzeitig auch ipSec für's iPhone zur Verfügung stelle?

Kann ich mir nicht wirklich vorstellen. Bei mir laufen site2site zu einer OPNsense, site2site zu einer FritzBox sowie Mobile VPN nebeneinander ohne Probleme.


Wie hast Du die FritzBox konfiguriert? Einrichtungsassisstent verwendet oder eigene VPN-Konfigurationsdatei erstellt und importiert?