Interpretationshilfe für Trace

[5624]

Hallo zusammen,

ich versuche bereits seit einigen Monaten immer mal wieder ein Problem zu lösen, was aber keine große Priorität hat, da es bisher nur mich stört und ich weiß, wie ich es umgehen kann.

Ich habe einen 1900EF (bis vor kurzem 10.72SU2, mittlerweile 10.72RU5), der unsere VPN-Verbindungen zu externen Dienstleistern bedient. Früher hatte ich noch einen weiteren 1900EF, der nur die VPN-Verbindungen von unseren eigenen Nichthandelsaußenstellen terminiert hat. Da beide Kisten mit ihrer Aufgabe deutlich unterfordert waren, habe ich beide zusammengefasst.
Also auf dem einen 1900EF ist jetzt beides zusammengefasst und via ARF getrennt. VPN von Externen auf Tag 431, VPN von Internen auf Tag 430. Der Traffic geht dann VLAN-separiert über ein LACP-Bundle zur übergeordneten Firewall. Die ARF-Kontexte lernen die jeweils anderen Verbindungen via OSPF über die Firewall. Ist in der Routingtabelle auch korrekt abgebildet.

Soweit klingt es erstmal gut und funktioniert, bis auf eine Sache: Wenn eine interne Außenstelle auf einen externen Dienstleister zugreifen will.

Ein traceroute vom Router einer Außenstelle zum externen Dienstleister endet in einer Schleife zwischen Firewall und 1900EF (.74 ist die IP des 1900EF Tag 430, .78 die des 1900EF Tag 431 und die .73 die der externen Firewall)

Code: Alles auswählen

root@RTR_BUERO_BERLIN:/
> ping -r 10.213.10.57

0 Traceroute 172.21.42.74      seq.no=0 time=17.960 ms
1 Traceroute 172.21.42.73      seq.no=1 time=17.192 ms
2 Traceroute 172.21.42.78      seq.no=2 time=17.674 ms
3 Traceroute 172.21.42.73      seq.no=3 time=17.917 ms
4 Traceroute 172.21.42.78      seq.no=4 time=17.423 ms
5 Traceroute 172.21.42.73      seq.no=5 time=17.929 ms
6 Traceroute 172.21.42.78      seq.no=6 time=17.436 ms
7 Traceroute 172.21.42.73      seq.no=7 time=17.927 ms
8 Traceroute 172.21.42.78      seq.no=8 time=17.678 ms
9 Traceroute 172.21.42.73      seq.no=9 time=17.182 ms
10 Traceroute 172.21.42.78      seq.no=10 time=17.672 ms
11 Traceroute 172.21.42.73      seq.no=11 time=18.705 ms
12 Traceroute 172.21.42.78      seq.no=12 time=17.431 ms
13 Traceroute 172.21.42.73      seq.no=13 time=17.185 ms
14 Traceroute 172.21.42.78      seq.no=14 time=17.933 ms
15 Traceroute 172.21.42.73      seq.no=15 time=17.936 ms
16 Traceroute 172.21.42.78      seq.no=16 time=17.941 ms
17 Traceroute 172.21.42.73      seq.no=17 time=17.935 ms
18 Traceroute 172.21.42.78      seq.no=18 time=17.936 ms
19 Traceroute 172.21.42.73      seq.no=19 time=18.196 ms
20 Traceroute 172.21.42.78      seq.no=20 time=18.440 ms

 ---10.213.10.57 ping statistic---
 56 Bytes Data, 22 Packets transmitted, 21 Packets received, 4% loss

root@RTR_BUERO_BERLIN:/

Andere Pakete enden identisch dazu mit einem TTL Time exceeded.

Jetzt habe ich mal den Tracer angeworfen und habe dieses hier herausbekommen:

Code: Alles auswählen

[IP-Router] 2023/11/26 13:42:34,484  Devicetime: 2023/11/26 13:42:34,008
IP-Router Rx (BUNDLE-1, VPN_EXTERN, RtgTag: 430):
DstIP: 10.213.10.55, SrcIP: 10.8.41.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0070, seq: 0x0000
Route: 172.21.42.73, BUNDLE-1 Tx (VPN_INTERN)

Für mich sieht die zweite Zeile so aus, als würde der Router irgendwas in den falschen Hals bekommen. Er meldet, er hätte es über VPN_Extern erhalten (das ist Tag 431), vermerkt es aber als Tag 430. Wenn es korrekt wäre, müsste es meiner Meinung nach aber

Code: Alles auswählen

BUNDLE-1, VPN_EXTERN, RtgTag: 431

und daraus folgend die letzte Zeile

Code: Alles auswählen

Route: WAN Tx (VPN_HOSTER)

lauten.

So sieht das gleiche aus, wenn ich nicht von einer Außenstelle über den 1900EF reinkomme, sondern einen Host an einer anderen Stelle im Netz nutze:

Code: Alles auswählen

[IP-Router] 2023/11/26 14:07:27,975  Devicetime: 2023/11/26 14:07:27,438
IP-Router Rx (BUNDLE-1, VPN_EXTERN, RtgTag: 431):
DstIP: 10.213.10.57, SrcIP: 172.21.30.240, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x04fd
Route: WAN Tx (VPN_HOSTER)

Sind meine Schlussfolgerungen für den ersten Trace-Eintrag richtig, dass das Paket anders aussehen müsste und der Router sich hier vertut? Gibt es für solche U-Turn-Konstruktionen bestimmte Sachen, die ich beim ARF beachten muss, die ich in der Doku überlesen haben könnte oder in dieser nicht erwähnt werden?
Der externe Router ist kein LANCOM, kann also mit ARF-Tags nicht umgehen und mein Verständnis ist, dass diese den Router nicht verlassen sollten.

[Dr.Einstein]

Hast du mal unter Kommunikation / Gegenstelle / Tag-Table die VPN Verbindung in das Tag 431 gesetzt?

[5624]

Ja, da ist für VPN_BUEROBER die 430 und für VPN_HOSTER die 431 hinterlegt.

[Dr.Einstein]

Lös mal temporär das LACP-Bundle auf, sodass du LAN-x verwendest. Ich hatte schon diverse Bugs in die Richtung gesehen...

[5624]

Bundle aufgelöst, gleiches Ergebnis.

Ich glaube, ich mache da morgen einen Fall für den Support draus.

[Dr.Einstein]

Hast du Firewall Regeln, die mit Quell- und/oder Ziel-Tag arbeiten?

[5624]

Ja, nur welche mit Quelltag und das meiste sind NAT-Regeln. Funktioniert aber auch nicht, wenn die Regeln nicht da sind. Im Gegenzug funktionieren ja die Regeln, wenn es nur einmal durch den Router läuft. Es gibt keine Regeln die einen Kontextwechsel verursachen.

Wenn ich die Traceausgabe richtig deute, dann kommt das Paket über die Schnittstelle mit Tag 431 rein, wird als Tag 430 gedeutet, springt dann in den Kontext 430, geht zur externen Firewall, wird wieder an die 431er Schnittstelle übergeben, als Tag 430 gedeutet, ..., TTL exceeded.

[5624]

Okee, dass mit dem Supportfall hat sich erledigt, kann ich gar nicht anlegen und für einen Supportfall in fünf Jahren kauf ich nichts, außer vielleicht einen Router von einem anderen Hersteller.

Mit sowas will ich jetzt die mir bekannten Field Engineers nicht belästigen, die bewahre ich mir für andere Sachen auf.

[Dr.Einstein]

Leg mal testweise eine Regel an, die ankommend für genau die Beziehung umtaggt.

[backslash]

Hi 5624,

da gast du dir wohl eine Schleife gebaut - wenn auch ungewollt... In 172.21.42.73 (Firewall) zeigt die Route zum 10.213.10.x Netz auf die 172.21.42.78 (LANCOM) und in 172.21.42.78 (LANCOM) auf die 172.21.42.73 (Firewall)

Das Problem ist, daß deine externe Firewall offenbar zumm Einen transparent ist und zum Anderen die Pakete an das LANCOM zurückspiegelt... Die IPv4-Firewall des LANCOMs kann damit nicht umgehen - die hat nur einen Session-Kontainer, der hier aber zwei "identische" Sessions (ping von 10.8.41.1 an 10.213.10.55) halten soll. Die Session wird mit der ersten Ping angelegt und zeigt auf die externe Firewall. Wenn die externe Firewall das Paket zurückspiegelt, wird die eben angelegte Session gefunden und das Paket geht wieder an die externe Firewall...

Damit das Szenario funktioniert, muß die externe Firewall NATten, damit die von ihr weitergeleiteten Pakete in der IPv4-Firewall des LANCOMs nicht mehr auf die selbe Session matchen.
Oder die externe Firewall muß selbst das Gateway in deinem lokalen Netz sein und das LANCOM ist einfach nur der Router, der Internetzugang und VPN-Einwahlen zur Verfügung stellt - dann würde der Traffic auch nur einmal über das LANCOM laufen und das Problem damit ungangen.

BTW: Das Abschalten der IPv4-Firewall im LANCOM hilft leider nicht, weill der Session-Lookup erhalten bleibt - es werden nur alle Regeln und das IDS deaktiviert.

Gruß
Backslash

[5624]

Die Firewall hat zwei IPs und ist nicht transparent.

VPN_Intern auf dem LANCOM (Tag 430) hat die .74, die leitet das Paket an die Firewall mit der .73, die routet das Paket dnan in ein anderes IP-Subnetz auf einer anderen VLAN-Schnittstelle, dort hat die Firewall die .77 und schickt es an VPN_Extern am LANCOM (Tag 431), der die IP .78 hat zurück.
Es sind auch /30er Netze, also .73/.74 und .77/.78 liegen nicht im selben Subnetz.

Der LANCOM baut hier, dem Trace nach, die Schleife, weil er ein Paket, welches über eine Schnittstelle mit Tag 431 hineinkommt, als 430 taggt und damit einen anderen Teil der Routingtabelle sieht, welcher 10.213.10.0/24 via OSPF über die externe Firewall schickt.

Unbenannt.PNG

Wenn ich wirklich den Kram NATten muss, dann ist es meiner Meinung nach ein Design- oder Implementierungsfehler seitens LANCOM, der dann entweder behoben werden oder kommuniziert werden muss. Damit ist ARF dann aber absolut unbrauchbar.

[backslash]

Hi 5624

Die Firewall hat zwei IPs und ist nicht transparent.

doch die Firewall IST transparent - zumindest, was den IP-Header der übertragenen Pakete angeht. Deshalb gibt es ja das Poblem...

Dein Bild ist irreführend, weil es sich um das EIN LANCOM handelt, das nur per ARF in zwei virtuelle aufgeteilt wird (dem Bild nach könnte man glauben es wären wirklich zwei). Wären es wirlich zwei, dann würde das Szenario u.U. sogar funktionieren

Wenn ich wirklich den Kram NATten muss, dann ist es meiner Meinung nach ein Design- oder Implementierungsfehler seitens LANCOM, der dann entweder behoben werden oder kommuniziert werden muss.

Das wird von LANCOM so kommuniziert! Zumindest jedes mal, wenn ein Kunde mit diesem Szenario ankommt, wird ihm gesagt, daß das nicht funktioniert.
Aus meiner sich ist sein solches Szenario (ich nenne das mal "Firewall an einer Stichleitung) ein Design-Fehler im Netz, denn es ermöglicht es einem Angreifer, die Firewall zu umgehen.

Damit ist ARF dann aber absolut unbrauchbar.

Nein! Das ARF ist nicht für dieses Stichleitungs-Szenario gedacht. Es funktioniert sauber solange Pakete nur EINMAL durch das LANCOM laufen. Im Stichleitungsbetrieb kommen sie aber ZWEIMAL an.

BTW: das ist kein Problem des ARF, sondern höchstens eins der IPv4-Firewall, denn das ARF erzeugt nur die Routing-Tabellen, die die Firewall beim ANLEGEN einer Session nutzt.
Um das Problem zu beheben, muß die IPv4-Firewall auf ganz neue Beine gestellt werden - etwa so wie bei der IPv6-Firewall, denn die kommt mit dem Szenario klar, weil sie Session-Container pro Interface besitzt.
Diese Umstellung wird aber erst mit einer vereinheitlichten Firewall für IPv4 und IPv6 kommen (was dann eine komplett neue Firewall sein wird).

Gruß
Backslash

[5624]

Danke backslash,

dann werde ich die Konstruktion umbauen. Dann wird ein Teil auf die Fortigate umgelegt, weil ich will weniger Router im Schrank haben, nicht mehr.

Aus meiner sich ist sein solches Szenario (ich nenne das mal "Firewall an einer Stichleitung) ein Design-Fehler im Netz, denn es ermöglicht es einem Angreifer, die Firewall zu umgehen.

Wie dieses? Es gibt ja keinen anderen Pfad, es gibt nur den Pfad vom LANCOM zur Fortigate. Alles andere am Router darf ja gar nicht gesehen werden, damit wird ja ARF beworben. Ja, Sachen im selben Kontext können die Abkürzung nehmen, aber dafür hat man ja eine entsprechende Netzplanung.

Mit der LANCOM-Firewall würde das gar keinen Spaß machen, ich hab auf der Kiste aktuell 40 Regeln, woraus über 45000 Filter werden und der Regelsatz sieht nur das absolute Minimum vor. Die Fortigates sind richtige Firewalls und können es definitiv besser, daher diese Variante.
Auf den ISG-1000 hab ich die Firewall schon auf nur 29000 Filter herunteroptimiert und dennoch ständig Drop-Outs aufgrund von Überlastung, mit im Schnitt 25 Verbindungen pro GW.

Diese Umstellung wird aber erst mit einer vereinheitlichten Firewall für IPv4 und IPv6 kommen (was dann eine komplett neue Firewall sein wird).

LCOS 15? LCOS 17?

[backslash]

Hi 5624,

Wie dieses? Es gibt ja keinen anderen Pfad, es gibt nur den Pfad vom LANCOM zur Fortigate. Alles andere am Router darf ja gar nicht gesehen werden, damit wird ja ARF beworben.

ARF richtet für jeden Kontext getrennte Routing-Tabellen ein und erzeugt damit die Trennung, aber:

Ja, Sachen im selben Kontext können die Abkürzung nehmen

mit dem Satz hast du auch gleich die Antwort auf deine Frage geliefert...

, aber dafür hat man ja eine entsprechende Netzplanung.

solange es dabei keinen Fehler gibt...

LCOS 15? LCOS 17?

das kann ich dir wirklich nicht beantworten - ich kann nur sagen, daß daran gearbeitet wird...

Bis dahin muß man mit den Unzulänglichkeiten leben, denn das Problem in der jetzigen IPv4-Firewall zu fixen, käme ebenfalls einem Neuschreiben gleich. Es ist halt ein grundlegendes Problem und zeigt, wie alt die Basis der derzeitigen Implementation ist (ELSA läßt Grüßen)

Gruß
Backslash