NAT in Verbindung mit OPNVPN-Client klappt nicht. Hilfe bitte!

[fdiskc2000]

Guten Abend zusammen,

meine opnsense baut per opn vpn client einen Tunnel nach aussen auf um eine feste ip von feste-ip.net zu bekommen. Das läuft soweit.
Nun möchte ich zunächst auf Port Basis eingehende Verbindungen verteilen, wie es bisher auch mit meinem Zugang per Fritzbox funktioniert hat.



Die untere Regel, welche sämtlichen Traffic an die IP 192.168.1.23 weiterleitet funktioniert auch.
Allerdings müsste nach meinem Verständnis die erste Regel vorher greifen, welche allen Traffic an Port 8001 auf einen anderen Host (Alias OLDMAN) dort an Port 5001 weiterleitet.

Ich sehe im Live View der FW auch, dass von meiner externen IP (DSL Anschluss) etwas über ovpnc1 und LAN an eben diese IP (OLDMAN:5001) erlaubt wird, ich bekomme aber im Browser keine Antwort von diesem Host.

Zusammengefasst:
- Eingang an opnsense über opnvpn-client mit externer IPv4 funktioniert.
- Weiterleiten des externen Ports 8001 an den internen Host auf Port 5001 nicht.

Sicherlich ein ziemlich simpler Fehler, allerdings wälze ich den schon 2 Abende und wäre für Hinweise sehr dankbar.
Ach ja, ich setze die aktuellste opnsense Version ein:
OPNsense 18.1.12-amd64
FreeBSD 11.1-RELEASE-p11
OpenSSL 1.0.2o 27 Mar 2018

Danke für Euren Support.

[JasMan]

Hey,

wenn Du in den Firewall Logs des LAN Interface erlaubten Traffic für den Verkehr OpenVPN:8001 -> OLDMAN:5001 siehst, muss die Regel ja funktionieren. Hast Du mal das Logging in der NAT Regel aktiviert um das sicherzustellen?

Sitzt OLDMAN im selben Subnetz wie die 192.168.1.23? Wenn ja würde das bedeuten, dass der Rückweg funktioniert da die 192.168.1.23 ja funktioniert. Wenn nein, würde ich mal den Rückweg prüfen.

Ist der Alias OLDMAN noch korrekt? Es gibt ein Problem in der aktuellen Version, dass wenn man den Alias nachträglich anpasst, die NAT Regeln das nicht sauber übernehmen. Ich glaub das ist aber nur wenn man den Alias Namen anpasst, nicht die Inhalte des Alias.

Was mir noch aufgefallen ist: die OLDMAN NAT Rule zeigt das Zeichen für eine "linked rule" (doppelter Pfeil), die 192.168.1.23 NAT Rule nur das normale Zeichen. Ich hab keine Ahnung wo genau der Unterschied da liegt, aber vielleicht hat es was damit zu tun.

Gruß
Jas

[fdiskc2000]

Hey Jas,

danke für Deine Antwort.
Wenn ich meine https://externe IP_VPN_Tunnel:8001 aufrufe

sehe ich im Liveview: OPVC1:meineexterneDSL-IP:UDPPORT (56900 o.ä.) -> IP_OLDMAN:5001 als "grün"

Der VPN Tunnel ist auf Prot UDP (vom Anbieter so im Profil ausgegeben) Was mich jetzt wundert: eingehend kommt da nicht port 8001, aber man liest das UPD das bessere Protokoll sei? Muss das trotzdem gehen?

OLDMAN ist im selben Subnet wie die andere IP: 192.168.1.23 -> 192.168.1.16

Habe sowohl Alias, als auch IP direkt versucht. Bei beiden das gleiche Ergebnis.

ich bin mir zwar nicht sicher wo der Unterschied zwischen der normalen und einer "linked rule" ist. Aber wenn ich beide auf NAT Rule setze geht nichts mehr.

Ich komme einfach nicht weiter mit dem Thema :-(

[JasMan]

Hey,

der Source Port 56900 ist ja der Client Port, also der Port mit dem der Client die Verbindung zu Dir aufbaut. Der ist für Dich irrelevant.
Das Du als Source Deine eigene, externe feste IP Adresse siehst und nicht die Quell-IP des eigentlichen Besuchers wird vermutlich daran liegen, dass der Anbieter die Pakete zu Dir weiterleitet. Oder versuchst Du vielleicht dich selbst über Deinen Anschluss zu erreichen? Dann könnte asynchrones Routing das Problem sein. Versuch in diesem Fall einfach mal über einen anderen Anschluss (z.B. Mobilfunk) die URL zu erreichen.

....
ich bin mir zwar nicht sicher wo der Unterschied zwischen der normalen und einer "linked rule" ist. Aber wenn ich beide auf NAT Rule setze geht nichts mehr.

Was meinst Du mit "beides auf NAT Rule setzen"?

Hast Du mal das Logging für die NAT Rule aktiviert um zu kontrollieren, ob der Traffic auch über die korrekte Regel abgearbeitet wird?

Jas

[fdiskc2000]

Hi,

also ich sehe schon die direkte IP des ausrufenden Systems. Ich gehe ja über meinen DSL-Anschluss raus zu einem externen VPN-Server und komme quasi über diesen Tunnel wieder zurück an die Opnsense. Die hat auch aktuell bei mir einen völlig eigenen und getrennten IP-Bereich.
Aber was soll ich sagen: das Problem scheint ein anderes zu sein. Das 2. Ziel war bei mir eine VM auf einem ESXi Server. Da scheint es im argen zu liegen.
Habe heute mal andere Dienste/Ports an BareMetal Installationen per NAT weitergegeben und das klappt nun. War also wohl vorher schon nicht ganz falsch
Warum es aber mit den VM´s (habe mittlerweile mehrere getestet) nicht klappt und mit anderen Systemen problemlos ist mir noch völlg unklar.

NAT-Logging: schlag mich nicht, aber ich finde ein Loging nur auf FW-Rule Basis. Aber für eine spezielle NAT-Regel geht das doch gar nicht, oder wo muss man da eingreifen?

So nächster Meilenstein:
warum geht NAT auf VM´s nicht und wie nutzt man den ollen HAProxy um URL basiert an verschiedene Hosts weiter zu leiten.

Danke Dir erstmal für Deine Unterstützung bis hier her :-)

[JasMan]

Uhhh, so langsam verliere ich echt den Überblick 

Du hast Recht, bei den Port-Forward-Rules gibt es kein Logging, zumindestens nicht auf der GUI. Ich war bei den Outbound Regeln.

Noch mal zur Source IP: welche Adresse siehst Du denn in den Firewall Logs als Source, wenn Du über Deinen DSLer mit der dynamischen IP den Server OLDMAN über die statische IP bei feste-ip.net erreichen willst? Die dynamische DSLer IP oder die statische IP von feste-ip.net?

Das es nur bei den VMs nicht funktioniert ist wirklich komisch. Aber wenn die selbe Regel bei BareMetal Systemen funktioniert kann es ja nur noch an der VM Umgebung liegen. Vorausgesetzt die BareMetal Systeme mit denen Du getestet hast hängen im selben Subnetz wie die VMs.
Aber außer dem üblichen Kram (Subnetmask oder Gateway Adresse bei den VMs falsch) fällt mir gerade auch nix ein. Können die VMs denn ins Internet pingen oder surfen? Nicht das die einfach keine Rückroute haben.

Zum HAProxy kann ich Dir leider nix erzählen, den habe ich auf der OPNsense noch nicht eingerichtet. Steht noch auf der ToDo Liste

[fdiskc2000]

Wenn keine NAT-Regel angelegt ist, sieht man:

DSL-IP -> VPN Tunnel Eingang (also die feste IP)

Mit NAT-Regel auf Host mit LAN-IP sieht man:

DSL-IP -> Ziel-IP im LAN

Komischerweise habe ich hier aktuell nur ein Netz in dem alle "Test"-Hosts unterwegs sind: 192.168.1.X, also Subnet etc. gleich. Gateway wäre noch eine Idee, sind meistens 2 drin, weil die Hosts auch noch in meinem "produktiven" Netz sind 192.168.178.X

Raus kommen die alle aktuell, evtl. auf dem falschen Gateway-Weg?

UPDATE: ja es waren die Gateways, war wohl zu simpel gedacht von mir. Einfach zu glauben, dass eingehend auch gleich ausgehend sein müsste.
Gateway Reihenfolge geändert und schon geht es. Bei den VM´s war es halt schön einfach eine zusätzliche NIC "einzubauen"

[JasMan]

Schön das es jetzt geht, aber sauber ist das glaub noch immer nicht.

Natürlich muss der eingehende Weg auch der ausgehende Weg sein. Den sonst sollte die Firewall die ausgehenden Pakete blocken weil er gar keine Session dazu kennt.

Und: wenn Du über Deinen DSLer rausgehst und somit die Source der Pakete die dynamische IP des DSLers ist, geht die Antwort zu diesen Pakten von z.B. OLDMAN ja auch an die dynamische IP Deines DSLers gehen. Sobald das Paket an Deiner OPNsense vorbei sagt die sich "Hey, das bin ich ja selbst", versucht es zu verarbeiten und da keine Session dazu existiert wird es verworfen. Ich denke das ist das eigentliches Problem. Und Du umgehst es jetzt nur, indem Du die Antworten einfach über ein anderes Gateway raus schickst.
Ist aber nur ne Vermutung. Dazu kenne ich den Aufbau nicht gut genug.