Ich habe es fast
-
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.