Hallo zusammen,
nutze das Legacy Plugin.
2 Zustände:
Lasse ich beim VPN Client die routen ziehen komme ich über das VPN an meine Webserver , ping usw. So wie es eben soll.
Dafür kann ich dann nicht mehr aus dem LAN raus ins Internet.
Mach ich beim VPN Client no route pull, komme ich vom LAN ins Netz und dafür aber nicht mehr an meiner Webserver und co.
Was übersehe ich ?
Config:
LAN > 192.168.1.0/24
WAN > über Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 groutet ist
Die Firewall DMZ hat die erste Nutzbare IP Adresse des / 29 als Interface Adresse
DMZ > 195.8.xx.xx.1/29
Füge bei der Allow-Regel am LAN deinen Gateway ausdrücklich hinzu.
OK, irgendwie bin ich echt zu blöd für Networking....
Aber macht es nicht Sinn, dass WAN > über Vlan 132 32.xx.xx./24 das default GW ist ?
Im Moment ist das VPN das default GW und ich weiss nicht warum ?
Hier mal das was unter System > Gateways > Configuration ist:
Irgendwie sieht das auch nicht ganz so richtig aus.
Quote from: fw115 on August 04, 2025, 06:04:22 PMAber macht es nicht Sinn, dass WAN > über Vlan 132 32.xx.xx./24 das default GW ist ?
Hängt von deiner Umgebung ab.
Aber es funktioniert doch, wenn du die VPN deaktivierst? So wird das nicht die Ursache deiner Probleme sein.
Quote from: fw115 on August 04, 2025, 06:04:22 PMIm Moment ist das VPN das default GW und ich weiss nicht warum ?
Wenn der Server die Default-Route pusht und "route no-pull" nicht aktiviert ist, ist das so.
Ich weiß noch immer nicht, was du eigentlich haben möchtest. Nur Zugriff aus der VPN aufs DMZ? Nur DMZ über VPN? Allen Upstream Traffic über die VPN?
Für Upstream Traffic über die VPN braucht es eine Outbound NAT Regel am VPN Interface.
Seine DMZ bekommt über das VPN ein globales /29 geroutet ...
Ja, hatte ich noch in Erinnerung. Aber das beantwortet nicht, wie er mit ausgehenden Traffic verfahren möchte.
Genau.
Hier nochmal meine Gateways als Screen Shot.
Warum steht das WAN mit defunct (upstream) da drin ? Versteh ich nicht.
Quote from: viragomann on August 04, 2025, 09:13:01 PMJa, hatte ich noch in Erinnerung. Aber das beantwortet nicht, wie er mit ausgehenden Traffic verfahren möchte.
Also:
Alles aus dem und in das LAN über :
WAN > über Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
alles aus der DMZ und in die DMZ :
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 groutet ist 1 nutzbare /29 Adresse hat das Interface der DMZ.
Wenn du verschiedene Gateways nutzen möchtest, kommst du um Policy-Routing nicht herum.
Das würde ich dann für die DMZ machen.
Also erst mal im OpenVPN Client "route no-pull" aktivieren.
Und dann in der DMZ Regel, die ausgehenden Traffic erlaubt, das VPN Gateway setzen.
Benötigt die DMZ Zugriff auf lokale Services, bspw. DNS auf der OPNsense, musst du eine eigene Regel dafür erstellen, die nur für Zielport 53 und diese über die Policy-Routing setzen, denn diese zwingt allen Traffic, auf den die Bedingungen zutreffen (Protokoll, Quell-IP, -Port, Ziel-IP, -Port) auf das Gateway.
Stimme zu - über das OpenVPN keine Default-Route ziehen. reply-to einschalten bzw. eingeschaltet lassen (ist der Default) und für die DMZ eine Policy-Regel anlegen.
OK,
habe route- no-pull gesetzt.
dann in OPENvpn eine Rule erstellt:
ipv4 ICMP > Soource * > Port * > Dest. DMZ Net > Port * > Gateway _VPN_LEG_VPNv4
Kein Ping mehr möglich.
Jetzt kommt sicher wieder mein Problem, dass ich Garantiert im falschem Interface bin
oder nicht verstanden habe wie die DMZ Policy-Regel richtig angelegt wird, da kein ping usw. mehr funktioniert.
Quote from: fw115 on August 04, 2025, 10:00:34 PMJetzt kommt sicher wieder mein Problem, dass ich Garantiert im falschem Interface bin
Interface könnte VPN_LEG sein, ist aber nicht entscheidend für diesen Zweck.
Aber die Destination muss any sein.
DMZ net würde nur Traffic auf die FW Interface IP betreffen.
Du hast eine globale Floating Rule, die "ping" erlaubt wie in dem anderen Thread empfohlen? Dann solltest du die VPN-Adresse der OPNsense und die Adresse der OPNsense in der DMZ bereits aus dem Internet anpingen können. Klappt das?
Die Policy-Rule brauchst du für den ausgehenden Verkehr der Server in der DMZ - die gehört also auf das DMZ-Interface.
Und für eingehenden Verkehr brauchst zu z.B.
Interface: das OpenVPN-Dings
Source: any
Destination: DMZ net
Destination port: z.B. 80 und 443 - man kann einen Alias bauen mit beidem und den z.B. "Web" nennen
Das sollte es eigentlich sein. Der VPN-Provider schickt den Kram ja in den Tunnel und dann landet er bei deinen Servern. Der "state" in Verbindung mit reply-to (per Default an) sollte dafür sorgen, dass die Antworten auch wieder im Tunnel landen.
Quote from: Patrick M. Hausen on August 04, 2025, 10:17:50 PMDu hast eine globale Floating Rule, die "ping" erlaubt wie in dem anderen Thread empfohlen? Dann solltest du die VPN-Adresse der OPNsense und die Adresse der OPNsense in der DMZ bereits aus dem Internet anpingen können. Klappt das?
Wenn route-no-pull nicht disabled ist, dann ja. Nehme ich route pull raus, vorbei mit ping.
Quote from: Patrick M. Hausen on August 04, 2025, 10:17:50 PMDie Policy-Rule brauchst du für den ausgehenden Verkehr der Server in der DMZ - die gehört also auf das DMZ-Interface.
Ich glaube ich check mal wo was lang geht mit :
curl --interface igb0 https://ifconfig.me
Und für eingehenden Verkehr brauchst zu z.B.
Interface: das OpenVPN-Dings
Source: any
Destination: DMZ net
Destination port: z.B. 80 und 443 - man kann einen Alias bauen mit beidem und den z.B. "Web" nennen
Das sollte es eigentlich sein. Der VPN-Provider schickt den Kram ja in den Tunnel und dann landet er bei deinen Servern. Der "state" in Verbindung mit reply-to (per Default an) sollte dafür sorgen, dass die Antworten auch wieder im Tunnel landen.
Genau so habe ich es auch gemacht. Allerdings ging dann alles über das VPN.
iCh glaube ich check das mal mit:
curl --interface igb0 https://ifconfig.me
Komm doch am Freitag mal zum virtuellen Stammtisch, dann gucken wir uns den Kram live an.
Der Jens hat mit OpenVPN auch noch deutlich mehr Erfahrung als ich, ich benutz wo ich kann lieber IPsec oder WireGuard.
Stammtisch-Info: https://forum.opnsense.org/index.php?topic=18183.0
Quote from: Patrick M. Hausen on August 04, 2025, 10:38:36 PMKomm doch am Freitag mal zum virtuellen Stammtisch, dann gucken wir uns den Kram live an.
Der Jens hat mit OpenVPN auch noch deutlich mehr Erfahrung als ich, ich benutz wo ich kann lieber IPsec oder WireGuard.
Stammtisch-Info: https://forum.opnsense.org/index.php?topic=18183.0
Ich hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.
Ich würde wirklich sehr gerne vorbei schauen, leider bin ich genau dieses WE schon verplant. Wie das so ist im Leben.
Und ich merke auch, dass Netzwerken nicht ganz so meine Welt ist (wohl auch der Grund warum ich IPv6 hasse wie die Pest, aber das ist ein anderes Thema).
Vielleicht erbarmt sich ja jemand und schaut mal für 15 min in der Woche danach mit mir auf mein System.
Mal sehen, ansonsten wird das wohl bis zum 22. warten müssen.
Danke an alle für die Hilfe!
Könntest du bitte mal alle Floating Regeln und alle auf OpenVPN zeigen?
Quote from: fw115 on August 04, 2025, 10:55:20 PMIch hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.
Das ist ja auch nicht schlimm - ich mache genau dasselbe für 2 Kunden, die über je einen WireGuard-Tunnel IP-Adressen aus meinem AS aus einem Interface ihrer OPNsense rauströpfeln lassen. Die hatten halt vor 20 Jahren mal eine 2 Mbit Leitung von uns zu astronomischen Preisen und haben sich dann vor ein paar Jahren eine DSL-Leitung der Telekom geklickt und wollten irgendwie unsere Adressen behalten.
Funktioniert alles - der Policy-Kram ist halt nicht ganz trivial.
Hier die Rules:
Quote from: Patrick M. Hausen on August 04, 2025, 11:58:33 PMQuote from: fw115 on August 04, 2025, 10:55:20 PMIch hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.
Das ist ja auch nicht schlimm - ich mache genau dasselbe für 2 Kunden, die über je einen WireGuard-Tunnel IP-Adressen aus meinem AS aus einem Interface ihrer OPNsense rauströpfeln lassen. Die hatten halt vor 20 Jahren mal eine 2 Mbit Leitung von uns zu astronomischen Preisen und haben sich dann vor ein paar Jahren eine DSL-Leitung der Telekom geklickt und wollten irgendwie unsere Adressen behalten.
Funktioniert alles - der Policy-Kram ist halt nicht ganz trivial.
Das merke ich gerade.
Witzig gerade: Ich kann Webseiten aufrufen aus dem LAN , aber nicht aus dem LAN pingen....
Ich Blick es nich mehr....
Ich würde gerne die Zusammenhänge verstehen und verstehe es nicht. Joa, merkt man am Ergebnis :)
Dein grundlegendes Verständnisproblem mit den Interfaces verstehe ich nun aber auch nicht ganz. Ich komme von viel Cisco (IOS, PIX, ASA) und vor allem der Secure Computing Sidewinder zur OPNsense und bei jeder anderen Firewall gehört eine Regel auf das Interface, an dem das System hängt, das die Verbindung initiiert. Ist wirklich global so. Bissi Berührung mit Checkpoint hatte ich auch - ebenfalls kein Unterschied.
Weshalb ist das mit den Interfaces so kompliziert in deinem Kopf?
System im Internet will Dinge von den Servern - IP kommt über den Tunnel rein --> Regel muss auf das Tunnel-Interface.
System im LAN will Dinge im Internet --> Regel muss auf das LAN.
Etc. Easy? Oder?
Quote from: Patrick M. Hausen on August 05, 2025, 12:28:44 AMDein grundlegendes Verständnisproblem mit den Interfaces verstehe ich nun aber auch nicht ganz. Ich komme von viel Cisco (IOS, PIX, ASA) und vor allem der Secure Computing Sidewinder zur OPNsense und bei jeder anderen Firewall gehört eine Regel auf das Interface, an dem das System hängt, das die Verbindung initiiert. Ist wirklich global so. Bissi Berührung mit Checkpoint hatte ich auch - ebenfalls kein Unterschied.
Weshalb ist das mit den Interfaces so kompliziert in deinem Kopf?
System im Internet will Dinge von den Servern - IP kommt über den Tunnel rein --> Regel muss auf das Tunnel-Interface.
System im LAN will Dinge im Internet --> Regel muss auf das LAN.
Etc. Easy? Oder?
Eigntlich ja, ich denke ich stehe mir aus Unsicherheit mit dem neuem System( is das was ich gemacht habe wirklich richtig?) mehr selber im Weg als ich sollte.
Die einzige Firewall die ich kenne, ist eben die Astaro die dann zur Sohopos UTM wurde. Aktuell V9.
In der Astaro hab ich 3 Interfaces. Das war es dann.
LAN
DMZ
WAN
VPN wird gar nicht als Interface wie in der OPNsense definiert.
Da wird kein Interface nochmal zugewiesen wie bei der Opnsense z.B. VPN oder das vlan 132
So sieht z.B das WAN bei der Sophos aus. Ich hab kein extra Vlan Interface das irgenwo assigend werden muss und habe dann auch nur 1 Interface WAN und nicht ein WAN und ein VLAN das mir angezeigt wird.
VLAN Tag rein, erledigt.
Macht das ganze deutlich übersichtlicher und einfacher nachzuvollziehen.
Und so gibt es viele Sachen die bei opsense in Zig Menüs aufgesplittet sind und die config einfach extrem unübersichtlich machen.
Als Anfäger in Opnsense und von der Oberfläche der Astaro ( is für mich eben immer noch Astaro obwohl von Sophos übernommen)kommend, bekommt man einfach einen Fön.
Quote from: fw115 on August 05, 2025, 12:16:38 AMHier die Rules:
Ich zitiere dazu Zeilen aus meinem ersten Post in deinem anderen Thread OpenVPN Client Config > sehe den Wald vor lauter Bäumen nicht. (https://forum.opnsense.org/index.php?topic=48075.0):
QuoteWichtig:
- Der OpenVPN Client Instanz musst du ein Interface explizit zuweisen, falls das noch nicht geschehen ist.
- In Firewall: Rules: OpenVPN darf keine Pass-Regel existieren. Jedenfalls keine, die auf die weitergeleiteten Pakete zutrifft.
Das "Wichtig" hatte ich davor gesetzt, weil es unbedingt zu beachten ist, will man Erfolg mit einem solchen Setup haben.
Erkennst du jetzt den Fehler?
Quote from: viragomann on August 05, 2025, 07:56:50 AMQuote from: fw115 on August 05, 2025, 12:16:38 AMHier die Rules:
Ich zitiere dazu Zeilen aus meinem ersten Post in deinem anderen Thread OpenVPN Client Config > sehe den Wald vor lauter Bäumen nicht. (https://forum.opnsense.org/index.php?topic=48075.0):
QuoteWichtig:
- Der OpenVPN Client Instanz musst du ein Interface explizit zuweisen, falls das noch nicht geschehen ist.
- In Firewall: Rules: OpenVPN darf keine Pass-Regel existieren. Jedenfalls keine, die auf die weitergeleiteten Pakete zutrifft.
Das "Wichtig" hatte ich davor gesetzt, weil es unbedingt zu beachten ist, will man Erfolg mit einem solchen Setup haben.
Erkennst du jetzt den Fehler?
Ja ich erkenne den Fehler das alle Rules die ich in OPENvpn gesetzt habe da raus müssen und in das von mir definierte Interface müssen.
Verstehe aber die unterschiedliche Behandlung der Interfaces nicht, siehe oben das Beispiel vom WAN der Astaro.
Was ist der Sinn dieser Art des Handlings ? Welchen Vorteil hat das ? Welche Einstellungen kann ich evt mehr vornehmen bei dieser Art des Setups ?
Warum die Aufteilung ? Warum nicht nur 1 Interface ?
Ich gehe dann davon aus, dass es sich bei WAN und VLAN132 ähnlich verhält.
Es geht um reply-to. Ich dachte, Patrick hatte es eh auch im anderen Tread schon (mehrmals) erwähnt.
Die Sache ist, standardmäßig folgen den Pakete der Routing-Tabelle. Hier geht es konkret um die Antwortpakete der DMZ. Die Default-Route zeigt nun aber auf das WAN GW, wenn in OpenVPN "route no-pull" nicht gesetzt ist.
Damit die Pakete dennoch richtig zurück geroutet werden könne, versieht OPNsense die Verbindung mit dem "reply-to" Tag, das das Gateway enthält, wo die Antwort hin soll. Das Tagging passiert durch die Regel, die den eingehenden Traffic (das SYN-Paket) erlaubt. Das Gateway holt sich OPNsense dabei aus der Interface-Konfiguration. Bei OpenVPN wird diese automatisch gemacht, also auch das Gateway.
Damit dieses Tagging funktioniert, muss OPNsense aber eindeutig das Gateway erkennen können. Dafür muss die zutreffende Regel, eindeutig einem Interface zuordenbar sein. Das gilt aber natürlich nicht für Floating Regeln und Regeln auf eine Interface-Gruppe. Diese können ja auf mehreren Interfaces definiert sein. OpenVPN ist aber eine Gruppe, die sämtliche OpenVPN Interfaces enthält, auch wenn du nur eine Instanz betreibst. Daher kein reply-to.
Wenn du erst eine Erklärung für dein Verständnis benötigst, um die Anweisungen zu befolgen, hättest du aber schon früher danach fragen können. Wir erklären alle gerne, aber zumindest ich nicht gerne unnötig, und manche interessieren die Hintergründe auch gar nicht.
Um die Regeln zu übersiedeln, brauchst du sie nur zu editieren und das Interface ändern, falls dir die Handhabe nicht geläufig ist.
OK, ich habe verstanden, dass OPENvpn ein Globales Interface ist, in das alle Rules rein kommmen, die für alle erstellten VPNs gültig sind.
Nun habe ich alle Rules aus OPENvpn entfernt und in mein legacy Interface VPN_Leg überführt, ich habe im Legacy Client in "Don't pull Routes" einen Haken drin.
Keine weiteren Änderungen.
Ergebnis:
nicht mehr erreichbar. Der Tunnel steht und ist connected allerdings finden sich folgende Fehler im Logfile:
Quote2025-08-05T10:46:00 Warning openvpn_client2 ERROR: FreeBSD route add command failed: external program exited with error status: 1
2025-08-05T10:46:00 Error openvpn_client2 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
2025-08-05T10:46:00 Error openvpn_client2 Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS])
2025-08-05T10:45:59 Warning openvpn_client2 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-08-05T10:45:59 Warning openvpn_client2 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2025-08-05T10:45:59 Warning openvpn_client2 WARNING: using --pull/--client and --ifconfig together is probably not what you want
2025-08-05T10:45:59 Warning openvpn_client2 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2025-08-05T10:45:59 Warning openvpn_client2 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2025-08-05T10:45:59 Error openvpn_client2 event_wait : Interrupted system call (fd=-1,code=4)
hier nochmal die vpn.conf vom provider:
Quotetls-client
client
dev tun
proto tcp
#proto tcp6
tun-mtu 1500
remote vpn3.xxx.de 1194
verify-x509-name vpn3.xxx.de name
cert cert_vpn.pem
key key_vpn.pem
ca vpn-ca.pem
cipher BF-CBC
comp-lzo
verb 3
Von dem Log ist mir nur die erste Zeile unklar. Mit "Don't pull Routes" sollte gar kein "route add" ausgeführt werden, es sei denn, du hast in "Remote Network" was eingetragen.
Mit "nicht mehr erreichbar" meinst du deine DMZ aus dem Internet über VPN?
Wenn es ohne "Don't pull Routes" funktioniert sollte es mit der VPN ja nichts zu tun haben. Dann kann es eigentlich nur daran liegen, dass reply-to nicht funktioniert.
Überprüfen kannst du da mit Packet Capture. Funktioniert es nicht, gehen die Antwort-Pakete um WAN raus, entsprechend der Default-Route.
Wenn das so ist, stelle nochmals sicher, dass
- auf OpenVPN keine Pass-Regel aktiv ist.
- in Firewall: Settings: Advanced reply-to nicht deaktiviert ist.
- reply-to in den jeweiligen Firewall-Regeln am VPN_Leg Interface nicht deaktiviert ist (Advanced Features). Du könntest da auch versuchsweise explizit das VPN Gateway angeben.
- die Firewall-Regeln am VPN_Leg auch zutreffen, indem du das Logging aktivierst und es dann im Log überprüfst.
Quote from: viragomann on August 05, 2025, 12:15:58 PMVon dem Log ist mir nur die erste Zeile unklar. Mit "Don't pull Routes" sollte gar kein "route add" ausgeführt werden, es sei denn, du hast in "Remote Network" was eingetragen.
Mit "nicht mehr erreichbar" meinst du deine DMZ aus dem Internet über VPN?
Wenn es ohne "Don't pull Routes" funktioniert sollte es mit der VPN ja nichts zu tun haben. Dann kann es eigentlich nur daran liegen, dass reply-to nicht funktioniert.
Ja genau. Nehme ich den Haken bei "Don't pull routes" raus, funktioniert kein Ping, kein SSH usw. an die DMZ
Setzte ich ihn wieder , funktioniert ping usw.
Dafür geht im LAN nichts mehr
Also gehe ich von einem Routing Problem aus.
Wenn ich : tcpdump -i ovpnc1 -n auf der Firwall Shell mache, sehe ich das jede Menge Traffic auf ovpnc1 ankommt.
Quote from: viragomann on August 05, 2025, 12:15:58 PMÜberprüfen kannst du da mit Packet Capture. Funktioniert es nicht, gehen die Antwort-Pakete um WAN raus, entsprechend der Default-Route.
Wenn das so ist, stelle nochmals sicher, dass
- auf OpenVPN keine Pass-Regel aktiv ist.
- in Firewall: Settings: Advanced reply-to nicht deaktiviert ist.
- reply-to in den jeweiligen Firewall-Regeln am VPN_Leg Interface nicht deaktiviert ist (Advanced Features). Du könntest da auch versuchsweise explizit das VPN Gateway angeben.
- die Firewall-Regeln am VPN_Leg auch zutreffen, indem du das Logging aktivierst und es dann im Log überprüfst.
Habe ich gemacht >Firewall: Settings: Advanced > kein Haken drin
Keine Rules in OpenVPN
reply-to in den Rules von VPN_Leg stehen auf default
Aus dem Capture kann ich leider nicht erkennen wo es dann zum Problem kommt.
Quote from: fw115 on August 05, 2025, 03:15:56 PMWenn ich : tcpdump -i ovpnc1 -n auf der Firwall Shell mache, sehe ich das jede Menge Traffic auf ovpnc1 ankommt.
"Eine Menge" ist ein vager Ausdruck, der nicht hilft, den Fehler einzugrenzen. Es geht um die entsprechenden Verbindungen.
Die DMZ Hosts nutzen schließlich auch die VPN für ausgehenden Traffic. Das kann auch eine Menge sein.
Wenn ein Client von außen auf deinen Webserver auf Port 443 zugreift, dann antwortet der Server vom Port 443. Daran ist zu erkennen, ob das Antwort-Paket auch am VPN Interface raus geht. Darum geht es.
Auch könntest du ein Capture am WAN machen, um festzustellen, ob die Pakete da raus gehen.
Oder du kannst feststellen, ob die FW-Regeln überhaupt angewandt werden, wie auch schon vorgeschlagen.
Und es gab noch weitere Vorschläge. Schöpfe die mal aus.
Quote from: fw115 on August 05, 2025, 03:15:56 PMreply-to in den Rules von VPN_Leg stehen auf default
Hierzu hatte ich bspw. vorgeschlagen, das VPN Gateway da mal fix zu setzen. Etwa bei der Regel, die Zugriff auf Port 443 zulässt. Dann teste mal via HTTPS von außen.
Aber die Regel muss auch zutreffen, sonst bringt das auch nix. Daher musst du das erst überprüfen.
Hallo,
also irgendwie bin ich raus.(Edit: Im Sinne von: Keine Ahnung was ich noch machen soll)
Ich bin nicht in der Lage das richtig zu analysieren und den Fehler zu finden.
Grundsätzlich scheine ich ja in der richtigen Richtung unterwegs zu sein, mangels Wissen > Fail
Hier mal ein Capture auf WAN > VLAN132
QuoteNo. Time Source Destination Protocol Length Info
1 0.000000 82.XX.XX.XX 195.8.XX.2 ICMP 98 Echo (ping) request id=0x003a, seq=1/256, ttl=59 (no response found!)
2 1.002001 82.XX.XX.XX 195.8.xx.2 ICMP 98 Echo (ping) request id=0x003a, seq=2/512, ttl=59 (no response found!)
3 2.025953 82.XX.XX.XX 195.8.xx.2 ICMP 98 Echo (ping) request id=0x003a, seq=3/768, ttl=59 (no response found!)
4 10.708563 195.8.XX.XX 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003b, seq=1/256, ttl=64
5 11.753931 195.8.XX.2 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003b, seq=2/512, ttl=64
6 12.777972 195.8.XX.2 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003b, seq=3/768, ttl=64
7 21.047062 195.8.XX.2 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003c, seq=1/256, ttl=64
8 22.058254 195.8.XX.2 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003c, seq=2/512, ttl=64
9 23.082249 195.8.XX.2 82.XX.XX.XX ICMP 98 Echo (ping) reply id=0x003c, seq=3/768, ttl=64
Ich habe von extern 82.xx auf den internen Host hinter dem DMZ Interface gepingt. Also die 2. Nutzbare IP aus dem /29 Netz.
Das oben ist die Antwort.
Wenn ich ein tcpdump -n -i ovpnc1 icmp mache, ist das die Antwort:
Quotetcpdump -n -i ovpnc1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), snapshot length 262144 bytes
00:07:20.873096 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 1, length 64
00:07:22.944518 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 2, length 64
00:07:23.943687 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 3, length 64
00:07:25.097888 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 4, length 64
00:07:26.013077 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 5, length 64
00:07:27.051476 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 6, length 64
00:07:28.098145 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 7, length 64
00:07:29.122337 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 8, length 64
Meine Schlüsse daraus bisher:
Der VPN-Tunnel funktioniert
Der eingehende Verkehr ist korrekt
Keine Echo Replies sichtbar > der Antwortverkehr geht nicht über ovpnc1 zurück
Es kommt keine Antwort , egal was ich an Rules wo einstelle.
Ich habe keinen Plan was ich noch machen soll und wie.
Auch die feste Angabe in den Advanced Einstellungen der Rules hat keine Veränderung gebracht.
Eine feste Route hat auch nichts gebracht.
Ich habe mehr Fragen als ich mir selber Antworten geben kann.
Ich kann von dem Host hinter dem DMZ Interface nach außen pingen , kann auch www.heise.de pingen auf diesem host.
Warum aber, wenn ich von extern an diesen Host, dass Firewall Interface usw. pinge, keine Antwort zurück kommt, kann ich nicht
erklären bzw. das Problem finden.
Scheinbar findet die Route nicht zurück über mein Interface VPN_Leg und geht über das Default GW WAN, warum kann ich allerdings nicht sagen.
Auch nicht wie ich das ändern müsste.
Feste Route setzten hat nicht gebracht
explizites GW sezten hat nichts gebracht
Möglichweiser Fehler eingebaut, die ich nicht als solche erkenne.
Nehme ich den Haken raus bei "don't pull routes" setzt er das Default GW auf das VPN und aller Traffic geht über VPN. Logisch ping geht sofort.
Aber nicht wirklich das Ziel.
Irgendwo verbocke ich das mit dem Routing.
Etwas Ratlos.
Quote from: fw115 on August 05, 2025, 11:41:32 PMKeine Echo Replies sichtbar > der Antwortverkehr geht nicht über ovpnc1 zurück
Es kommt keine Antwort , egal was ich an Rules wo einstelle.
Ich habe keinen Plan was ich noch machen soll und wie.
Auch die feste Angabe in den Advanced Einstellungen der Rules hat keine Veränderung gebracht
Das die Echo Repliess nicht am VPN zu sehen sind, hatte ich erwartet. Die werden von der Floating Regel durchgelassen, und was für Floating Regeln gilt, siehe weiter oben.
Erwähnen möchte noch, dass Floating und Gruppen-Regeln Vorrang gegenüber Interface Regeln haben. Daher ist es notwendig, dass solche Regeln für den eingehenden Traffic nicht zutreffen.
Quote from: fw115 on August 05, 2025, 11:41:32 PMHier mal ein Capture auf WAN > VLAN132
Was ich hier aber nicht verstehe ist, warum da dieselben Echo Requests am WAN zu sehen sind. Die sollten doch zum VPN Provider geroutet werden.
Quote from: fw115 on August 06, 2025, 11:31:24 AMScheinbar findet die Route nicht zurück über mein Interface VPN_Leg und geht über das Default GW WAN, warum kann ich allerdings nicht sagen.
Auch nicht wie ich das ändern müsste.
Wie erwähnt, dafür dass die Antwortpakete zum richtigen Gateway zurück gehen, muss reply-to sorgen.
Alles was es meines Wissens diesbezüglich zu konfigurieren und zu überprüfen gilt, hatte ich bereits erwähnt. Ob du es auch gemacht hast, weiß ich nicht. In deine Rückmeldungen gehst du ja nicht auf alle Punkte ein.
Ich kann dir nur sagen, normalerweise funktioniert das so problemlos.
Hast du auch schon bei reply-to das VPN Gateway explizit gesetzt und dich überzeugt, dass die Regel überhaupt zutrifft.
Fragen, die ich schon mehrfach gestellt habe.
Ansonsten könnte vielleicht als allerletzter Ausweg eine Dirty Lösung funktionieren. Habe ich aber noch nie gemacht und daher keine Erfahrung:
In jeder einzelnen Policy-Routing Regel am VPN Interface den "State Type" auf "sloppy" setzen.
Hier gilt aber wieder, die Regel muss auch zutreffen und Floating und Interface-Gruppen (bspw. OpenVPN) Regeln haben Vorrang.
Quote from: viragomann on August 06, 2025, 02:35:33 PMWie erwähnt, dafür dass die Antwortpakete zum richtigen Gateway zurück gehen, muss reply-to sorgen.
Alles was es meines Wissens diesbezüglich zu konfigurieren und zu überprüfen gilt, hatte ich bereits erwähnt. Ob du es auch gemacht hast, weiß ich nicht. In deine Rückmeldungen gehst du ja nicht auf alle Punkte ein.
Ich kann dir nur sagen, normalerweise funktioniert das so problemlos.
Was keine böse Absicht ist. Ich habe einfach den Überblick verloren.
Ich habe gestern 6 Std. damit verbracht und gar keinen Plan mehr wo ich bin, was ich gemacht habe und ob das was ich gemacht habe richtig ist.
Zuviel Bastelei und das trotz der Hilfe.
Was müsste ich den Posten, damit ihr in der Lage seid zu prüfen, ob das was ich so eingestellt habe, so ist wie ihr das erwarten würdet ?
Oder einfach mal die config.xml der opnsense per PN an einen von euch (sofern Zeit und Nerv)?
Ich dreh mich einfach im Kreis.
Zum Stammtisch kommen und jemanden live drauf gucken lassen. Für eine extra Sitzung außerhalb des Freitagabends habe ich im Moment keine Zeit, sorry.
Quote from: Patrick M. Hausen on August 06, 2025, 03:17:27 PMZum Stammtisch kommen und jemanden live drauf gucken lassen. Für eine extra Sitzung außerhalb des Freitagabends habe ich im Moment keine Zeit, sorry.
Joa, dann werd ich mal am 22.08 vorbei schauen.