Hallo,
Ich bin auf ein mir unerklärbares Phänomen gestoßen und hoffe nun auf mögliche Unterstützung der Community.
Hier mein Szenario:
Lokales Netz: 192.168.2.0/24
Ich haben eine statische Route für das Netz 192.168.10.0/24 über ein Gateway 192.168.2.252 definiert.
Das Gateway, die OPNsense Appliance und die PC's sind an einem Switch angeschlossen.
In der Firewall musste daher das Tracking des Verbindungszustandes deaktivieren, da ein Antwortpaket aus dem 192.168.10.0/24-Netz für ein PC im lokalen Netz vom Gateway direkt zu dem PC geleitet wird und nicht über die OPNsense(z.B. brach eine SSH-Verbindung nach wenigen Sekunden ab).
Ich hoffe das ist soweit verständlich.
Nun zum Problem:
Im Netz 192.168.10.0 befindet sich ein Webserver. Über den Browser können Dateien hochgeladen werden. Dies funktioniert aber für Dateien die größer als ca. 60kb nicht.
Ein Netzwerkmitschnitt zeigt, dass die OPNsense mitten in der Übertragung plötzlich aufhört Datenpakete weiterzuleiten.
09:30:39.909330 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 61175:62565, ack 6212, win 512, length 1390
09:30:39.909356 02:cb:3a:90:9c:00 > ec:ce:13:ea:24:f4, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 61175:62565, ack 6212, win 512, length 1390
09:30:39.909370 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 62565:63955, ack 6212, win 512, length 1390
09:30:39.909386 02:cb:3a:90:9c:00 > ec:ce:13:ea:24:f4, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 62565:63955, ack 6212, win 512, length 1390
09:30:39.909647 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 63955:65345, ack 6212, win 512, length 1390
09:30:39.909658 02:cb:3a:90:9c:00 > ec:ce:13:ea:24:f4, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 63955:65345, ack 6212, win 512, length 1390
09:30:39.909664 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 65345:66735, ack 6212, win 512, length 1390
09:30:39.909670 02:cb:3a:90:9c:00 > ec:ce:13:ea:24:f4, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 65345:66735, ack 6212, win 512, length 1390
09:30:39.909754 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [P.], seq 66735:68125, ack 6212, win 512, length 1390
09:30:39.909761 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 68125:69515, ack 6212, win 512, length 1390
09:30:39.909898 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 69515:70905, ack 6212, win 512, length 1390
09:30:39.909907 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 70905:72295, ack 6212, win 512, length 1390
09:30:39.910028 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 72295:73685, ack 6212, win 512, length 1390
09:30:39.910038 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 73685:75075, ack 6212, win 512, length 1390
09:30:39.910158 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 75075:76465, ack 6212, win 512, length 1390
09:30:39.910167 98:5f:d3:c8:f1:6a > 02:cb:3a:90:9c:00, ethertype IPv4 (0x0800), length 1444: 192.168.2.171.62094 > 192.168.10.11.443: Flags [.], seq 76465:77855, ack 6212, win 512, length 1390
An den MAC-Adressen sieht man schön einmal das ankommende Paket und einmal das ausgehende.
Ich hab das mal gekürzt. Anschließend folgen dann Retransmission (erstmal für Seq 66735, wegen PUSH-Flag ) bis das alles in einen Timout läuft.
Hat jemand eine Idee warum die OPNsense plötzlich dicht macht ?
Ich bin für jeden Hinweis dankbar.
Lieben Gruß
looserouting
Edit:
Es werden keine Blocks protokolliert.
Für den Fall das es relevant ist: Bei "Static route filtering" in den erweiterten Firewalleinstellungen ist ein Haken gesetzt.
bitte mal einen grafischen netwerkplan.
- warum die route, ist die sense nicht das default gateway?
- bitte screenshots von dem was du konfiguriert hast.
Gesendet von iPad mit Tapatalk Pro
Vielen Dank, für dein Interesse.
Eine Übersicht des Netzwerkes habe ich angehangen. ACHTUNG: Im Bild ist die Rede von einem 192.168.5.0/24 Netz. richtig wäre 192.168.10.0/24 (Also bei der Cisco2 und dem web-Server)
Die beiden Ciscos machen VPN und werden von einem externen Unternehmen betreut. Daher wirkt das Szenario ein wenig chaotisch. Für das Netz hinter Cisco2 ist in der OPNsense eine Route zur Cisco1 eingetragen.
Im Grunde ist die aber kein ungewöhnliches Szenario.
Da Standartmäßig keep state verwendet wird, brachen SSh Verbidungen zu WWW aus dem internen Netz ab.
Wie schon erwähnt, gehen die Antwortpakete von der Cisco vom Switch direkt zu dem PC.
Daher hatte ich eine Regel erstellt, damit die OPNsense den Zustand nicht trackt.
Aktuell sieht die Regel so aus:
pass in quick on GROUP_VLAN4_LAN inet from any to 192.168.10.0/24 flags S/SA keep state (sloppy) label "f2aed4cd0836e936d44cf05cf0a894b1"
Seitdem funktioniert SSH.
Ich haben 3 Port für die ein VLAN (4) konfiguriert habe. An diesen 3 "VLAN4-Ports" hängen die Switche.
Diese Ports habe ich dann einer Bridge hinzugefügt und außerdem haben eine GROUP zur einfacheren Konfiguration erstellt (GROUP_VLAN4_LAN).
Ich vermute, dass aus einem mir nicht bekannt Grund, bei einer http oder https Verbindung trotz allem keep state verwendet wird. Aber ich sehe keine Regel die da "zuvor kommt".
Lieben Gruß
Wahrscheinlich läuft bei dir asynchrones Routing. Hatte einen ähnlichen Fall schonmal in einem meiner Netze.
https://forum.opnsense.org/index.php?topic=21250.msg99625#msg99625
Deine Pakete werden von der OPNsense an den Cisco geleitet, die SourceIP wird aber standardmäßig nicht umgeschrieben, somit Anwortet der Cisco direkt an den Client - dieser wartet aber nur auf Antworten von der OPNsense.
Ähnliches / gleiches Problem wie so oft auch in anderen Fällen. Asymmetrisches Routing kann solche Effekte erzeugen. Alleine dass du die Regel für SSH anpassen musstest ist da schon hartes Indiz für, dass es so in der Konstellation einfach nicht rund läuft.
Du hast zwei Möglichkeiten, wobei die zweite die Sinnvollere ist:
a) wenn die Sense das Default GW ist und daher alles annimmt und zum Cisco schickt: aktiviere NAT für die Verbindung sofern das machbar ist (sprich wenn nur ihr zur Gegenseite müsst, die andere Seite aber nicht wirklich zu euch). Am Besten mit einer sehr spezifischen Regel, also bspw. nur 192.168.2.0/24 -> 192.168.10?.0/24 (also ins VPN entfernte Fremdnetz). Dann schickt die Sense die Pakete aus Cisco Sicht und bekommt daher auch die Antworten zurück, State Inspection und Routing kann sauber ablaufen, fertig.
b) (wesentlich sinnvoller): Mit dem Betreuer des Ciscos bei euch in Verbindung setzen, kurz schildern, dass das Setup so eben Probleme macht weil nicht sinnvolles Routing und das Setup ändern: Cisco via Transfernetz direkt an die OPNsense anschließen (bspw. nen extra VLAN zwischen Cisco und Sense machen oder direkt verkabeln auf ein freies Interface - was eben sinnvoller ist bei euch) und das Routing entsprechend anpassen. Bspw. zwischen Sense und Cisco das XFER Netz 172.17.17.0/30 auflegen, Sense bekommt 1, Cisco bekommt 2 und Cisco bekommt Route dass 192.168.2.0/24 bitte zu 172.17.17.1 geschickt werden soll. VPN Settings auf dem Cisco können komplett so bleiben wie sie sind, denn der Tunnel soll ja weiterhin 192.168.2 nach 192.168.10 und zurück routen. Nur dass eben das .2.x Netz nicht mehr direkt am Cisco aufliegt, sondern via XFER direkt an die Sense geschickt wird.
Dadurch bekommt man wieder eine gerade Linie fürs Routing und alles läuft sauber geroutet über die OPNsense und man muss keine fixes für künstliche Probleme basteln :)
Cheers
\jens
Zu nächst einmal vielen lieben Dank für die Antworten.
Es gibt in der Tat ein asynchrones Routing. Das war mir schon bewusst. Daher kam ich je auch auf die Idee, den Verbindungszustand zu ignorieren. Was ja zu mindestens teilweise funktioniert hat...
Ich muss lernen ein wenig pragmatischer zu denken. Statt den eigentlichen Fehler zu finden, hätte ich echt lieber zusehen müssen, dass das Routing irgendwie wieder gerade gezogen wird.
Wobei ich schon gerne im Detail verstehen würde was da passiert... ::)
Ich werde nochmal berichten, wenn ich einen Lösung umgesetzt habe. Danke!
> Es gibt in der Tat ein asynchrones Routing.
Not to be nitpicking, aber es ist nicht asynchron, sondern asymmetrisch. Es geht nicht um Nebenläufigkeit, sondern tatsächlich um die "Symmetrie" des Netzes, dass das Paket den gleichen Weg hin wie zurück nimmt also symmetrisch läuft ;) Bei asynchronem Verhalten hättest du noch ganz andere Probleme :D
> Ich muss lernen ein wenig pragmatischer zu denken. Statt den eigentlichen Fehler zu finden, hätte ich echt lieber zusehen müssen, dass das Routing irgendwie wieder gerade gezogen wird.
Ich glaube da kritisierst du dich falsch rum :) Du hast mit dem State fix eher den Workaround gemacht, statt den eigentlich Fehler - das Routing - zu korrigieren/finden. Also Klebeband statt Rohr ausgetauscht :D
Ansonsten ist das Detail mehr oder weniger spannend und hängt dann von mehreren Dingen ab was genau passiert. Was auf jeden Fall passiert ist, dass der Rücktraffic über den Cisco durch dessen Dasein im gleichen Netz direkt zum Client durchgestellt wird. Das kann(!) für viele Trafficarten OK sein, manchmal gibt aber auch das schon Probleme. Der Hinweg geht via Router, Cisco VPN und dann zum Ziel, die Antworten kommen dann zurück und laufen via VPN Cisco direkt zum Client. Der kann darauf ziemlich irritiert reagieren, denn er hat die Anfrage schließlich an sein Gateway geschickt, bekommt aber Antwortpakete von einer anderen IP (dem Cisco) als die die er gefragt hat. Wie gesagt gibt es einiges, was damit so halbwegs gut klar kommt, aber einige Verbindunen, Dienste oder Protokolle haben damit ein Problem, da sie auf die Antwort von der IP warten, an die sie die Frage geschickt haben.
Im Endeffekt hast du also 3 Personen im Raum. Dein Client, deine Sense und den Cisco, der via Stöpsel im Ohr (VPN) Sachen nachfragen und beantworten kann. Vereinfacht fragt dein Client jetzt nach Daten von dem Server hinter dem Cisco. Da er den Cisco nicht kennt (persönlich), fragt er die Sense, die dreht sich zum Cisco (weil sie den kennt / Route) und fragt ihn, der fragt seinen Publikumsjoker (den Server) und dreht sich dann zum Client und gibt die Antwort direkt. Jedes Mal wenn eine Frage kommt, quatscht der Cisco dann plötzlich mit der Antwort den Client direkt zu der darauf ziemlich irritiert wird, stellt er die Frage schließlich seinem Ansprechpartner im Raum (der Sense).
Ich wäre da auch ziemlich hin- und hergerissen :D
Cheers
\jens