Hallo,
ich mal wieder.
Firewall nochmal Reset auf Werkszustand, restart from scratch.
Opnsense Version 25.7
LAN > 192.168.1.0/24
WAN > Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
DMZ > 192.168.100.0/24
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 geroutet werden soll
Ping ist auf allen Interfaces möglich:
LAN <> DMZ geht
ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=247 time=30.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=247 time=29.9 ms
^C
LAN <> WAN mit DNS geht
ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=247 time=30.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=247 time=29.9 ms
^C
So. Jetzt OpenVPN:
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
Der Tunnel steht. Sehe das VPN auf dem Dashboard unter Interfaces mit der IP Adresse vom Provider.
Wie ist jetzt der Weg um:
1) die IP Adressen aus dem /29 Netz an Hosts in der DMZ zuzuweisen ?
2) was/wie sind die richtigen NAT Regeln und Rules damit der Traffic vom Internet über den Tunnel und dem /29 an die Hosts in der DMZ gehen und wieder zurück ?
Wenn was nicht klar genug sein sollte, bitte Hinweis.
Aber ich dreh mich gerade im Kreis.
Danke
Wo liegt denn dieses /29 an?
Das wird über das VPN an die Interface Adresse 231.240.xx.xx/32 groutet.
Müsste ich nicht jetzt ohne das es eine entsprechende config gibt die 231.240.xx.xx/32 extern pingen können ?
Also du hast einen Account bei deinem VPN-Provider und kannst den Tunnel herstellen. Und der Provider routet zusätzlich ein /29 in den Tunnel? Hab ich das richtig?
Damit du 231.240.xx.xx/32 aus dem Internet anpingen kannst, musst du natürlich auf dem VPN-Interface eingehend eine Firewall-Regel haben, die das erlaubt. Oder eine Floating Regel, die global ICMP echo auf allen Interfaces erlaubt, das habe ich. Ich halte "ping" für zwingend notwendig und glaube nicht an "ICMP sperren".
Nun nehmen wir mal an, das /29 wäre 195.8.xx.0/29 - dann würde ich dem DMZ-Interface der OPNsense 195.8.xx.1/29 zuweisen. Dann kannst du 5 Server oder VMs an dieses DMZ-Interface anschließen mit 195.8.xx.2-6/29. Firewall-Regeln nach Bedarf, kein NAT.
Gruß
Patrick
Quote from: fw115 on July 23, 2025, 07:13:36 PMDas wird über das VPN an die Interface Adresse 231.240.xx.xx/32 groutet.
Müsste ich nicht jetzt ohne das es eine entsprechende config gibt die 231.240.xx.xx/32 extern pingen können ?
Nein. Dazu müsste die gepingte IP auf deiner Seite einem Gerät zugewiesen werden, das der eventuell weitergeleitete oder geroutete Ping Request erreicht.
Aber sehen könntest du die Pakete am VPN Interface mit Packet Capture.
Aber das ist für deinen Zweck ja nicht nötig. Du kannst die Web-Anfragen einfach mittels NAT Regeln weiterleiten.
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.
Dann kannst du einfach für jede IP eine NAT Port Forward Regel am VPN client Interface erstellen. Bspw.
Ziel: 195.8.xx.4, Port: 443
Weiterleitung: 192.168.100.16, Port: 443
Jeweils mit "Add associated Filter rule". Das sollte am Client Interface die Firewall Regeln erstellen.
Du könntest auch mit nur einer NAT One-to-One Regel das gesamte /29 Subnetz weiterleiten, wenn die Webserver IPs durchgehend und in der gewünschten Reihenfolge vorliegen.
Aber dann müsstest du die Filter Regeln am VPN Client Interface manuell erstellen.
Grüße
Danke für die Tipps.
Die Interfaces machen mich fertig. Ich hab das da noch icht ganz im Griff.
Also ...
Ich habe 2 VPN "Interfaces"
opvpnc1> OpenVPN zugewiesen an opt3> VPN ( das was ich definiert habe)
Wenn ich das recht verstanden habe, sollte das VPN Interface somit richtig zugewiesen sein. Richtig ?
Das Interface ist UP mit der 231.xx.xx.xx/32
Damit sollte also vie Vorraussetzung da sein, per NAT
195.8.xx.2/29 an 192.168.100.10 zu "natten" mit Port xyz
Das heisst die Rules müssen dann in VPN erfolgen, was von mir definiert wurde.
In OpenVPN sind nur automatic rules drin.
OpenVPN ist eine Interface-Gruppe, die alle Interfaces enthält, die du anlegst.
Warum willst du unbedingt eingehend NATen? Weise das /29 der DMZ zu wie von mir beschrieben. Wenn der Provider das in Richtung deiner OPNsense routet, ist das doch optimal so.
Quote from: Patrick M. Hausen on July 23, 2025, 08:49:38 PMOpenVPN ist eine Interface-Gruppe, die alle Interfaces enthält, die du anlegst.
Quote from: fw115 on July 23, 2025, 08:47:07 PMIn OpenVPN sind nur automatic rules drin.
Und daher müssen Pass Regeln, die zutreffen würden, von da weg oder so geändert werden, dass sie nicht zutreffen. Das gilt auch für automatisch generierte Regeln.
Edit:Ich möchte noch der Vollständigkeit halber hinzufügen, dass die Sache mit den Regeln am richtigen Interface nur für den Fall gilt, dass der VPN-Provider nicht dein Standardgateway ist, also nicht dein gesamter ausgehender Traffic über diese VPN läuft.
Aber das hatte ich aufgrund deiner Schilderung so angenommen.
Quote from: Patrick M. Hausen on July 23, 2025, 08:49:38 PMOpenVPN ist eine Interface-Gruppe, die alle Interfaces enthält, die du anlegst.
Warum willst du unbedingt eingehend NATen? Weise das /29 der DMZ zu wie von mir beschrieben. Wenn der Provider das in Richtung deiner OPNsense routet, ist das doch optimal so.
Enschuldige das ich so dumm nachfrage, aber ich habe zuviel rumgebastelt, dass ich mir selber nicht mehr traue.
Ich würde das /29 gerne an die DMZ zuweisen, da es sich für mich nach einer einfacheren Struktur der Verwaltung anhört.
Fragen dazu:
Wie weise ich das Netz korrekt zu ?
Wie sieht das mit den Rules und evt Port Zuweisungen für das /29 aus ?
Was ist mit dem Routing ? Macht die Opnsense das "on the fly" mit dem Zuweisen des /29 an die DMZ ?
VG
Torsten
Quote from: fw115 on July 23, 2025, 10:26:38 PMIch würde das /29 gerne an die DMZ zuweisen
Du meinst, an die einzelnen Server? Du möchtest also das /29 Netz intern betreiben.
Tatsächlich?
Das wird wohl etwas kompliziert.
Quote from: viragomann on July 23, 2025, 10:29:40 PMQuote from: fw115 on July 23, 2025, 10:26:38 PMIch würde das /29 gerne an die DMZ zuweisen
Du meinst, an die einzelnen Server? Du möchtest also das /29 Netz intern betreiben.
Tatsächlich?
Das wird wohl etwas kompliziert.
Nein, das ist viel einfacher als der Port-Forwarding Mist.
Aber sorry - Details morgen.
So, @fw115 - lass uns doch erstmal gucken, ob wenn der Tunnel aufgebaut ist, die eine /32 IP-Adresse auch tatsächlich aus dem Internet erreichbar ist.
Also Tunnel aufbauen klappt, ja? Dann leg doch mal diese Floating-Regel an wie in meinem Screen Shot. Die erlaubt, alles im Netz anzupingen und ist daher m.E. nicht irgendwie kritisch. Sie erlaubt auch nur "ping", sonst nichts mit ICMP. Bei "Interfaces" nichts auswählen, dann gilt sie global.
Und dann machst du mal aus dem Internet über irgendeine andere Verbindung ein "ping" auf die /32 Adresse. Das muss klappen. Wenn nicht, brauchen wir gar nicht erst weiter zu machen.
Grüße
Patrick
Moin,
joa mxtoolbox /32 versucht anzupingen. Nix.
Die Aussage vom Provider, liegt an mir, die können alles pingen.
Ganz toll.
Hast du die Floating Regel eingerichtet? Ohne eine ausdrückliche Regel kann es nicht funktionieren.
Quote from: Patrick M. Hausen on July 25, 2025, 10:08:38 AMHast du die Floating Regel eingerichtet? Ohne eine ausdrückliche Regel kann es nicht funktionieren.
Ja, hab ich. Leider ohne Erfolg.
Mach während eines kontinuierlichen Pings mal ein tcpdump auf dem OpenVPN-Interface der OPNsense.
tcpdump -i ovpnc1 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), snapshot length 262144 bytes
10:44:02.750760 IP [version 15 != 4] (invalid)
10:44:03.563562 IP [version 15 != 4] (invalid)
10:44:03.593065 IP 192.168.100.153.57620 > 199.7.91.13.53: 8251 [1au] NS? . (40)
10:44:03.593541 IP 192.168.100.153.47557 > 199.7.91.13.53: 59675 [1au] NS? cz. (43)
10:44:04.369931 IP [version 15 != 4] (invalid)
10:44:04.394346 IP 192.168.100.153.58344 > 192.58.128.30.53: 39946 [1au] NS? . (40)
10:44:04.587503 IP 192.168.100.153.53202 > 192.58.128.30.53: 12067 [1au] NS? cz. (43)
10:44:05.195718 IP [version 15 != 4] (invalid)
10:44:05.195878 IP 192.168.100.153.36201 > 198.41.0.4.53: 45679 [1au] NS? . (40)
10:44:05.611699 IP 192.168.100.153.56885 > 198.41.0.4.53: 12277 [1au] NS? cz. (43)
10:44:05.736549 IP [version 15 != 4] (invalid)
10:44:05.995999 IP 192.168.100.153.42768 > 202.12.27.33.53: 54126 [1au] NS? . (40)
10:44:06.091377 IP 192.168.100.153.56372 > 202.12.27.33.53: 1153 [1au] NS? cz. (43)
10:44:06.139168 IP [version 15 != 4] (invalid)
10:44:06.287814 IP [version 15 != 4] (invalid)
10:44:06.635397 IP [version 15 != 4] (invalid)
10:44:06.797299 IP 192.168.100.153.39366 > 170.247.170.2.53: 22501 [1au] NS? . (40)
10:44:06.798418 IP 192.168.100.153.36959 > 170.247.170.2.53: 28207 [1au] NS? cz. (43)
10:44:07.598910 IP 192.168.100.153.59108 > 198.97.190.53.53: 42831 [1au] NS? . (40)
10:44:07.599742 IP 192.168.100.153.38434 > 198.97.190.53.53: 8890 [1au] NS? cz. (43)
10:44:07.659824 IP [version 15 != 4] (invalid)
22 packets captured
22 packets received by filter
0 packets dropped by kernel
OK, das sieht nach einem VPN Problem aus. Verschlüsselung ? Cert ? Da keine Ahnung von VPN und das Probelme natürlich nicht
nur von meiner config aus passieren können.
10:44:06.139168 IP [version 15 != 4] (invalid)
10:44:06.287814 IP [version 15 != 4] (invalid)
10:44:06.635397 IP [version 15 != 4] (invalid)
Im Moment keine Ahnung wie ich das lösen könnte.
Ohne eine Einsicht in deine VPN Konfiguration tappen wir da wohl auch im Dunkeln.
Aus dem Backup der OPNsense extrahiert:
# OpenVPN Client-Konfiguration: X_VPN
client
dev tun
proto tcp
remote vpn3.xxx.de 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verb 3
topology subnet
# Zertifikat & Schlüssel
ca [Pfad zur CA-Datei: z. B. /conf/ca/xxxxxxxxx.pem]
cert [Pfad zum Client-Zertifikat: z. B. /conf/cert/xxxxx.pem]
key [Pfad zum privaten Schlüssel des Client-Zertifikats]
Das ist die Konfig, die du vom Provider erhalten hast. Die kennen wir schon und ich gehe davon aus, dass es damit auch funktionieren sollte.
Nun wäre aber interessant, was du daraus gemacht hast, denn das macht offenbar Probleme.
Ein direkte Konfig-Import Möglichkeit ist mir ja nicht bekannt. Und wenn, wäre auch interessant, wie das nun in OPNsense aussieht.
Quote from: viragomann on July 25, 2025, 01:15:33 PMDas ist die Konfig, die du vom Provider erhalten hast. Die kennen wir schon und ich gehe davon aus, dass es damit auch funktionieren sollte.
Nun wäre aber interessant, was du daraus gemacht hast, denn das macht offenbar Probleme.
Ein direkte Konfig-Import Möglichkeit ist mir ja nicht bekannt. Und wenn, wäre auch interessant, wie das nun in OPNsense aussieht.
<OPNsense>
<OpenVPN version="1.0.1"persisted_at="1753436035.20">
<Instances>
<Instance uuid="xxxxxxxxx">
<vpnid>1</vpnid>
<enabled>1</enabled>
<dev_type>tun</dev_type>
<verb>3</verb>
<proto>tcp4</proto>
<port>1194</port>
<topology>subnet</topology>
<remote>vpn3.xxx.de</remote>
<role>client</role>
<cert>xxxxxxxxxxxx</cert>
<ca>xxxxxxxxxxxxx</ca>
<verify_client_cert>require</verify_client_cert>
<remote_cert_tls>0</remote_cert_tls>
<description>X_VPN</description>
<mssfix>0</mssfix>
<username_as_common_name>0</username_as_common_name>
<strictusercn>0</strictusercn>
<provision_exclusive>0</provision_exclusive>
<register_dns>0</register_dns>
<compress_migrate>0</compress_migrate>
<ifconfig-pool-persist>0</ifconfig-pool-persist>
</Instance>
</Instances>
<StaticKeys/>
</OpenVPN>
</OPNsense>
<interfaces>
<opt3>
<if>ovpnc1</if>
<descr>X_VPN</descr>
<enable>1</enable>
<lock>1</lock>
<spoofmac/>
</opt3>
</interfaces>
Mir fällt da nicht Verdächtiges auf, das ich mit dem Fehler in Zusammenhang bringen würde.
Eine falsche Compression Einstellung könnte ich mir am ehesten denken. Und dazu habe ich nochmals oben nachgesehen in deinem ersten Post. Das enthält doch zusätzlich
cipher BF-CBC
comp-lzo
Warum hast du das dann weggelassen? Hast du eine neue Konfig vom Provider erhalten?
Quote from: viragomann on July 25, 2025, 02:22:00 PMMir fällt da nicht Verdächtiges auf, das ich mit dem Fehler in Zusammenhang bringen würde.
Eine falsche Compression Einstellung könnte ich mir am ehesten denken. Und dazu habe ich nochmals oben nachgesehen in deinem ersten Post. Das enthält doch zusätzlich
cipher BF-CBC
comp-lzo
Warum hast du das dann weggelassen? Hast du eine neue Konfig vom Provider erhalten?
Nein, würde ich gerne setzen, kann ich aber nicht unter instances in der 25.7:
cipher BF-CBC
comp-lzo (ist dazu depricated)
und ich weiss nicht, ob ich das einfach so von Hand in die VPN config eintragen kann, ohne das es Probleme erzeugt.
Ich glaube die 25.7 hat diese Option sowieso nicht mehr.
Quote from: fw115 on July 25, 2025, 02:48:53 PMNein, würde ich gerne setzen, kann ich aber nicht unter instances in der 25.7:
Beide Einstellungen sind veraltet, sollten aber noch unterstützt werden. Jedoch kann man in in der OPNsense Instanz nicht mehr konfigurieren.
Du solltest deinen Provider ersuchen, sein OpenVPN upzudaten und neue Konfigurationen auszugeben.
Wenn du das in 25.7 einrichten möchtest, benötigst meines Wissens das Lecacy Plugin.
Da sollte beides auswählbar sein.
Antwort vom Provider:
nach Prüfung durch unsere Technik kann ich Folgendes mitteilen:
Der betroffene Host erhält konstant eingehenden Traffic in Form von TCP-SYN-Paketen. Allerdings erfolgt darauf keinerlei Antwort, weder durch TCP-RST noch über ICMP, es wird schlichtweg nicht reagiert.
Ich weiß jetzt nicht, ob der Techniker auf der Remoteseite überhaupt sehen könnte, dass dein Client ein Problem hat.
Eventuell könntest du aber auf deiner Seite Hinweise in den Logs finden.
Aber solange du keine kompatiblen VPN Client hast, sehe ich weiteres Troubleshooting für Zeitverschwendung.
So jetzt plugin installiert und ganz andere Probleme:
Wenn ich jetzt die config speichern will :
QuoteAn IPv4 protocol was selected but the selected interface has no ipV4 address
Gehe ich ins Interface und will die IP Adresse festlegen:
QuoteCannot assign an IP Address to a tunnel interface
OK, wie dann?
Unter Interface hast du WAN ausgewählt?
irgendwas war hier nicht richtig ... kann weg
Danke für den Stupser!
Quoteping 213.xx.xx.xx
PING 213.xx.xx.xx (213.240.152.150) 56(84) bytes of data.
64 bytes from 213.xx.xx.xx: icmp_seq=1 ttl=60 time=98.4 ms
64 bytes from 213.xx.xx.xx: icmp_seq=2 ttl=60 time=54.8 ms
64 bytes from 213.xx.xx.xx: icmp_seq=3 ttl=60 time=127 ms
Ich weine ein kleines bischen :)
Wie weise ich denn jetzt die Netze korrekt zu ?
Quote from: Patrick M. Hausen on July 23, 2025, 08:49:38 PMOpenVPN ist eine Interface-Gruppe, die alle Interfaces enthält, die du anlegst.
Warum willst du unbedingt eingehend NATen? Weise das /29 der DMZ zu wie von mir beschrieben. Wenn der Provider das in Richtung deiner OPNsense routet, ist das doch optimal so.
So wie zuvor auch.
Wenn du das von der Instanz noch hast, brauchst du nur auf Interfaces: Assignments gehen und da den Legecy Client als Device auswählen und speichern.
Quote from: viragomann on July 25, 2025, 05:34:47 PMSo wie zuvor auch.
Wenn du das von der Instanz noch hast, brauchst du nur auf Interfaces: Assignments gehen und da den Legecy Client als Device auswählen und speichern.
Wollte Patrick mir noch richtig erklären. Hat er noch nicht, da Ping nicht ging und er sagte macht vorher keinen Sinn.
Unten findest du "Assign a new interface". Da bei Device die OpenVPN client instance auswählen, bspw. "ovpnc2", einen Test in das Description Feld schreiben und auf Add klicken.
Eventuell muss du noch das neue Interface öffnen und es aktivieren. Möglw. geschieht das automatisch, weiß ich jetzt nicht.
Quote from: viragomann on July 25, 2025, 05:34:47 PMSo wie zuvor auch.
Wenn du das von der Instanz noch hast, brauchst du nur auf Interfaces: Assignments gehen und da den Legecy Client als Device auswählen und speichern.
Ich habe in der Instanz noch nichts eingerichtet gehabt.
Du konfigurierst das Interface deiner DMZ statisch mit einer Adresse aus dem /29. Das ist dann der Gateway für deine Server im selben /29.
Ping sollte dann sofort gehen mit der Floating Regel.
NAT musst du auf manuell stellen und für das LAN-Netz eine Outbound Regel auf dem WAN anlegen.
Die DMZ kriegt kein NAT.
Dann eingehende Firewall-Regeln, 80, 443, ... nach Bedarf.
Quote from: Patrick M. Hausen on July 25, 2025, 08:30:53 PMDu konfigurierst das Interface deiner DMZ statisch mit einer Adresse aus dem /29. Das ist dann der Gateway für deine Server im selben /29.
Ping sollte dann sofort gehen mit der Floating Regel.
NAT musst du auf manuell stellen und für das LAN-Netz eine Outbound Regel auf dem WAN anlegen.
Die DMZ kriegt kein NAT.
Dann eingehende Firewall-Regeln, 80, 443, ... nach Bedarf.
Das versuche ich morgen mal.
Geht Hybrid auch oder muss das manuell sein ?
Kann ich auch weitere /29 so in die DMZ bringen?
Muss manuell sein, sonst macht sie für die DMZ automatisch NAT und das will man ja nicht.
Outbound NAT im Hybrid Mode und eine Regel für die DMZ mit "no NAT" sollte es auch tun.
So braucht es nicht noch Regeln für andere Subnetze.
Und die Regel wohl am VPN Interface, und den ausgehenden Traffic mit einer Policy-Routing Regel da raus schicken wenn der VPN Server nicht das Standardgateway ist.
Das WAN GW möchte eventuell diese IPs nicht sehen.
Quote from: viragomann on July 26, 2025, 08:58:59 AMOutbound NAT im Hybrid Mode und eine Regel für die DMZ mit "no NAT" sollte es auch tun.
So braucht es nicht noch Regeln für andere Subnetze.
Und die Regel wohl am VPN Interface, und den ausgehenden Traffic mit einer Policy-Routing Regel da raus schicken wenn der VPN Server nicht das Standardgateway ist.
Das WAN GW möchte eventuell diese IPs nicht sehen.
Wärst du so nett und gibts mit ein reales Beispiel? Ich habe über 10 Jahre mit einer anderen Firewall gearbeitet und habe es doch etwas schwer mit dem Umstieg auf Opnsense. Die Verteilung in den ganzen Untermenüs ist für mich echt ein Problem.
Sagen wir eine Regel für eingehend und ausgehend:
195.1.2.3/29 eingehend über WAN / Vlan 132 in die DMZ auf 192.168.100.10
und ausgehend von der DMZ über das VPN .
WAN mit VLAN 132 ist das default GW.
Ich wäre echt dankbar dafür!
Quote from: fw115 on July 26, 2025, 11:57:25 AM195.1.2.3/29 eingehend über WAN / Vlan 132
Ist das nun dein WAN Subnetz?
Zuvor hattest du diese Angaben gemacht:
Quote from: fw115 on July 23, 2025, 03:14:52 PMWAN > Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
DMZ > 192.168.100.0/24
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 geroutet werden soll
So wie ich es verstanden hatte, war das Ziel, das 195.8.xx.xx/29 den Webservern in der DMZ zuzuweisen.
Am WAN wären keine eingehender Traffic, nur über VPN.
Aus dem LAN ausgehender Traffic sollte normal über WAN raus gehen.
Ist das so noch richtig?
Hast du dem DMZ Interface und den Servern die IPs aus 195.8.xx.xx/29 zugewiesen?
Und wenn ja, kommen die Pings schon an und werden beantwortet?
Quote from: viragomann on July 26, 2025, 02:31:06 PMQuote from: fw115 on July 26, 2025, 11:57:25 AM195.1.2.3/29 eingehend über WAN / Vlan 132
Ist das nun dein WAN Subnetz?
Zuvor hattest du diese Angaben gemacht:
Quote from: fw115 on July 23, 2025, 03:14:52 PMWAN > Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
DMZ > 192.168.100.0/24
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 geroutet werden soll
So wie ich es verstanden hatte, war das Ziel, das 195.8.xx.xx/29 den Webservern in der DMZ zuzuweisen.
Am WAN wären keine eingehender Traffic, nur über VPN.
Aus dem LAN ausgehender Traffic sollte normal über WAN raus gehen.
Ist das so noch richtig?
Hast du dem DMZ Interface und den Servern die IPs aus 195.8.xx.xx/29 zugewiesen?
Und wenn ja, kommen die Pings schon an und werden beantwortet?
Fast.
Sorry fals ich das unklar ausgedrückt habe.
Quotewar das Ziel, das 195.8.xx.xx/29 den Webservern in der DMZ zuzuweisen
Genau.
Plus 2 historische Netze /29 die noch dazukommen, soweit das mit dem 195.x/29 funktioniert und erstmal grundlegend konfiguriert ist.
Aber:
Alles von LAN, eingehend wie ausgehend, soll über WAN/VLAN 132
LAN soll ebenfalls die DMZ erreichen können, eingehen wie ausgehend
Alles was in der DMZ ist (öffentliche IPs) , soll nur über VPN rein und raus.
WAN hätte meiner Ansicht nach dann Traffic weil das VPN ja letztendlich über das WAN rein und raus geht.
Wie gesagt :
Über WAN mit dem draufgelegten VLAN 132, muss aller Traffic rein und raus, das das der Hauptanschluss mit Default GW ist über den auch das VPN laufen muss.
Hier nochmal als schnelle Übersicht:
QuoteLAN > 192.168.1.0/24
WAN > Vlan 132 32.xx.xx./24 mit 1 Nutzbaren festen IP
DMZ > 192.168.100.0/24
OpenVPN > 213.240.xx.xx./32 auf das ein 195.8.xx.xx/29 geroutet werden soll
Wenn ich das nun richtig sehe, fällt das DMZ > 192.168.100.0/24 weg und an dessen stelle tritt dann das 195.x.x./29
Da ich vorher immer genattet habe , bin ich vollkommen unsicher wie hier die config zu sein hat.
Kämen die anderen Netze dann als Virtuelle IP auf dieses Interface ?
Quote from: fw115 on July 26, 2025, 02:47:52 PMWenn ich das nun richtig sehe, fällt das DMZ > 192.168.100.0/24 weg und an dessen stelle tritt dann das 195.x.x./29
Ja.
Quote from: fw115 on July 26, 2025, 02:47:52 PMDa ich vorher immer genattet habe , bin ich vollkommen unsicher wie hier die config zu sein hat.
Routen tut OPNsense automatisch.
Also wenn auf irgendeinem Interface ein Paket für 195.8.xx.xx/29 ankommt, wird es auf das jeweilige Zielgerät weitergeleitet. Voraussetzung ist nur, dass die IP in der DMZ existiert und dass es eine Firewall Regel erlaubt.
Quote from: fw115 on July 26, 2025, 02:47:52 PMKämen die anderen Netze dann als Virtuelle IP auf dieses Interface ?
Würde ich natten. Aber ich hätte auch das 195.8.xx.xx/29 genattet. Was daran schlecht ist, hat mir noch keiner erklärt.
Verstehe ich das richtig, dieses andere /29 soll auf dieselben DMZ Geräte geleitet werden?
Du hast noch nicht verraten, ob das 195.8.xx.xx/29 schon funktioniert.
Begrenzen wir erst das Setep auf die DMZ mit 195.8.xx.xx/29.
OPT1 heißt den VPN Interface, soweit ich mich erinnere.
Outbound NAT Regel:
Firewall: NAT: Outbound"Hybrid outbound NAT rule generation" aktivieren und das mal sichern.
Mit "+" darunter eine Regel hinzufügen:
"Do not NAT" anhaken
Interface: OPT1
Source address: DMZ net
Restlichen Werte auf default belassen. Wichtig dabei
Destination: any
Das bedeuten alles, was am OPT1 (VPN) raus geht und vom DMZ Subnetz kommt, soll nicht genattet werden (Quell IP). Die IPs werden also beibehalten.
Ausgehender Traffic von der DMZ:
Hier wieder eine Annahme von mir: Das VPN Gateway ist nicht das Standardgateway, sondern das WAN GW.
Annahme auch, aller ausgehender Traffic von der DMZ wird erlaubt.
Damit die Pakete nicht zum WAN GW gehen, musst du sie per Policy-routing aus VPN GW schicken. Das macht eine normale Firewall-Regel, in der man das Gateway angibt.
Um Public und private IPv4 zu differenzieren, empfiehlt es sich, für die privaten Ranges einen Alias anzulegen. Ich nenne diesen treffend RFC1918.
Firewall: AliasesMit "+" einen neuen Alias erstellen:
Name: RFC1918
Type: Networks
Content: 10.0.0.0/8 172.16.12.0/12 192.168.0.0/24
Save
Also eine Regel anlegen:
Firewall: Rules: DMZMit "+" eine Regel anlegen:
Action: Pass
Protocol: any
Source: DMZ net
"Destination / Invert" anhaken
Destination: RFC1918
Gateway: OPT1 GW
Der Haken bei "Destination / Invert" kehrt den Wert um, so dass diese Regel für alles andere als dem RFC1918 Alias gilt.
Diese Regel sollte ganz oben positioniert sein.
Wenn du aus der DMZ auch Zugriff auf lokale Resourcen brauchst, bspw. dem DNS Resolver auf der OPNsense, musst du dafür weitere Regeln anlegen.
Hallo,
ich kann Erfolge melden.
Das Firewall DMZ Interface hat die erste IP vom /29 Netz zugewiesen bekommen und kann nun
von außen angepingt werden.
Die config ist zwar vollkommen anders als ich das von der anderen Firewall her gewohnt bin, aber ich arbeite daran.
Vielen vielen Dank für die Hilfe dafür an Patrick und Viragoman, dass dieser Abschnitt nun funktioniert.
Nun geht es mit der config weiter und eine Menge neuer Fragen sind bereits aufgekommen.