IPSEC, nur eine Seite erreicht die Netze

marcfunk

Hallo Zusammen!

Wir haben zwischen einer 2100 Base und einer 6100 Base ein IPSec Tunnel aufgebaut.
Dieser wird auch verbunden und funktioniert soweit - allerdings nur von einer Seite.

Seite A:
NETZ 192.168.72.0/24
NETZ 192.168.0.0/24

Seite B:
NETZ 192.168.190.0/24

Von Seite B komme ich nach A. Von A komme ich aber nicht nach B. Egal ob aus dem 72er oder 0er Netz. Firewall-Regeln sind alles Standard Default LAN to Any.
Ich habe auch separat Regeln angelegt, die explizit von A nach B Netze und umgekehrt erlauben - dennoch klappt es nicht.

Vor den pfSenses sind jeweils FritzBoxen, die aber nur als Modem genutzt werden und bei denen ESP, 4500 UDP und 500 UDP auf die pfSense zeigen.

Hat jemand einen Denkanstoß? Danke! :)

NOCling

Da hier Daten rein und raus gehen, scheint der Tunnel soweit zu funktionieren. Das sieht auf beiden Seiten so aus oder?

Ich würde noch mal beim Regelwerk schauen und eine Logging Regel auf dem IPsec Interface erstellen die any any erlaubt.
Zudem kannst du unter Diag einen Mitschnitt erzeugen und dann schauen ob hier etwas bei der pfSense ankommt.

Die P2 sieht auf beiden Seiten anlog aus, also sind hier auch beide Netze der A Site eingetragen?

Und wenn du schon 2022 einen Tunnel neu baust, dann doch bitte gleich AES256 SHA256, DH19 statt 14.

Habe hier so einen Tunnel laufen, mit GCM und dem SaveXcel Treiber laufe ich im Moment in ein Problem.
Ggf. kannst du das ja mal versuchen und auch reproduzieren.

marcfunk

@nocling
Moin Moin!

Danke für die Hinweise.
Ich habe mal ein Traceroute von A nach B gemacht. Er endet immer an der FritzBox - in dieser sind aber keine Regeln festgelegt. Die pfSense lässt es also augenscheinlich bis zur Fritte durch und die blockiert. Heute Nacht werde ich diese einmal neustarten - ggf. löst sich damit das Problem.

Thema Sicherheit:
Ich hatte erst einmal die Default Werte genommen, die pfSense voreingestellt hat - lediglich beim Schlüssel hatte ich von AES128 schon auf AES256 gestellt. Die Group ändere ich noch - danke für den Hinweis!

So sieht übrigens Seite B aus:

Auf Seite B sind mir noch folgende Fehler im Log aufgefallen:
received ESP_TFC_PADDING_NOT_SUPPORTED notify
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

Nach einer Recherche konnte ich nicht wirklich heraus finden, wofür a) TFC Padding steht und b) was der Fehler bedeutet. Evtl. nur, dass die pfSense das wohl nicht unterstützt?!

micneu

@marcfunk said in IPSEC, nur eine Seite erreicht die Netze:

Vor den pfSenses sind jeweils FritzBoxen, die aber nur als Modem genutzt werden und bei denen ESP, 4500 UDP und 500 UDP auf die pfSense zeigen.

Hat jemand einen Denkanstoß? Danke! :)

ich frage nochmal, macht die sense pppoe über die fritzboxen (fritzbox als modem)?
warum hast du dann auf der fritzbox die ports auf die sense weitergeleitet, so lese/verstehe ich dein text?

NOCling

Klassisches doppltes NAT.

Trage mal die pfSense als exposed Host ein, dann leitet er alles weiter.

Wenn der Tunnel läuft, dann sind die Fritzen davor doch aber egal, weil es dann schon mit dem ESP Header drum durch diese durch läuft und erst die andere pfSense die Pakete wieder entschlüsseln kann.

Die Clients hängen hinter der pfSense am jeweiligen Standort?
Der Traceroute erfolgte von einem Client auf einer Seite zu einem System im LAN Netz hinter der anderen pfSense?
Da dürfte dann die Fritz gar nicht sichtbar sein.
So müsste das aussehen:

Routenverfolgung zu Ziel [192.168.166.11]
über maximal 30 Hops:

  1     2 ms     2 ms     2 ms  pfsense.bla.blub [192.168.10.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3   108 ms    83 ms    86 ms  Ziel [192.168.166.11]

marcfunk

Okay - ich habe mich nicht ganz korrekt ausgedrückt.
Die FritzBoxen sind eigenständige Router mit eigenem Netz und leiten Ports weiter. Das habe ich jetzt zu Exposed Host geändert - an beiden Seiten.

Die Traceroute führe ich direkt von der pfSense aus und gibt folgendes Ergebnis:

Standort A (Fritz-Netz: 192.168.178.0/24) > Tracert auf 192.168.190.29
1  192.168.178.1  1.962 ms  1.841 ms  1.736 ms
2  * * *
3  * * *
4  * * *

Standort B (Fritz-Netz: 192.168.189.0/24) > Tracert auf 192.168.72.29
1 192.168.72.29 0.761 ms 0.676 ms 0.624 ms

Es sieht so aus, als wenn am Standort A die Anfragen an das 190er Netz auf die Fritte laufen und am Standort B über die VPN direkt - oder?

NOCling

Bitte teste von einem Client hinter der pfSense zu einem Client hinter der anderen pfSense.

Da IPsec hier ein eigenes Interface hat, was man im Traceroute nicht auswählen kann, kommt hier kein brauchbares Ergebnis raus.
Dazu müsstest du den Tunnel auf Transport Mode mit VTI umstellen.

Zudem die pfSense den Tunnel ja selber nie für Nutzdaten verwenden wird, also bitte realistisch Client to Client testen.
Dann wirst sicherlich sehen, das der Tunnel funktioniert, wenn das Regelwerk den Datenverkehr zulässt.

marcfunk

Ich habe von Client to Client das tracert durchgeführt.

Seite A:

Routenverfolgung zu 192.168.190.29 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  192.168.72.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
...

Seite B:

Routenverfolgung zu NAS01 [192.168.72.29]
über maximal 30 Hops:

  1     1 ms    <1 ms    <1 ms  pfSense.N***.local [192.168.190.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    57 ms    61 ms    61 ms  NAS01 [192.168.72.29]

Generell erhalte ich bei Seite A mit nslookup folgendes Ergebnis:

C:\Users\User>nslookup
Standardserver:  UnKnown
Address:  192.168.72.1

> 192.168.72.1
Server:  UnKnown
Address:  192.168.72.1

*** 192.168.72.1 wurde von UnKnown nicht gefunden: Non-existent domain.

Bei Seite B wird es korrekt aufgelöst:

C:\Users\User>nslookup
Standardserver:  pfSense.N****.local
Address:  192.168.190.1

> nslookup
Server:  pfSense.N****.local
Address:  192.168.190.1

Bei beiden pfSenses ist DNS etc. alles gleich eingestellt:

Lediglich die IP ist auf Seite B für den 2. Eintrag auf der 192.168.189.1.

Es scheint also schon am DNS zu haken - das ist aber alles "Standard" von der pfSense - ich habe keinen DNS-Server konfiguriert.

Gleiches gilt auch für das 192.168.0.0/24. Auch dort läuft der DNS nicht richtig. Die Namensauflösung klappt dort in der CMD auch nicht - unter Windows aber schon. Suche ich per nslookup nach N***-NUC07 kennt er den Namen nicht - gehe ich über den Windows Explorer über den UNC-Pfad klappt es.

Am Client sind als DNS die 192.168.72.1 eingetragen. Ich verzweifel langsam...

marcfunk

Axo:
Schaue ich im ARP-Table in der pfSense auf Seite A, werden die IPs und Hostnamen korrekt angezeigt:

NOCling

Wenn du intern mit Kurznamen arbeiten willst, dann musst du auch die Suchdomäne an die Clients über DHCP ausrollen oder diese manuell eintragen.

Bitte vergiss dieses, es geht doch im Windows dank diesem mDNS Schrott auch, das ist Betrieb durch Zufall und hört spätestens bei der Netzgrenze auf Spaß zu machen.

Richte dir daher den Resolver sauber ein, den DHCP Server inkl. Suchdomain und dann funktioniert das.
Und der Resolver spricht dann nicht mit dem Fritz DNS Server, es sei denn du erzwingst das Forwarding, sondern direkt mit den großen mächtigen Root DNS Servern des Internets.
Dann kann er noch Prefetch und Caching und dann willst du nie wieder was anderes haben.

Ok, scheinbar will bei dir die Seite A nicht, da scheint sich irgendwas verknotet zu haben. Starte die Kiste doch mal neu, das alle Dienster hier wieder sauber hoch kommen und auch die Routing Tabelle sauber neu aufgebaut wird.
Denn soweit scheint alles zu stimmen.

Aber die Clients hinter der pfSense, die nutzen die pfSense auch als Gateway? Nicht das du hier mit einem testest, der zwar neue statische IP hat, aber dessen GW und dessen DNS Server nicht auf stand gebracht wurde.
Ich lass hier daher alles bis auf Firewall, Switche und NAS/Server auf DHCP laufen.
Dann haben die immer eine saubere IP Konfiguration, für IPv4 und auch IPv6.

marcfunk

@nocling
Moin!

Danke nochmal für die ganze Hilfe.
Heute Nacht habe ich Seite A neugestartet und siehe da: VPN klappt. Echt seltsam...die andere Seite lief ja.

Bzgl. Gateway und DNS: Ja beide die pfSense - es wird auch der Name "NAME.local" als Verbindungssuffix mitgegeben.

Ich bin seit über 20 Jahren dabei...und es funktioniert nach wie vor wie früher: Ein Neustart rettet leben :))

In diesem Sinne: Danke nochmal!

JeGr

@marcfunk said in IPSEC, nur eine Seite erreicht die Netze:

Die FritzBoxen sind eigenständige Router mit eigenem Netz und leiten Ports weiter. Das habe ich jetzt zu Exposed Host geändert - an beiden Seiten.

Vorsicht vor den Fritzboxen und Port Forwardings bzw. Exposed Host. Gerade wenn die Fritze mal wieder semi intelligent versucht für ihr Netz"Home" die Geräte automagisch zu erkennen kommt da oft Murks bei raus.

Da die Fritten auch selbst IPsec können, kann es sein, dass Port Forwards nicht reichen, das gab es in der Vergangenheit bei älteren Firmwares schon, dass dann IPsec einfach nicht weitergeleitet wurde.

Was für ordentlichen exposed Host oft hilft:

Fritz Port Forwarding und exposed host etc. löschen
In der Netzübersicht/Homeview das Device, das die pfSense ist löschen
Dann fix zum Forwarding/Freigabe Screen wechseln solang sie noch kein neues Gerät angelegt hat
Exposed Host anlegen nicht auf ein "vorhandenes benanntes Gerät" sondern auf "IP Adresse" und manuell die IP eingeben, die die pfSense hat (hoffentlich eine STATISCHE!)
speichern

Klingt doof, aber wir hatten jetzt schon mehrfach Fälle auch mit neueren FBs hinter denen eine Sense hing, dass exposed Host eben nicht sauber geklappt hat und Ports verschluckt wurden etc. oder kein Ping lief
Erst löschen dieses komischen MAC/ARP/IP Gerätewirrwarrs auf der Fritz und Anlegen des Exposed Hosts mittels IP (was sie blockt wenn es schon ein bekanntes Gerät gibt mit der IP, darum vorher löschen!) hat den Knoten gelöst und innerhalb von 1-2s ging plötzlich ein Dauerping und Verbindungstest von extern, der vorher konsistent gescheitert ist.

Einfach als kleiner Tipp aus der Praxis