PF - Packet Filter: NAT-Loopback will nicht so recht

[Cédric]

Ich habe jetzt eine vereinfachte Firewall Regel erstellt und angewendet, um das ganze einfacher Debuggen zu können - normalerweise umfasst sie mein ganzes Netzwerk inkl. Subnetze und andere Interfaces... also:

Mit dem was ich hier habe, möchte ich ganz einfach nur ausgehende Pakete durchlassen, und deren zurückkommende "Antworten", mehr nicht... mit einer kleinen Besonderheit: NAT-Loopback: heisst, ich kann meine Public IP so einsetzen als wäre ich selber draussen...
Netzwerk:
Server (= Firewall - decemplex.net Extern): 127.0.0.1 (lo0), 192.168.0.1 (fxp0), 192.168.1.1 (rl0), 192.168.2.1 (ath0), x.x.x.x (tun0)
An tun0 hängt dann das Internet, an fxp0 den Rest des Netzwerkes, im moment...
Für diejenigen die PF nicht kennen, es wird eine Regel nach der anderen durchgegangen, bis zur letzten die passt - erst die wird genommen...

Problem: Raus kann ich, usw. - und das von jedem Host aus sowie vom Server (= Firewall) selber... aber: mache ich vom Server aus ein telnet decemplex.net, dann bekomme ich nichts, mache ich das gleiche von einem beliebigen Client aus, so hab ich mein Telnet erfolgreich... Folglich hab ich gedacht, meine NAT Regel dort unten ist falsch... Falsch gedacht, ob ich die Zeile benutze oder nicht, ändert irgendwie gar nichts am Problem... das heisst also: unabhängig der NAT Zeile unten, kann ich vom Server meine externe IP nicht benutzen, ausser zum anpingen... von anderen Hosts aus, klappt alles, nur dummerweise lässt man dort ein telnet decemplex.net zu das nicht zugelassen werden soll...

Ich schreib irgendwie wirrwarr, deswegen nochmal:

Mit vermeintlicher NAT Regel: Server kann nichts auf decemplex.net machen, nur ein Ping + erlaubtes - Clients können alles, auch nicht erlaubtes...
Ohne vermeintlicher NAT Regel: Server kann nichts auf decemplex.net machen, nur ein Ping + erlaubtes - Clients können alles, auch nicht erlaubtes...
=> Meine NAT Regel ist wohl auch nicht das wahre, trotz Empfehlung der Manpage... Hilfe :-|

# Loggt aufs externe Interface
set loginterface tun0

# NAT-Loopback auf's externe Interface
nat on tun0 inet from ! (tun0) to any -> (tun0)

# Blockt alles auf's externe Interface
block log on tun0

# Lässt alles auf's Loopback Interface zu
pass quick log on lo0 all

# Lässt alles auf's externe Raus + "Antworten"
pass out log on tun0 proto { tcp udp icmp } all flags S/SA keep state

# Öffnet den Port für den WebServer
pass in on tun0 proto tcp from any to any port www flags S/SA keep state

Habe auch mal mit tcpdump geguckt... ein telnet aus fxp0 zu tun0 kommt auf fxp0 rein, und das war's... und gelingt also auch...
Ein telnet vom Server nach tun0 wird auf tun0 einkommend geblockt, geht aber raus, also eigentlich korrekt...

Hoffe irgendwer kann mir helfen, und das man mich zu solcher Uhrzeit noch verstehen kann

 

[Cédric]

Anhang

---NAT am Server:

-Telnet to decemplex.net - NAT aktiv, Telnet nicht erlaubt: --> Bricht ab

000509 rule 2/0(match): pass out on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13450428 0>
000249 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13450428 0>
2. 964800 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13450728 0>
3. 200317 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13451048 0>
230078 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK>
3. 200398 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK>
3. 200373 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK>
874202 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK>
6. 270744 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK>

Logisch, NAT ist aktiv...


-Telnet to decemplex.net - NAT inaktiv, Telnet nicht erlaubt: --> Bricht ab

000489 rule 2/0(match): pass out on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13471890 0>
000422 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13471890 0>
2. 995725 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13472190 0>
3. 067075 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13472510 0>
3. 200348 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>
3. 200390 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>
2. 290284 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>
4. 384613 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>
670126 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>
4. 850601 rule 0/0(match): block in on tun0: IP 83.134.149.196.60309 > 83.134.149.196.23: S 2291999074:2291999074(0) win 65535 <mss 1452,nop,nop,sackOK>

Logisch, die Routing Tabelle wählt sich das Interface um rauszugehen...



--NAT am Client:

-Telnet to decemplex.net - NAT aktiv, Telnet nicht erlaubt: --> Geht durch

Nichts


-Telnet to decemplex.net - NAT inaktiv, Telnet nicht erlaubt: --> Geht durch

Nichts


Stand: die NAT Regel selber ist Okay - sie funktioniert schon, nur erschien es gestern komisch das ich bei ausgeschalteter NAT von den Clients noch ins Internet kam, warum weiss ich jetzt: das NAT von ppp war noch aktiv, wurde jetzt abgeschaltet - sodann funktioniert der Internetzugriff vom Client bei inaktiver NAT Regel nicht mehr, aber der Telnet zu decemplex.net funktioniert noch... und genau da happert es, sehr gut zu sehen wenn NAT aus ist (die Pakete sollen ja immerhin auf tun0 raus, und dann wieder rein, was man halt unter NAT Loopback versteht) - vllt. versteht man mein Problem so besser...

 

[I.MC]

Ist decemplex.net wirklich auf deine IP gemappt, oder ist das nur der Name deines Routers?
Dein Problem erkenn ich nicht ganz. Dich stört also, dass Clients, also nicht der Router selber noch einen telnet auf decemplex.net ausführen können obwohl NAT deaktiviert ist?

Gruß, I.MC

 

[Cédric]

Ist decemplex.net wirklich auf deine IP gemappt, oder ist das nur der Name deines Routers?
Dein Problem erkenn ich nicht ganz. Dich stört also, dass Clients, also nicht der Router selber noch einen telnet auf decemplex.net ausführen können obwohl NAT deaktiviert ist?

Gruß, I.MC

decemplex.net ist auf meine public IP gemappt...
Was mich stört, ist schlichtweg das ich von meinem internen Netz meinen Server nicht mehr über seine externe IP erreichen kann - zumindest nicht von den Clients aus, im Falle des Servers klappt das ja, siehe oben...
Das mit dem deaktivierten NAT war ein Beispiel dafür, das da was nicht stimmt

Das _scheint_, sowie ich das verstehe, jetzt zu passieren: ich mache einen Telnet von einem Client aus, nach decemplex.net - er schickt das ganze zum Router (= Firewall = Server ;-P), da er mit der Public IP so nichts anfangen kann. Gut, der Router erkennt die Ziel IP als eins seiner Interfaces und nimmt die Telnet Connection an - fertig... und für mich falsch...
Was ich will, ist das er die Verbindung auf tun0 rausleitet, und sie sozusagen wieder reinschickt (Loopback) - so wie das halt passiert wenn ich einen Telnet decemplex.net vom Server aus mache, mit aktiviertem NAT, ist ja oben im Log schön zu sehen... damit würde in meinem Versuchsfall hier das Telnet geblockt, und ich hätte Zugriff über die Public IP, von aussen aus...

Ich hoffe das hilft weiter

 

[I.MC]

Was mich stört, ist schlichtweg das ich von meinem internen Netz meinen Server nicht mehr über seine externe IP erreichen kann - zumindest nicht von den Clients aus, im Falle des Servers klappt das ja, siehe oben...

OK, wenn du also ein Telnet vom Router aus auf sich selber machst geht es fein, richtig?

Das _scheint_, sowie ich das verstehe, jetzt zu passieren: ich mache einen Telnet von einem Client aus, nach decemplex.net - er schickt das ganze zum Router (= Firewall = Server ;-P), da er mit der Public IP so nichts anfangen kann. Gut, der Router erkennt die Ziel IP als eins seiner Interfaces und nimmt die Telnet Connection an - fertig... und für mich falsch...

Wieso? Du willst doch, dass der Router (sag nicht immer Server :-) die Telnet Verbindung annimmt oder nicht?

Gruß, I.MC

 

[Cédric]

Wieso? Du willst doch, dass der Router (sag nicht immer Server :-) die Telnet Verbindung annimmt oder nicht?

Jep... soll er annehmen - aber die Verbindung soll auf dem externen Interface einkommend stattfinden - sprich ich kann dann decemplex.net aus dem gesamten LAN so nutzen als wäre ich irgendwo im Internet (mit den dort geltenden Zugriffsregeln - und nicht die die im LAN herrschen), ist manchmal ganz nützlich... konnte der alte Hardware Router problemlos so...

Hier sieht man es gut:

Das Paket geht raus, und kommt dann wieder rein, und wird abgeblockt :-)

000509 rule 2/0(match): pass out on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13450428 0>
000249 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 <mss 1452,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 13450428 0>

So soll's sein... nur klappt das zur Zeit nur vom Router selber aus, nicht von den Clients im LAN...

 

[I.MC]

---NAT am Server:

Was genau meinst du damit. Deine Ausführungen sind ein wenig unklar für mich.
Meinst du, dass du hier ein Telnet von einen Client im LAN auf die öffentliche IP des Routers (tun0) machst?

--NAT am Client:

Meinst du, dass hier vom Router selbst ein Connect auf sich selbst gemacht wird (auf tun0)?

Also ich hab mir das noch einmal durchgelesen. Problem: du kannst dich vom Router aus auf sich selbst verbinden (auf tun0), du kannst dich aber nicht von einem Client aus dem LAN auf den Router verbinden (tun0), richtig? Es geht also immer nur um die Telnet Verbindung zu dem Router von wo aus auch immer.

Gruß, I.MC

 

[Cédric]

Hm nein, nicht genau das...

Das möchte ich erreichen:

Die (NAT-)Loopback Funktion eines Routers wird dafür benötigt um Serverdienste in dem eigenen LAN und aus dem eigenen LAN heraus zu testen.
Der Verbindungsaufbau sieht also so aus das der Client mit seiner LAN-IP an den Router eine Anfrage an die bereits bestehende WAN-IP sendet. Diese Anfrage soll dann so interpretiert werden als wenn sie aus dem Internet käme und nicht aus dem LAN heraus.
Bsp.: Man hat zu Hause in seinem LAN einen Webserver eingerichtet der z.B. über den Port 80 angesprochen werden kann und möchte nun testen ob der Zugriff darauf aus dem Internet heraus funktioniert. Wenn man dafür nun die über den Router bereits bestehende Internetverbindung benutzt und der Router keine (NAT-)Loopback Funktion hat, interpretiert der Router dies nicht als eine Anfrage aus dem Internet heraus auf den Port 80, sondern als eine Anfrage aus dem LAN. Somit wird statt des Webservers der Port 80 des Router angesprochen und man landet meistens in der Webkonfiguration des Routers. Um die Funktion des Webservers zu testen muß also entweder der Router einer (NAT-)Loopback Funktion besitzen, oder man muß es von einem PC aus testen der keine Verbindung zu dem LAN bzw. dem Router hat.

Und ich muss das mit PF umsetzen... und es happert... wieso krieg ich das nicht erklärt

Vllt. mal ne andere Frage: ist das mit PF überhaupt möglich?! Wenn nein, gibt's da andere Software? Wenn man ja so nach NAT Loopback googelt, kommt ja soviel wie nichts... ausser für Hardware Router, aber kein Lösungsansatz für eigene Regeln für PF oder sonstiges... :-(

 

[I.MC]

http://openbsd.org/faq/pf/rdr.html

Dort steht erklärt, wie man die Regeln einrichten muß, damit diese Umleitungen / Portforwarding auch aus dem internen LAN funktionieren und nicht nur von extern.

Wieso du das nicht erklärt bekommen hast bis jetzt ist einfach, ich verstehe nicht was du vorhast. Denn was du gerade zitiert hast ist was anderes als das was du oben beschrieben hast. Bis jetzt war immer die Rede davon, dass du KEIN Portforwarding machen möchtest, sondern die immer nur von a) dem Router selbst auf sich selbst und b) von einem Client im LAN auf den Router verbinden wolltest. Von "umleiten" auf einem extra Server war nie die Rede, oder ich habe es echt überlesen.

Gruß, I.MC

EDIT: Sorry, der bsdforen.de Thread den ich hier gelinkt hatte nichts damit zu tun...

 

[Cédric]

Lösung

Hm, nein... es ist ja kein Portforwarding... also ich weiss beim besten Willen nicht wie ich es anders erklären soll - trotzdem danke für die Hilfe I.MC.
Ich hab einfach mal etwas auf "katastrophen Englisch" zusammengesetzt das das ganze hier zusammenfasst und an freebsd-pf@freebsd.org geschickt - das ganze ist hier zu lesen inklusive Lösung, falls das nochmal jemand braucht (ups... ne mail zuviel ): http://lists.freebsd.org/pipermail/freebsd-pf/2004-November/000555.html

Also in meinem Falle:

pass in on fxp0 route-to (tun0 (tun0)) from any to (tun0) keep state

und verallgemeinert:

pass in on $internal_if route-to ($external_if $external_ip) \
     from any to $external_ip keep state

Die eingehende Verbindungen auf's Interne Interface die als Dst IP die WAN IP besitzen werden damit auch effektiv zum externen Interface geroutet statt sofort am internen angenommen zu werden (da der TCP/IP Stack von PF scheinbar bei der eingehenden Verbindung checkt, ob die Dst IP einem Interface oder Aliase des Rechners entspricht, wenn ja wird dort sofort angenommen) => ich hab endlich meinen NAT Loopback ;-)