Messages

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.

Joa, dann werd ich mal am 22.08 vorbei schauen.

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.

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.

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.

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

No.    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:

tcpdump -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.

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.

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.

Ü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.

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:

2025-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:

tls-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

Hier 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.:

Wichtig:
- 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.

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?

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.

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.

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 :)

Hier die Rules:

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

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!

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?

Wenn route-no-pull nicht disabled ist, dann ja. Nehme ich route pull raus, vorbei mit ping.

Die 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

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.

Ja, 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.

Genau.

Hier nochmal meine Gateways als Screen Shot.
Warum steht das WAN mit  defunct (upstream) da drin ? Versteh ich nicht.