Messages

Gute Idee, nur leider zu spät, weil ich das Update schon draufgebügelt habe. Und die ipsec.conf erscheint ja auch korrekt. Deswegen bin ich ja so verwirrt.

Nachdem ich heute eine meiner Firewalls von 18.1.5 auf 18.1.8 geupdatet habe (meine Heim-Firewall), ist genau eine IPsec-Tunnelgruppe durcheinander. Auch das Neuanlegen des Tunnels bringt keine Besserung.

Die Gegenseite ist der letzte noch verbliebene IPcop, dessen Konfig habe ich nicht angetastet.

Die geupdatete OPNsense liegt mit doppeltem NAT hinter einem Unitymedia-Router, dies sehe ich jedoch nicht zwingend als Problem an (alle anderen Tunnels gegen mehrere OPNsense 18.1.5 und eine Sophos UTM rennen problemlos). Ihr LAN ist 172.31.1.1/23, ihr WAN 192.168.150.2/24 mit Gateway 192.168.150.1 (dort ist die OPNsense erfolgreich als DMZ gelistet, und alle möglichen Ports dorthin freigegeben).

Gegen IPcop und Sophos muss ich natürlich mit IKE-V1 arbeiten, also vergleiche ich mal den nicht funktionierenden Tunnel mit dem gegen die Sophos:

/usr/local/etc/ipsec.conf -- hier der Teil gegen die Sophos (es gibt einen weiteren Tunnel in eine andere Zone -- auch OK):

Code Select Expand

conn con6-000
  aggressive = no
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = none
  left = 192.168.150.2
  right = der.sophos-ihre.url
 
  leftid = meine.noip.me
  ikelifetime = 28800s
  lifetime = 28800s
  ike = aes256-sha256-modp2048!
  leftauth = psk
  rightauth = psk
  rightid = XX.XX.XX.XX                  [in der GUI über "Peer-IP-Adresse" zugewiesen -- geprüft und ok]
  rightsubnet = 172.16.0.0/24
  leftsubnet = 172.31.0.0/23
  esp = aes256-sha256-modp2048!
  auto = route


Und der Teil gegen den IPcop mit den vormals funktionierenden Parametern neu angelegt (auch hier gibt es eine weitere Zone auf der Gegenseite -- diese ist auch nicht OK):

Code Select Expand

conn con5-000
  aggressive = no
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = none
  left = 192.168.150.2
  right = dem.ipcop-seine.url
 
  leftid = meine.noip.me
  ikelifetime = 3600s
  lifetime = 28800s
  ike = 3des-sha1-modp2048!
  leftauth = psk
  rightauth = psk
  rightid = 172.31.1.1                        [das ist natürlich ein Fehler, in der GUI über "Peer-IP-Adresse" gesetzt]
  rightsubnet = 172.18.0.0/23
  leftsubnet = 172.31.0.0/23
  esp = aes256-sha1-modp2048,aes192-sha1-modp2048,aes128-sha1-modp2048!
  auto = route


Da die "rightid" definitiv fehlerhaft ist -- der Cop soll sich ja nicht mit meiner LAN-IP identifizieren, sondern mit seiner WAN-IP -- editiere ich die Phase 1 neu und definiere den Peer-Identifier über "IP-Adresse" mit der gültigen IP:

Code Select Expand

conn con5-000
  aggressive = no
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = none
  left = 192.168.150.2
  right = dem.ipcop-seine.url
 
  leftid = meine.noip.me
  ikelifetime = 3600s
  lifetime = 28800s
  ike = 3des-sha1-modp2048!
  leftauth = psk
  rightauth = psk
  rightid = YY.YY.YY.YY                        [einzige Änderung, jetzt sollte es passen]
  rightsubnet = 172.18.0.0/23
  leftsubnet = 172.31.0.0/23
  esp = aes256-sha1-modp2048,aes192-sha1-modp2048,aes128-sha1-modp2048!
  auto = route


Die unterschiedlichen Verschlüsselungs- und Zeitparameter sind den Grundeinstellungen bzw technischen Möglichkeiten der Gegenstellen geschuldet. Die Konfiguration sollte jetzt folglich passen, tut sie aber nicht.

Also schaue ich in die Statusübersicht und sehe (hier beginnt die Absurdität; die Zuordnungen scheinen komplett durcheinander zu sein):

Verbindung	Version	Lokale ID	Lokale IP	Ferne ID	Ferne IP	Lokale Auth	Ferne Auth
Sophos	IKEv1	meine.noip.me	192.168.150.2	XX.XX.XX.XX	der.sophos-ihre.url	pre-shared key	pre-shared key
IPcop	IKEv1	172.31.1.1	dem.ipcop-seine.url	meine.noip.me	192.168.150.2	pre-shared key	pre-shared key

Fazit: Die Verbindung zur Sophos wie auch zu allen OPNsenses (dort mit IKEv2) passen, nur die zum IPcop ist komplett durcheinander. Ist das ein genereller Fehler? Wie bekomme ich di Verbindung wieder hin (die Idee "Den IPcop sofort wegwerfen" ist leider keine gültige Lösung, das wird leider eine etwas umfangreichere Operation, bis ich den umgestellt bekomme)? Und vor allem: Was gerät durcheinander, sobald ich die anderen OPNsenses aktualisiere?

What happened is, in short, that while the respective location was a "full" member of my "IPsec mesh", every tunnel which involved at least one OPNsense was very prone to break down with various error messages in the log and various symptoms on the GUI — long description above  :)

As for the cause, unfortunately I'm not exactly sure (yet). At this location's sense we've been experiencing some other problems, epecially Unbound also crashing (whithout having found the time to investigate why exactly it did so).

There are four possible causes whiih I'll have to investigate:
1. Hardware failure — low probability — it's a Scope7 7525 box, couple of months old, extensively tested at my home (which I always do before bringing a gateway into production)
2. IP address problem — fiber connection by Deutsche Telekom which is shared with another company. Maybe their firewall which resides side-by-side with ours causes conflicts.
3. Cable problem — the quality of the physical cable from the main switch is unknown to me
4. Config problem — reinstall OPNsense (or at least run the setup from scratch).

Well, at least I won't get bored during the next days (as if I ever would... ;D )

It turned out to be caused by one specific OPNsense. After deleting all its VPNs all other tunnels run stable

Our company has a multi-site setup with six locations. In the progress of leaving IPcop behind (which has been discontinued a while ago) I began switching over to OPNsense about half a year ago.

Of those six locations, four have been migrated to OPNsense (three on Lanner x64 hardware, plus the smallest one on an old i386 PC). One location is served by a Sophos UTM (which I decided to keep running as long as the subscription is valid), in the last one IPcop is still running.

There are tunnels configured in every location's gateway so that everything shall be accessible from everywhere. We have static IPV4 addresses at every location which are under control by the respective gateways (i.e. 4x OPNsense, 1x IPcop, 1x Sophos), so no NAT-T should be necessary. The internet access seems to be stable (not aware of dropping connections).

Every OPNsense is running 19.1.3 at this time.

To make a long story short, the connections where IPcop and/or Sophos is involved seem — quite — stable while the OPNsense-only connections have been dropping either at once or after a few minutes. Some connections show as alive on the IPsec status overview while showing as down on the dashboard widget (and technically spoken they ARE down).

The tunnel setup between OPNsenses basically is

Code Select Expand

  aggressive = no
  fragmentation = yes
  keyexchange = ikev2
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = clear
  dpddelay = 10s
  dpdtimeout = 60s
  left = ***LOCALPUBLICIP***
  right = ***PUBLIC.AVAILABLE.REMOTE.URL***
  leftid = ***LOCALPUBLICIP***
  ikelifetime = 28800s
  lifetime = 3600s
  ike = 3des-sha256-modp2048!
  leftauth = psk
  rightauth = psk
  rightid = ***REMOTEPUBLICIP***
  rightsubnet = 172.17.0.0/23
  leftsubnet = 172.31.0.0/23
  esp = 3des-sha256-modp2048!
  auto = start


The log files of the braking tunnels show a whole bunch of what I tend to call "lame excuses", at least to my knowledge.

Any thoughts what's wrong with my setup? I'm just an inch away from deleting and re-creating every single tunnel  :-\

Thanks for this topic. I'm currently in the phase of implementing various OPNsense boxes instead of IPcop and have been wondering why it is mostly the OPNsense-OPNsense VPN tunnels which don't come up again  8)

From a pragmatical point of view: What's wrong with an OpenVPN setup (which seems to work fine)?

I haven't even tried to use IPsec for road warriors since years on either IPcop, sophos-utm and OPNsense due to various caveats I stumbled upon with the various clients (different Windows flavors, OSX, iOS, Android...).

My set-ups have been using IPsec for (static) site-2-site connections and OpenVPN for (dynamic) road warriors ever since, thus drastically reducing support overhead.

Update to myself:

After duplicating the respective phase 2's once again (forward and backward), the problem of all phase 2's showing some strange state (instead of "running") does not occur any more.

In the meantime, I played aroud with the "manual SPD entries" without any success.

This procedure works against an OPNsense as well as IPcop or Sophos UTM on the other side.

Following situation: I'm currently migrating rom IPcop to OPNsense.

We have several sites, all connected together site-to-site with IPsec. For every site, there is a number of connections to every network.

One of the sites worked as a "central" OpenVPN server with push routes to all the other sites' networks. There had been IPsec tunnels to the specific OpenVPN network.

The big advantage is that an employee only has to log into one site and gets access to the complete company network.

For simplicity, let's assume two sites:

Site A
WAN: Static public IP
LAN: 172.17.1.1/23
OpenVPN server (tun) network: 172.17.2.0/24 plus option push "route 172.19.0.0 255.255.254.0"
IPsec LAN to LAN of Site B

Site B
WAN: Static public IP
LAN: 172.19.1.1/23
IPsec LAN to LAN of Site A

With the settings above, no traffic gets routed from road warrior to Site B.

So I added another IPsec phase 2 between the sites (like in the IPcop times).
On Site A local = 172.17.2.0/24 to remote = 172.19.0.0/23
On Site B local = 172.19.0.0/23 to remote = 172.17.2.0/24

In principle, this setup works (and the IPsec tunnels between the two sites still are up), but now, on Site A's OPNsense, all tunnels to Site B are greyed out on the status page — which is very irritating.

Does anyone have an idea of how to solve the issue? Several hours of looking up such a setup via Google did not lead me to a better result.