IPSEC GastLAN -> Sophos Firewall in DMZ

[Henri]

Hallo,

ich habe im Moment noch ein Problem mit IPSEC über eine Public IP auf unsere Sophos Firewall in der DMZ.

Von aussen funktioniert alles wie gewünscht, von innen (Gast bzw. Client VLAN) bekomme ich nach ein paar Paketen "masquerading failed for source" oder wenn ich ein anders Outbound Interface nutze "reverse masquerading failed for source (1): 10.0.203.8:500".

Ich gehe mal davon aus, dass Problem tritt auf, da bei der IP Adresse "78.x.x.x/32" Masq:No bei "sh ipv4-fib" zu finden ist.
Funktioniert das trotzdem irgendwie?

Vielen Dank wie immer und frohe Ostern

Henri

[IP-masquerading] 2023/04/08 13:23:52,898 Devicetime: 2023/04/08 13:23:52,775 [info] : open port 23692 for UDP (17), 172.20.70.129:51266

[IP-Router] 2023/04/08 13:23:52,899 Devicetime: 2023/04/08 13:23:52,777
IP-Router Rx (VF1, RtgTag: 70):
DstIP: 172.20.70.129, SrcIP: 78.x.x.x, Len: 208, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 51266, SrcPort: 500
Filter (limited)

[IP-Router] 2023/04/08 13:23:52,937 Devicetime: 2023/04/08 13:23:52,777
IP-Router Rx (VF1, RtgTag: 70):
DstIP: 172.20.70.129, SrcIP: 78.x.x.x, Len: 208, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 51266, SrcPort: 500
Route: BUNDLE-1 Tx (VLAN70_CLIENT)

[IP-Router] 2023/04/08 13:23:52,937 Devicetime: 2023/04/08 13:23:52,807
IP-Router Rx (BUNDLE-1, VLAN70_CLIENT, RtgTag: 70):
DstIP: 78.x.x.x, SrcIP: 172.20.70.129, Len: 424, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 500, SrcPort: 51266
Route: WAN Tx (VF1)

[IP-masquerading] 2023/04/08 13:23:52,937 Devicetime: 2023/04/08 13:23:52,807 [error] : masquerading failed for source: 172.20.70.129:51266

[IP-Router] 2023/04/08 13:23:56,014 Devicetime: 2023/04/08 13:23:55,876
IP-Router Rx (BUNDLE-1, VLAN70_CLIENT, RtgTag: 70):
DstIP: 78.x.x.x, SrcIP: 172.20.70.129, Len: 424, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 500, SrcPort: 51266
Route: WAN Tx (VF1)

[IP-masquerading] 2023/04/08 13:23:56,014 Devicetime: 2023/04/08 13:23:55,876 [error] : masquerading failed for source: 172.20.70.129:51266

[IP-Router] 2023/04/08 13:24:02,177 Devicetime: 2023/04/08 13:24:02,074
IP-Router Rx (BUNDLE-1, VLAN70_CLIENT, RtgTag: 70):
DstIP: 78.x.x.x, SrcIP: 172.20.70.129, Len: 424, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 500, SrcPort: 51266
Route: WAN Tx (VF1)

[IP-masquerading] 2023/04/08 13:24:02,177 Devicetime: 2023/04/08 13:24:02,074 [error] : masquerading failed for source: 172.20.70.129:51266

Rtg-Tag 70

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
0.0.0.0/0 0.0.0.0 TELEKOM 41 on Redistribute Static (5)
78.x.x.x VF1 23 on Redistribute Static (5)
10.0.100.0/24 0.0.0.0 VLAN100_FWINT 3 no Redistribute Connected LAN (2)
10.0.100.1/32 0.0.0.0 #Loopback 1 no Never VRRP (0)
10.0.100.2/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)
10.0.101.0/24 10.0.100.8 VLAN100_FWINT 3 no Redistribute Static (5)
10.0.203.0/24 0.0.0.0 VLAN203_FWWAN 8 no Redistribute Connected LAN (2)
10.0.203.1/32 0.0.0.0 #Loopback 1 no Never VRRP (0)
10.0.203.2/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)
10.0.210.0/24 0.0.0.0 MANAGEMENT 21 no Redistribute Connected WAN (2)
10.0.210.2/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)
78.x.x.x/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)

[tstimper]

Hi Henri,

Welche Sophos Firewall hast Du denn?

Frag da mal lieber im Sophos Forum.

Oder ist ein LANCOM Gerät hier mit beteiligt?

Viele Grüße

ts

[Henri]

Hallo tstimper,

das sind LANCOM IP-Router und IP-Masq. Traces.

Mit vielen Grüßen

Henri

[Dr.Einstein]

Ich gehe mal davon aus, dass Problem tritt auf, da bei der IP Adresse "78.x.x.x/32" Masq:No bei "sh ipv4-fib" zu finden ist.

Rtg-Tag 70

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
78.x.x.x VF1 23 on Redistribute Static (5)
78.x.x.x/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)

Das ist nur ein Anzeigefehler. Die eigene WAN-IP/32 wird immer ohne Maskierung an, die eigentliche Route aber mit Maskierung, Beispiel von meinem Router:

Code: Alles auswählen

  0.0.0.0/0          0.0.0.0         INTERNET                  3          on           Redistribute   Static (5)
  80.151.xxx.xxx/32  0.0.0.0         #Loopback                 1          no           Redistribute   Local WAN (0)

Mir fehlt hier aber noch ein Puzzleteil. Woher kommt 172.20.70.129/xx? Ist diese Adresse als statische Route auf das VLAN70_CLIENT / LACP-Bundle gerichtet? Mich wundert, dass das nicht in deiner IPv4-FIB Ausgabe mit angezeigt wird. Eigentlich sollte ja dann eher die IDS zuschlagen.

Nutzt du Portweiterleitungen für UDP500 auf deine 172.20.70.129?

[Henri]

Hallo Dr.Einstein,

danke, habe wohl zu viel rausgeworfen. Die VLANs sind alle über Bundle-1 (10G) mit dem Switch verbunden.

Ich hatte auch untern /Status/IP-Router/1-N-NAT/IPSec-Table nachgeschaut. Da wird die Verbindung registriert,
finde aber gerade den Output nicht mehr.

Mit vielen Grüßen

Henri

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
0.0.0.0/0 0.0.0.0 TELEKOM 22 on Redistribute Static (5)
172.20.70.0/23 0.0.0.0 VLAN70_CLIENT 17 no Redistribute Connected LAN (2)
172.20.70.1/32 0.0.0.0 #Loopback 1 no Never VRRP (0)
172.20.70.2/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)


Mit vielen Grüßen

Henri

[Henri]

Nutzt du Portweiterleitungen für UDP500 auf deine 172.20.70.129?

Ja klar, 500 und 4500, allerdings selektiv für Interface VF1 (78.x.x.x).

Mit vielen Grüßen

Henri

[Dr.Einstein]

Moment, entweder habe ich den Aufbau nicht verstanden, oder genau das ist das Problem:

VF FritzBox -> Lancom (WAN 78.x.x.x | LAN 172.20.70.2/23) -> Sophos Firewall 172.20.70.129

Sophos Firewall 172.20.70.129 baut einen VPN Tunnel auf die WAN IP des Lancoms auf??

DstIP: 78.x.x.x, SrcIP: 172.20.70.129,
Prot.: UDP (17), DstPort: 500, SrcPort: 51266

Dann würde es mich nicht wundern, dass diese Schleife nicht funktioniert. 1) wäre das Hairpin Nat, 2) hättest du einen Kreis, da ja der Zielport 500 wieder auf die Portweiterleitung zeigt. Kapiere nicht, was du vor hast. Oder das ganze IP gekürze macht mir hier Probleme.

[Henri]

Hallo Dr.Einstein,

danke für deine Nachricht.

Okay, also erst einmal wieso. Wir haben diverse Kunden mit hohen Sicherheitsanforderungen, daher nutzen wir LANCOM VPN, 802.1x mit SCEP (MDM) und Zertifikate vom ISG-4000. Jetzt gibt es aber Mitarbeiter, wo diese Lösung nicht passt. Dafür gibt es dann einen Zugang mit Sophos IPSEC OTP auf ganz spezifische IPs & Ports. Für diesen Zweck gibt es eine Public IP 78.x.x.x, für diese IP ist ein Forwarding von Port 500, 4500, 443 usw. auf den Sophos Cluster 10.0.x.8, eingerichtet, Outbound geht auch alles über diese IP zurück ins Internet (10.0.203.8 - TAG 203). Hierfür gibt es einsprechende FW Regel und IP-R Einträge.
Der Sophos Cluster ist vor allem der zentrale Reverse Proxy (WAF), die WAN URLs werden von LAN als auch vom WAN benutzt.
Das funktioniert auch alles wie gewünscht, wenn man von aussen kommt (im Fall von IPSEC), sonst immer.

Wenn aber nun ein solcher Mitarbeiter vor Ort ist, bucht er sich in das Guest WLAN ein und möchte die VPN Verbindung auch "lokal" nutzen.
Dabei gibt es dann dieses Problem.

Technisch:

/Setup/IP-Router/1-N-NAT
500 500 UDP 78.x.x.x 10.0.203.8 0 Yes SFW IPSEC
4500 4500 UDP 78.x.x.x 10.0.203.8 0 Yes SFW IPSEC

/Setup/IP-Router/IP-Routing-Table
255.255.255.255 0.0.0.0 2005 0 10.0.100.8@5 0 No Yes Default Route via Sophos FW - VLAN5
255.255.255.255 0.0.0.0 2000 0 10.0.100.8@0 0 No Yes Default Route via Sophos FW - VLAN1
255.255.255.255 0.0.0.0 203 0 VF1 0 on Yes Default Route from FW WAN

Das dafür dann die entsprechenden FW Rules existieren, ist glaube ich selbsterklärend. Die Sophos Firewall NATted dann Outbound mit 10.0.203.8.

Backslash hatte vor vielen Jahren einmal etwas über eine Glaskugel bei IP-Masq. und IPSEC geschrieben. Ich vermute einmal ich mache hier etwas falsch, so dass die Glaskugel nicht funktioniert. Hier ist die Blick in die Glaskugel, vermutlich ist es nicht gut, wenn bei SPI 0 drinsteht, was aber hier nicht okay ist, verstehe ich nicht ganz. Übrigens nutze ich gerade VPN ins Admin Netz in gleicher Konstellation zu einem ISG-5000 ohne Probleme.

Content of table: /Status/IP-Router/1-N-NAT/IPSec-Table

remote-Address local-Address remote-cookie local-cookie remote-SPI local-SPI Timeout CO NL NR DP Flags WAN-Address
--------------------------------------------------------------------------------------------------------------------------
78.x.x.x 10.0.203.8 9f1be4f5a03b78b6 438d6ccf99b058fb 00000000 00000000 16850 20 0 0 0 0041 78.x.x.x
78.x.x.x 172.20.70.129 0000000000000000 9f1be4f5a03b78b6 00000000 00000000 1985 15 0 0 0 0040 78.x.x.x

Es funktioniert offensichtlich nicht, da wg. diesem Traceeintrag ("[IP-masquerading] 2023/04/08 13:23:52,937 Devicetime: 2023/04/08 13:23:52,807 [error] : masquerading failed for source: 172.20.70.129:51266") das Paket nicht an die Sophos Firewall forwarded wird. Das ist dann auch in den Traces der Sophos Firewall und dem Client zu sehen, übriges funktioniert die Kommunikation initial für die ersten paar Pakete. Der Sophos Client nutzt Port 500, nicht 4500, ich aber auch bisher keine Schalten dafür gefunden.

Danke und mit vielen Grüßen

Henri

[Dr.Einstein]

Du meinst das hier oder? viewtopic.php?p=80080&hilit=ipsec+table#p80080

Hair-PIN-Nat auf Port 500 mit speziellem Lancom-Algorithmus. Da bin ich leider raus. Sowas kann dir garantiert nur ein Entwickler beantworten.

[backslash]

Hi Henri,

also bei einem Hairpin-NAT für IPSec wäre ich sehr vorsichtig... IPSec nachzuhalten ist an sich schon eine herausforderung, das aber auch noch als Hairpin-NAT... ich würde davon ausgehen, daß das scheitert...

mein Tipp: trage im DNS-Server des LANCOMs die IP-Adresse der Sophos unter dem öffentlichen Namen ein...

so kontaktiert ein Host von "aussen" das LANCOM und es wird ein Portforwarding gemacht und wenn der Host von "innen" kommt, dann spricht er direkt mit der Sophos...

Das hat zudem den Vorteil, daß die Sophos auch die von "innen" kommenden Zugriffe "separieren" kann (z.B. in Log-Files), denn bei einem Hairpin-NAT kämen sie alle von der öffentlichen Adsresse des LANCOMs...

Gruß
Backslash

[Henri]

Hallo Backslash,

vielen Dank für deine Hilfe, wie immer...

Das habe ich schon versucht gehabt, leider bindet die Sophos Firewall IPSEC nur an ein Interface (WAN=10.0.203.. Auf dem Gerät sind Routen definiert, um den 172.20.0.0/16 Traffic über das LAN IF(10.0.100. zu routen. Daher passiert bei dieser Konfiguration leider folgendes:

172.20.70.129 -> 10.0.203.8 WAN (SFW) LAN 10.0.100.8 -> 172.20.70.129 IDS! Ende!

Das Gerät wird nicht nur als WAF (Inbound) sondern auf den gesamten Outbound Traffic verwendet. Funktionieren würde die 10.0.100.8 als Ziel, leider ist dort aber IPSEC nicht erreichbar.

Hast Du noch eine andere Idee?

Danke und mit vielen Grüßen

Henri

[backslash]

Hi Henri,

da ich deine Routing-Tabellen nicht kenne und auch nicht weiss, wie du die Geräte angeschlossen hast, ist das wie ein Blick in die Kristallkugel... (und wie man die Sophos richtrig konfiguriert kann ich dir auch nicht sagen)

Aber ich verstehe ich das Problem auch nicht wirklich... Du hast die Sophos in der DMZ und einen Client in einem Gastnetz...
Das sind doch verschiedene Netze... Somit ist es aus Sicht der Sophos doch egal, ob der Client in "Internet" steht oder in einem andere LAN-Netz (Gastnetz) - beide Netze erreicht die Sophos über ihre Default-Route.
Und Clients, die sich auf der Sophos einwählen, bekommen doch von der Sophos eine IP-Adresse zugewiesen - und der Pool ändert sich ja nicht, egal aus welchem Netz der Client sich einwählt. Wichtig ist nur, daß es keine Überschneidung des Pools mit deinen anderen Netzen gibt, denn sonst passiert genau das:

172.20.70.129 -> 10.0.203.8 WAN (SFW) LAN 10.0.100.8 -> 172.20.70.129 IDS! Ende!

Da solltest du wohl eher dein Netz aufräumen, statt zu hoffen, daß ein Hairpin-NAT für IPSec funktioniert...

BTW: "funktioniert" es denn, wenn du das IDS abschaltest (also als IDS-Aktion "Übertragen" einstellst)? Wenn ja, dann könntest du das IDS mit einer Dummy-Route "überlisten", die das Netz 172.20.70.x in einem ansonsten ungenutzten Routing-Tag über ein imaginäres Gateway im Netz 10.0.100.x (z.B. die von dir genannte 10.0.100.8 ) erreichbar macht...


Aber du könntest natürlich mit der ganz großen Kelle "draufschlagen" und die Pakete für die 78.x.x.x durchs Internet schicken... Denn laut deiner FIB hat du ja zwei WAN-Leitungen - eine zur Telekom und eine über die Fritzbox (VF1)... Du mußt nur dafür sorgen, daß die Route zum 78.x.x.x Netz im "Gast"-Kontext (Rtg-Tag 70) nicht auf VF1 zeigt, sondern auch auf die TELEKOM... Und natürlich muß dem Kontext der Sophos die Default-Route auf VF1 zeigen und es darf keine Route auf die TELEKOM-Geegnstelle geben. Dann machen die Pakete die Große Runde...

Gruß
Backslash

[COMCARGRU]

Hi Henri,
da ich deine Routing-Tabellen nicht kenne und auch nicht weiss, wie du die Geräte angeschlossen hast, ist das wie ein Blick in die Kristallkugel... (und wie man die Sophos richtrig konfiguriert kann ich dir auch nicht sagen)
Backslash

Die Sophos SG Serie (XG weiß ich nicht) bindet IPSec tatsächlich immer nur an ein AKTIVES Interface. Man kann zwar mehreren Interfaces zuweisen, aber es wird immer das primäre Interface benutzt bis zu dem Zeitpunkt wo das ausfällt, dann wird IPSec an das nächste Interface gebunden. Man kann die Reihenfolge festlegen. Relevant ist natürlich, dass die Sophos auch merkt, dass ihm ein Interface "weggeflogen" ist. Leitungsüberwachung ist also zwingend aktiv zu benutzen.

Gruß

[Henri]

Die XG(s) bindet IPSEC nur an das WAN Interface, da ich aber vom der LAN Seite komme, funktioniert das so nicht. Diese Geräte haben alle eine Trusted Side(LAN) und eine Non-Trusted-Side(WAN), dazwischen läuft dann IDS, WAF/Reverse Proxy etc. Das Geräte NATted mit dem entsprechenden Interface. Daher müssen die Pakets aus dem LAN zum LAN Interfaces der XG(s) gerouted werden und die WAN Pakete von/zum WAN Interface.
Aus dem LAN Pakete ans WAN zu senden ist nun einmal nicht vorgesehen.

Ich habe also versucht, die Pakets über das Telekom Interface die große Runde herum zu schicken. Allerdings ist das Guest LAN auf einen WLC-30 beheimatet, der hat eine Defaultroute zum ISG-5000 und eine Rückroute wieder zum WLC. Das funktioniert auch grundsätzlich und lt. Trace gehen die Pakete über die gewünschte (Telekom) Strecke hin und kommen auch wieder zurück.

Ich bekomme allerdings auf dem WLC "ICMP Host unreachable", habe gerade den ISG-5000 mit einen ICMP Trace abgeschlossen, nicht so toll.

Leider ein gewaltiger Aufwand, für eine ganz einfache Aufgabenstellung.

Mit vielen Grüßen

Henri