Ich habe es fast
-
Nein, das ist nötig, aber eine Outbound Regel für WAN müsste automatisch eingerichtet werden.
Wenn das Outbound auf "Automatic rule generation" steht, solltest du eine WAN-Regel für 192.168.11.0/24, also dein LAN auf die Interface Adresse gestetzt haben.Ich kenne nur das Problem von einer früheren Version, dass wenn man die Interface-Konfig ändert, also dein LAN-Netz, das Outbound NAT nicht automatisch nachgezogen wird.
-
Hallo viraomann,
vielen Dank für deine schnelle Antwort.
Die automatischen Regeln sind bei mir leer.
Ich habe heute pfSense auf Werkseinstellungen zurückgesetzt.
Könnte das daran liegen?Sind diese wichtig, bzw. wie kann ich pfSense diese erstellen lassen?
Meine Einstellung war auf automatisch.
Da diese leer sind, habe ich nun den Hybrid Modus aktiviert.Markus
-
Ja, die Regeln brauchst du und die tun auch nichts Böses.
Diese NAT-Regel transferiert einfach die Quell-IP (bspw. die deines LAN-Hosts) auf die WAN-IP, wenn ein Paket die pfSense auf der WAN-Schnittstelle verlässt. Das ist hier nötig, denn ansonsten kommt das Paket mit einer 192.168.11.xxx Quell-IP auf 10.112.116.220 an. Dieser schickt seinen Respons dann auch dahin zurück. Der Kunden-Router kennt aber die IP 192.168.11.xxx nicht und leitet es an sein Default-GW, also die FB, weiter.So weit ich weiß, werden die Outbound-NAT Regel für WAN automatisch generiert, wenn man auf "Automatic rule generation" stellt und save klickt.
Aber nachdem du nur ein LAN-Netz hast, würde dir ohnehin nur diese eine Regel erstellt. -
Die Regeln bleiben bei mir leer, auch wenn ich zwischen automatisch und manuell hin- und herschalte.
Jetzt habe ich noch ein letztes Problem:
An der pfSense nutze ich eine 3. Schnittstelle wie folgt:
LAN 192.168.11.0/24 –---- (192.168.11.110 pfSense 10.49.0.84/28 ) ------ Kundennetz
+ |
virtuell 192.168.1.5/24 |
10.49.0.81
|
|
192.168.2.1 Router Kunde --------VPN------10.49.0.181Von der pfSense aus kann ich sowohl die 10.49.0.81, als auch die 10.49.181 pingen und tracen.
Von meinen Clients aus meinem LAN erreiche ich nur die 10.49.0.81.
Die 10.49.0.181 erreiche ich nicht.
Ist das wieder ein NAT Problem?
Hier meien Routen:
Destination Gateway Flags Use Mtu Netif Expire default 192.168.33.1 UGS 382284 1500 em1 10.49.0.0/24 192.168.1.2 UGS 431 1500 em2 10.49.0.80/28 link#3 U 122 1500 em2 10.49.0.84 link#3 UHS 0 16384 lo0 10.112.116.0/24 192.168.33.3 UGS 0 1500 em1 127.0.0.1 link#9 UH 22 16384 lo0 192.168.1.0/24 link#3 U 2171 1500 em2 192.168.1.5 link#3 UHS 0 16384 lo0 192.168.11.0/24 link#1 U 240160 1500 em0 192.168.11.110 link#1 UHS 0 16384 lo0 192.168.33.0/24 link#2 U 4159 1500 em1 192.168.33.116 link#2 UHS 0 16384 lo0Trace von der pfSense:
1 192.168.1.2 (192.168.1.2) 0.496 ms 0.292 ms 0.275 ms 2 * * * 3 10.49.0.181 (10.49.0.181) 14.331 ms * 10.854 msTrace von einem Client bleibt als 1 Hop bei der LAN Schnittstelle der pfSense 192.168.11.110, danach kommen nur noch Sternchen.
Meine NAT Einstellungen:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description Kunde2 192.168.11.0/24 * 10.49.0.0/24 * Kunde2 address * NO testen2 Kunde2 192.168.11.0/24 * 192.168.1.0/24 * Kunde2 address * NO 192.168.1.1er WAN 192.168.11.0/24* * * WAN address * NO www nach aussen WAN 192.168.11.0/24 * 10.112.116.0/24 * WAN address * NO Kunde1 test -
Da sind ein paar Dinge nicht ganz sauber.
Diese beiden Routen überschneiden sich:
Destination Gateway Flags Use Mtu Netif Expire 10.49.0.0/24 192.168.1.2 UGS 431 1500 em2 10.49.0.80/28 link#3 U 122 1500 em2Das könnte vielleicht noch funktioniern, aber wie soll das denn gehen:
pfSense 10.49.0.84/28 ) ------ Kundennetz | | 10.49.0.81 | | 192.168.2.1 Router Kunde --------VPN------10.49.0.181Wie ist da das Kundennetz 10.49.0.84/28 mit dem Kundenrouter verbunden?
-
Destination Gateway Flags Use Mtu Netif Expire default 192.168.33.1 UGS 408023 1500 em1 10.49.0.80/28 link#3 U 133 1500 em2 10.49.0.84 link#3 UHS 0 16384 lo0 10.49.0.176/28 192.168.1.2 UGS 226 1500 em2 10.112.116.0/24 192.168.33.3 UGS 0 1500 em1 127.0.0.1 link#9 UH 26 16384 lo0 192.168.1.0/24 link#3 U 10356 1500 em2 192.168.1.5 link#3 UHS 0 16384 lo0So funktioniert es auch nicht.
Der Aufbau funktioniert.
Momentan läuft ein alter ipCop 1.4, den ich ersetzen möchte.Der Router hat die 192.168.1.2 (da hatte ich einen Tippfehler)
Der Server 10.49.0.81 hat wahrscheinlich auch eine viruelle IP 192.168.1.81
Server 81 und Router steht bei uns im Haus.über die 192.168.1.2 wird nach 10.49.0.181 verbunden.
Die Netzmaske ist die /28 bei dem 10er Netz -
192.168.1.2 macht es ja auch nicht besser.
Die Frage ist, wie diese IP an dem Kundennetz 10.49.0.80/28 hängt.Ist 10.49.0.81 der Kundenrouter? Wenn ja, was ist dann obige, der VPN-Server? Wenn ja, sollte 10.49.0.181 auch eine VPN-IP in dem Netz haben.
-
Meine pfSense hat an dieser Schnittstelle zwei IPs:
10.49.0.84 und virtuell die 192.168.1.5daran hängt ein Server des Kunden.
Dieser hat die IP 10.49.0.81 und die 192.168.1.81 (die arp Tabelle zeigt für beide eine identische MAC)auf diesen Server kann ich von meinem LAN aus zugreifen.
Somit existieren auf meiner Seite zwei Netze, bestehend aus den selben Maschinen.1)192.168.1.0/24
2) 10.49.0.80/28als Gateway dient ein Router des Kunden mit der IP 192.168.1.2
Beim Kunden im Büro steht ein Server mit der IP 10.49.0.181 /28 (die /28 vermute ich).
10.49.0.81
+
192.168.1.81(virtuell)
|
|
LAN 192.168.11.0/24 –---- (192.168.11.110 pfSense 10.49.0.84/28 ) ------ -----------
+ |
virtuell 192.168.1.5/24 |
192.168.2.1 Router Kunde -----/ /------10.49.0.181 (Büro Kunde)Der iPCop, den ich mit der 192.168.1.1 in diesem Netz am Laufen habe hat folgende Konfiguration:
ifconfig eth1:0 192.168.1.1 /sbin/iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.1.1 route add -net 10.49.0.0 netmask 255.255.255.0 gw 192.168.1.2Diese habe ich in pfSense nachgebaut, aber ohne Erfolg.
An irgendeiner Stelle funktioniert pfSense anders.Meine Anfragen an die 10.49.0.181 verschwinden im Nirvana und ich finde nirgends einen Hinweis.
-
Okay, das war mit "virtuell 192.168.1.5/24" gemeint.
Dabei hilft dir wieder das Outbound NAT. Lege eine Regel für WAN an, gib als Source dein LAN-Netz an, als Destination 10.49.0.181 (damit es nicht für den gesamten Traffic nach WAN gilt) und als Tranlation dir virtuelle IP 192.168.1.5.
Positioniere diese Regel aber oberhalb der Standard-WAN Regel damit sie eher greift!Die Route für den Server über 192.168.1.2 musst du in der pfSense allerdings auch wieder setzen. Wenn es nur der eine Host ist, kannst du sie ja mit /32 setzen oder ein entsprechend schmales Netz, das sich mit deinem WAN nicht in die Quere kommt.
-
Das verstehe ich nicht ganz :-[
Bevor ich frage.
Ich habe der pfSense die IP des IPCops zugewiesen (10.49.0.83)
Danach konnte ich den Server 10.49.0.181 pingen.
Liegt es dann nicht an der Rückroute des Servers bzw. des GWs, auf die ich keinen Zugriff habe?–------
Zu deinem Ansatz:Wieso kommt hier das WAN Interface ins Spiel?
Dieses kommt hier doch überhaupt nicht zum tragen, oder doch?[quote]Die Route für den Server über 192.168.1.2 musst du in der pfSense allerdings auch wieder setzen. Wenn es nur der eine Host ist, kannst du sie ja mit /32 setzen oder ein entsprechend schmales Netz, das sich mit deinem WAN nicht in die Quere kommt.
Wie gesagt, auf die 192.168.1.2 (router) und den Server (10.49.0.181) habe ich keinen Zugriff.
Meine Anfragen gehen richtig raus.Oder meinst du, dass ich der pfSense mitteilen muss, dass Antworten von 192.168.2.1 (oder von 10.49.0.181??) über das Interface 10.49.0.84 als GW in mein LAN geleitet werden sollen?
Da stehe ich jetzt auf dem Schlauch.
Aber irgendwie liegt eine Lösung in der Luft.
-
Ich habe der pfSense die IP des IPCops zugewiesen (10.49.0.83)
Danach konnte ich den Server 10.49.0.181 pingen.
Liegt es dann nicht an der Rückroute des Servers bzw. des GWs, auf die ich keinen Zugriff habe?Von einem LAN Host aus klappte der Ping?
Hab ich das überlesen?Das ist schon möglich. Dann könnte die Sache so gelöst sein, dass auf dem Kunden Router eine statische Route für dein LAN über
10.49.0.83 gesetzt ist.
Wenn deine pfSene eine andere IP hat, geht das dann natürlich nicht.Mit dieser Route könntest du dir auch das Outbound NAT ersparen, bzw. mit der anderen IP brauchst du die Regel.
Wieso kommt hier das WAN Interface ins Spiel?
Dieses kommt hier doch überhaupt nicht zum tragen, oder doch?Ich bin davon ausgegangen, dass 10.49.0.84 dein WAN Interface ist wie im oberen Schema das Kunden-Netz an deinem WAN hängt.
Ja die Route zu dem Server brauchst du auf der pfSense. Zuvor hattest du ja diese:
Destination Gateway Flags Use Mtu Netif Expire 10.49.0.0/24 192.168.1.2 UGS 431 1500 em2Die ist nun entsprechend deiner letzten Routing-Tabelle weg.
10.49.0.84
-
Von einem LAN Host aus klappte der Ping?
Ja,mit der IP10.49.0.83 als IP auf dem Interface
Das sind meine Routen:
Destination Gateway Flags Use Mtu Netif Expire default 192.168.33.1 UGS 5541 1500 em1 10.49.0.80/28 link#3 U 0 1500 em2 10.49.0.84 link#3 UHS 346 16384 lo0 10.49.0.176/28 192.168.1.2 UGS 6 1500 em2 10.112.116.0/24 192.168.33.3 UGS 0 1500 em1 127.0.0.1 link#9 UH 12 16384 lo0 192.168.1.0/24 link#3 U 3409 1500 em2 192.168.1.5 link#3 UHS 0 16384 lo0 192.168.11.0/24 link#1 U 16452 1500 em0 192.168.11.110 link#1 UHS 0 16384 lo0 192.168.33.0/24 link#2 U 7587 1500 em1 192.168.33.116 link#2 UHS 0 16384 lo0Die 192.168.33.1 ist die Fritzbox und die 192.168.33.116 mein WAN interface.
Das ist schon möglich. Dann könnte die Sache so gelöst sein, dass auf dem Kunden Router eine statische Route für dein LAN über
10.49.0.83 gesetzt ist.Bin ich dann "Fertig" und der Kunden Admin muss jetzt ran?
Oder kann ich mit einem Outbound NAT die Sache selbst lösen?Wobei ich echt nicht mehr wüsste, was ändern.
Momentan habe ich folgende Outbound Regeln:Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Kunde 192.168.11.0/24 * 10.49.0.176/28 * Kundeninterface address * NO Kunde 192.168.11.0/24 * 10.49.0.80/28 * Kundeninterface address * NO Kunde 192.168.11.0/24 * 192.168.1.0/24 * 192.168.1.5 * NO -
Oder kann ich mit einem Outbound NAT die Sache selbst lösen?
Ja. Hab ich doch schon oben beschrieben.
Ändere bei der ersten Regel fürs Kunden-Interface die Translation Adresse auf 192.168.1.5 und es sollte klappen.
Regel 2 u. 3 vom Kunden-Interface sind sinnlos.Wenn ich es nun richtig verstanden habe, ist ja 192.168.1.5 nun die virtuelle IP des Kunden-Interfaces, aber eben auch die, die der Kunden-Router kennt, weil sie in seinem Netz ist. Dahin muss die Quell-IP übersetzt werden, wenn ein Paket das Interface Richtung Kunden-Router verlässt.
Das ist genau das, was die NAT-Regel in IpCop auch macht. Postrouting ist hier Outbound NAT und SNAT heißt das die Source-IP transferiert wird. Das ist bei Outbound-NAT selbstverständlich.
IPCop hatte aber offenbar 192.168.1.1 als IF-IP.Aber das funktioniert nur, wenn 192.168.1.5 im selben Subnetz ist wie der Kunden-Router. Das hast du jedenfalls oben geschrieben.
-
Hallo viragomann,
:D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D
Daaaaaaaanke.
Ist irgendwo logisch, aber ich habe es nicht gepeilt.
Es funktioniert.
Ha ist das cool.Hey, seit Tagen und Stunden haue ich mir meine Freizeit um die Ohren.