OPNsense Forum
International Forums => German - Deutsch => Topic started by: mwerth on July 24, 2020, 11:15:17 am
-
Hallo,
ich habe ein Routing-Problem mit einer aktuellen OPNsense Installation. Wenn ich einen Host im Subnetz anpinge, wird das Paket nicht an den Router geschickt, sondern an das Default-Gateway obwohl die Route korrekt gesetzt ist.
Setup-Übersicht
- 172.17.3.1 - Default Gateway
- 172.17.3.10 - Adresse des externen Interfaces (igb4) der OPNsense
- 172.17.3.76 - Gateway für das Subnetz 10.100.0.0/24
Diagnose
# route show 10.100.0.1
route to: 10.100.0.1
destination: 10.100.0.0
mask: 255.255.255.0
gateway: 172.17.3.76
fib: 0
interface: igb4
flags: <UP,GATEWAY,DONE,STATIC>
Ich habe mir die Ethernet-Pakete auf dem igb4-Interface mit tcpdump angesehen.
# tcpdump -e -i igb4 -n ip proto \\icmp and net 10.100.0.0/24
...
10:58:18.584392 6c:b3:11:22:2b:b6 > cc:ce:1e:d8:4d:c6, ethertype IPv4 (0x0800), length 98: 172.17.3.10 > 10.100.0.1: ICMP echo request, id 40277, seq 0, length 64
Diese werden blöderweise an das Default-Gateway geschickt (cc:ce:1e:d8:4d:c6) anstatt an den 172.17.3.76 (ee:30:5d:8a:54:31)
# arp -a -n | egrep 172.17.3.1\|172.17.3.76
? (172.17.3.76) at ee:30:5d:8a:54:31 on igb4 expires in 365 seconds [ethernet]
? (172.17.3.10) at 6c:b3:11:22:2b:b6 on igb4 permanent [ethernet]
? (172.17.3.1) at cc:ce:1e:d8:4d:c6 on igb4 expires in 1197 seconds [ethernet]
Wie kann ich das weiter Debuggen?
Kann ich das Paket irgendwo im System "verfolgen"?
Edit: IP-Adresse des GW korrigiert.
-
OK wo kommt denn jetzt die .76 her? Oben listest du .1, .10 und .74 auf und jetzt ist das Gateway weiter unten aber die .76? Wer ist das und warum?
Kannst du da ggf. eine kleine Skizze machen wie das wo warum verkabelt ist, denn so steige ich gerade nicht durch, was da versucht wird zu erreichen und von wo du überhaupt wen versuchst anzupingen :o
Grüße
\jens
-
Dieses Verhalten tritt nur auf wenn du in Interfaces : XXX auch ein Upstream Gateway gesetzt hast, oder das Interface ein DHCP Client ist. Dann wird jeden Paket, egal ob es auch ins gleiche Netz geht erst an das Gateway geschickt.
Gibt eine hitzige Diskussion darüber ob das so sinnvoll, ich denke aber mit 20.7 werden da keine Defaults mehr geändert.
Entweder
- Upstream Gateway austragen -> dann brauchst du manuelle NAT Regeln und ein Gateway
- Disable Reply-to in Firewall : Settings : Advanced
- Eine FIrewallregel auf dem entsprechenden Interface und in Advanced nur dort den Haken bei "Disable Reply-to" (da muss man mit den Richtungen etwas spielen)
-
Hi Jens,
OK wo kommt denn jetzt die .76 her? Oben listest du .1, .10 und .74 auf und jetzt ist das Gateway weiter unten aber die .76? Wer ist das und warum?
Das war ein Fehler. Habe ich korrigiert.
Der Ping wird auf der OPNsense ausgeführt.
+------------+ +----------+
| |172.17.3.1 172.17.3.10| |
| Default-GW +--------------+---------------+ OPNsense |
| | | igb4| |
+------------+ | +----------+
|
|172.17.3.76
+-----+------+
| |
| Subnetz-GW |
| |
+------------+
-
Dieses Verhalten tritt nur auf wenn du in Interfaces : XXX auch ein Upstream Gateway gesetzt hast, oder das Interface ein DHCP Client ist. Dann wird jeden Paket, egal ob es auch ins gleiche Netz geht erst an das Gateway geschickt.
Das ist IMHO ein seltsames Verhalten. Womit wird das begründet?
- Upstream Gateway austragen -> dann brauchst du manuelle NAT Regeln und ein Gateway
Wozu benötige ich eine manuelle NAT Regel? Also SNAT?
Wie werden dann die Pakete geroutet, die von der OPNsense ausgehen. Soweit ich das verstanden habe, greifen die Gateway-Routen des Policy Routing in den Firewall Settings nur, wenn ein Paket die OPNsense passiert und nicht direkt auf dem System generiert und verschickt wird.
- Disable Reply-to in Firewall : Settings : Advanced
- Eine FIrewallregel auf dem entsprechenden Interface und in Advanced nur dort den Haken bei "Disable Reply-to" (da muss man mit den Richtungen etwas spielen)
Ok. Das werde ich mal testen.
Vielen Dank und Gruß,
Martin
-
Das ist ein uraltes legacy Verhalten von pfsense, da traut sich momentan keiner ran. Ich glaub pfsense selbst hat das schon geändert. Bitte frag nicht nach der Logik .. es war wahrscheinlich irgendjemand der halt von größeren Umgebungen keine Ahnung hatte und meinte dass macht weniger Support input.
Die Mühlen malen langsam .. ich versuch das bis 21.1 zu regeln :)
Also, Upstream Gateway in Interfaces hat 2 Funktionen:
1. Erstelle eine reply-to regel, dass für jeden Paket, welches auf diesem Interface raus kommt, an sein Gateway geschickt wird. Das gilt dann eben auch für Pakete von Hosts aus dem gleichen Netz, ärgerlich, bitte nicht diskutieren (Fix wäre reply-to abzustellen)
2. Bei Automatic NAT oder Hybrid NAT in Firewall : NAT : Outbound wird jedes Netz was NICHT upstream gesetzte hat, automatisch nach außen ÜBER das interface was upstream gesetzt hat, genattet, in Linux-sprech, SNAT. D.h. wenn du auto nat hast und du nimmst upstream raus, brauchst du hybrid oder manual nat und muss sagen source LAN, destination ANY, interface WAN
So, jetzt suche ich den alten Issue und male weiter die Mühlen :)
-
> Ich glaub pfsense selbst hat das schon geändert.
Soweit ich sehe/weiß, ja, sollte schon länger raus sein. Das Verhalten wäre mir zumindest von pfS Installationen gänzlich neu ;)
Aber das Verhalten von 2) ist mit ein Grund warum ich eigentlich den meisten Usern Nahe lege, dass sie ihr NAT auf manuell schalten und es selbst regeln, damit eben nichts automagisch erstellt wird was man vielleicht nicht - oder in dem Fall durchaus - haben will :) Außerdem mehr Kontrolle aber naja, das mag nur mir so gehen :D
-
https://forum.opnsense.org/index.php?topic=15900.msg73203#msg73203
Wobei ich bei mir ein paar Systeme durchgesehen habe, auch mit pppoe und dhcp und da steht das immer richtig drin:
pass out log route-to (igb0 109.90.53.125) inet from 109.90.53.126 to ! (igb0:network) flags S/SA keep state allow-opts label "8ae1aae82a27b943342b684e2fce74b7"
! (igb0:network) ist ja dann korrekt. Bin grad etwas verwirrt weil kein System bei mir so ein Verhalten hat.
Kannst du mal auf der Console tippen:
pfctl -s all | grep route-to
-
Wobei ich bei mir ein paar Systeme durchgesehen habe, auch mit pppoe und dhcp und da steht das immer richtig drin:
Die Adressen sind auf dem System statisch konfiguriert.
Kannst du mal auf der Console tippen:
pfctl -s all | grep route-to
Gern.
pass out log route-to (igb2 11.22.33.76) inet from 11.22.33.73 to ! (igb2:network) flags S/SA keep state allow-opts label "label1"
pass out log route-to (igb0 192.168.2.5) inet from 192.168.2.200 to ! (igb0:network) flags S/SA keep state allow-opts label "label2"
pass out log route-to (igb4 172.17.3.1) inet from 172.17.3.10 to ! (igb4:network) flags S/SA keep state allow-opts label "label3"
pass out log route-to (igb5 11.22.33.65) inet from 11.22.33.66 to ! (igb5:network) flags S/SA keep state allow-opts label "label4"
pass in log quick on igb2 route-to (igb4 172.17.3.1) inet from 11.22.33.33 to any flags S/SA keep state label "label5"
pass in quick on igb2 route-to (igb4 172.17.3.1) sticky-address inet proto tcp from <mailgw> to any port = smtp flags S/SA keep state label "label6"
pass out log on igb5 route-to (igb5 11.22.33.65) inet proto udp from any to 62.225.42.158 port = isakmp keep state label "label7"
pass out log on igb5 route-to (igb5 11.22.33.65) inet proto esp from any to 62.225.42.158 keep state label "label8"
-
Welcher Interface wäre denn das betroffene? Mach noch das Gleiche für "reply-to" statt "route-to" .. bin grad verwirrt, sorry :o
-
Welcher Interface wäre denn das betroffene? Mach noch das Gleiche für "reply-to" statt "route-to" .. bin grad verwirrt, sorry :o
Das Setup wurde aus einer gewachsenen Struktur migriert und ist leider etwas komplex und ist grob so aufgebaut. :-/
Es geht um das Interface igb4.
+------------+
| OPNsene |
+------------+ ---+igb5 |
| |172.17.3.1 | |
| Default-GW +--------------+---------------+igb4 igb2+----INTERN
| | | 172.17.3.10| |
+------------+ | +------------+
|
|172.17.3.76
+-----+------+
| |
| Subnetz-GW |
| |
+------------+
Ich habe die PF-Ausgabe mal auf igb4 beschränkt:
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to 11.22.33.77 port = openvpn flags S/SA keep state label "label1"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from any to 11.22.33.77 port = openvpn keep state label "label1"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <LW_Service> to (self) flags S/SA keep state label "label2"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <LW_Service> to (self) keep state label "label2"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from (igb4:network) to (self) port = domain flags S/SA keep state label "label3"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from (igb4:network) to (self) port = domain keep state label "label3"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to (self) port = smtp flags S/SA keep state label "label4"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to <mailgw2> port = smtp flags S/SA keep state label "label5"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet from <OVPN_Transfer> to <Server_Netzwerk> flags S/SA keep state label "label6"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto esp from <SH_IPSec_GW> to (self) keep state label "label7"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <SH_IPSec_GW> to (self) port = sae-urn flags S/SA keep state label "label8"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <SH_IPSec_GW> to (self) port = sae-urn keep state label "label8"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <SH_IPSec_GW> to (self) port = isakmp flags S/SA keep state label "label9"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <SH_IPSec_GW> to (self) port = isakmp keep state label "label9"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to 11.22.33.75 port = smtp flags S/SA keep state label "label10"
-
Da alle Regeln ein label haben sind das keine Auto Rules. Komisch.
Also momentan schickt der die Replies and .1 und nicht an .76?
-
Da alle Regeln ein label haben sind das keine Auto Rules. Komisch.
Also momentan schickt der die Replies and .1 und nicht an .76?
Ja. Genau genommen die ICMP Echo Requests.
Offenbar funkt mir da auch noch das SNAT dazwischen. Kann das die Ursache sein?
Ich habe mal von einem Host aus dem inneren Netzwerk an die 10.100.0.1 gepingt. Da laufen die Pakete wie folgt:
[192.168.2.60] ----> [igb0:192.168.2.200 OPNsense igb4:172.17.3.10] ----> [172.17.3.1]
Wenn ich mir die eingehenden Pakete jetzt auf igb0 ansehe:
17:10:24.759013 b4:39:d6:f0:e4:00 > 00:24:1d:72:a7:22, ...: 192.168.2.60 > 10.100.0.1: ICMP echo request, id 30950...
und die von der OPNsene ausgehenden auf igb4:
17:10:19.719023 6c:b3:11:22:2b:b6 > cc:ce:1e:d8:4d:c6, ...: 172.17.3.10 > 10.100.0.1: ICMP echo request, id 55412...
dann greift hier das SNAT auf dem Interface igb4. Die Mac-Adresse cc:ce:1e:d8:4d:c6 ist die von dem Default-Gateway.
Kann das die Ursache sein?
-
Ups. Hatte ganz vergessen, die Lösung mitzuteilen.
Dieses Verhalten tritt nur auf wenn du in Interfaces : XXX auch ein Upstream Gateway gesetzt hast, oder das Interface ein DHCP Client ist. Dann wird jeden Paket, egal ob es auch ins gleiche Netz geht erst an das Gateway geschickt.
Entweder
- Upstream Gateway austragen -> dann brauchst du manuelle NAT Regeln und ein Gateway
Nachdem ich auf der Schnittstelle igb4 den Punkt IPv4 Upstream Gateway auf "auto-detect" gesetzt hatte, war das Problem gelöst.