Topics

1

22.1 Legacy Series / [Solved] 22.1.10 IPsec tunnels not showing up

« on: July 16, 2022, 09:34:53 am »

Norning all,

I just updated one of my OPNsenses from 21.1.8 to 21.1.10 and found that my IPsec tunnels (net-net) are not showing up any more. Neither in the dashboard applet nor in the status overview. Also the log file is not accessible from the GUI.

The corresponding tunnels are up and running, though, which means I can access the site and vice versa can access remote resources from this site. So technically spoken not a critical problem of operations.

The remote endpoints are running a mix of 21.1.8 and 21.1.9 (the latter one being the one which I usually update first).
The security allocation+policies both show reasonable data.

The phenomenon does not change after stopping/starting IPsec and rebooting the firewall.

Did I miss something which I was supposed to do, and/or do others see the same situation?

2

Hardware and Performance / Sophos SG210 hardware

« on: October 09, 2020, 03:25:28 pm »

Quick and direct question: Has anyone succeeded installing OPNsense onto a Sophos SG210 hardware?

3

German - Deutsch / Telekom verlangt Firmware-Upgrade, SRV-Diensteauflösung

« on: September 03, 2020, 11:10:48 am »

Hallo liebes Forum!
Mit Schreiben von vorgestern möchte mir die Telekom erklären, dass ich in einer Filiale wegen eines "veralteten DNS-Eintrags über A-Record" ab 21. September nicht mehr telefonieren könne. Stattdessen möge ich doch bitte eine "SRV-Diensteauflösung" benutzen.

Die technische Hotline verwies nur relativ stumpf auf "Sie müssen 'DAS' Update machen", konnte mir jedoch keinerlei weitere Hinweise geben außer "ja wenn Sie einen Router von uns verwenden würden…" — dann kann ich aber meine IPsec-Tunnel grad mal in die Tonne treten. Als ob alle anderen Geschäftskunden den ganzen Tag nur Katzenvideos glotzen würden 

Kann mir hier jemand einen Schubs in die richtige Richtung geben? Was genau wollen die von mir, wie schaffe ich das?

Setup:
Telekom ADSL, 16 Mbit/s, BNG, statische IPV4-Adresse.
Modem: Dlink DSL-321b
Router: OPNsense, WAN-Anschluss über PPPOE (derzeit noch 20.1.8, das Upgrade auf 20.7 habe ich hier noch prokrastiniert ).

Telefon: Gigaset C430A GO, steht im LAN, erhält eine fixe V4-Adresse über DHCP der OPNsense. Als DNS-Server verweise ich auf einige interne BIND9-Server, welche für alles externe bei Google oder Quad9 anfragen.
Für die SIP-Anbindung (zur Telekom) habe ich für das Telefon "NAT ausgehend" mit statischen Ports definiert sowie UDP Portweiterleitungen von der PPPOE-Adresse (3478,5060:5076,40000:40100) zum Telefon angelegt.

4

German - Deutsch / [Gelöst] IPsec, ein spezieller Tunnel durcheinander seit Updatenach 18.1.8

« on: June 01, 2019, 12:38:53 pm »

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]

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]

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]

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?

5

19.1 Legacy Series / IPsec tunnels constantly breaking down (solved)

« on: March 13, 2019, 11:06:45 am »

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]

  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 

6

18.7 Legacy Series / OpenVPN routing (to other site connected via IPsec)

« on: December 02, 2018, 06:06:51 pm »

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.