Ich habe es fast



  • Hallo zusammen,

    ich fank mal ein neues Topic an, da ich inzwischen einiges mit eurer Hilfe lösen konnte.

    Hier mein verbliebenes Problem:

    Mein Netz:

    LAN 192.168.11.0/24  –---- (192.168.11.110    pfSense  192.168.33.116) ------ WAN 192.168.33.0/24
                                                                                                                                            |
                                                                                                                                            |
                                                                                                                                            192.168.33.1 Fritzbox ---- ISP
                                                                                                                                            |
                                                                                                                                            |
                                                                                                                                            |
                                                                                                                                            192.168.33.3 Router Kunde ----- 10.112.116.0/24
                                                                                                                                                                                                          |
                                                                                                                                                                                                          |
                                                                                                                                                                                                10.112.116.220

    Im WAN Netz habe ich eine Fritzbox mit 192.168.33.1 und eine Kundenrouter mit 192.168.33.3.
    Die Fritzbox habe ich als default GW eingetragen.

    Für den Kunden Router habe ich ein GW erstellt.
    Zudem eine Route für 10.112.116.0/24 über den Kunden Router als GW.
    Traceroute zeigt als ersten Hop den Kundenrouter.

    Ich kann erst auf den Server 10.112.116.220 zugreifen, wenn ich den Kundenrouter als default GW setze.
    Sobald ich die Fritzbox als default GW einstelle, kann ich nicht mehr auf den Server 10.112.116.220 zugreifen.
    Traceroute hat denn als ersten Hop die Fritzbox.

    Woran könnte das liegen?



  • Hallo,

    also wenn du mit einer statischen Route das 10.112.116.0/24 Netz auf 192.168.33.3 schickst, sollte das in jedem Fall funktionieren. Damit hast du für dieses Ziel ja schon das richtige Gateway.

    Poste bitte deine IPv4 Routing-Tabelle und eine die Ausgabe eines Traceroutes zu 10.112.116.220. Beides im Diagnostic Menü der pfSense zu finden.



  • Hallo viragomann,
    ich habe noch etwas getestet. Wenn ich unter Interfaces -> WAN das IPv4 Upstream Gateway auf "None" setze, funktioniert die Route und ich kann mit dem Server 10.112.116.220 verbinden.
    Allerdings habe ich dann kein Internet über meine Fritzbox.

    Sobald ich als IPv4 Upstream Gateway meine Fritzbox (default GW) setze funktioniert das www, aber die Verbindung zum Server 10.112.116.220 nicht.

    Hier die Informationen mit IPv4 Upstream Gateway aud None:

    
    Destination	Gateway	Flags	Use	Mtu	Netif	Expire	 
    default	192.168.33.1	UGS	8	1500	em1
    10.112.116.0/24	192.168.33.3	UGS	13	1500	em1
    127.0.0.1	link#9	UH	24	16384	lo0
    192.168.11.0/24	link#1	U	31587	1500	em0
    192.168.11.110	link#1	UHS	0	16384	lo0
    192.168.33.0/24	link#2	U	38	1500	em1
    192.168.33.116	link#2	UHS	0	16384	lo0
    
    
     192.168.33.3 (192.168.33.3)  2.881 ms  2.834 ms  2.819 ms
     2  * * *
     3  * * *
    
    

    Hier die Informationen mit IPv4 Upstream Gateway auf der Fritzbox 192.168.33.1:

    
    Destination	Gateway	Flags	Use	Mtu	Netif	Expire	 
    default	192.168.33.1	UGS	5	1500	em1
    10.112.116.0/24	192.168.33.3	UGS	14	1500	em1
    127.0.0.1	link#9	UH	26	16384	lo0
    192.168.11.0/24	link#1	U	34523	1500	em0
    192.168.11.110	link#1	UHS	0	16384	lo0
    192.168.33.0/24	link#2	U	50	1500	em1
    192.168.33.116	link#2	UHS	0	16384	lo0
    
    
    
    1  192.168.33.1 (192.168.33.1)  0.706 ms  0.694 ms  0.933 ms
     2  * * *
     3  * * *
    
    

    Wenn ich das IPv4 Upstream Gateway auf "None" setze, kann ich google von der pfSense pingen und tracen, aber nicht von einem Client.

    Markus



  • Ich glaube ich hab's.

    Nachdem ich ein Outbound NAT gesetzt habe, kann ich sowohl auf das www, als auch auf den Server zugreifen.

    Macht das Sinn, oder habe ich mir da ein Sicherheitsloch eingebaut?

    Markus



  • 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.181

    Von 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	lo0
    
    

    Trace 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 ms
    

    Trace 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	em2
    
    

    Das 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.181
    
    

    Wie 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	lo0
    
    

    So 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.5

    daran 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/28

    als 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.2
    
    

    Diese 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.



  • @mark99:

    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.

    @mark99:

    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	em2
    
    

    Die 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	lo0
    
    

    Die 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
    
    


  • @mark99:

    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.


Log in to reply