15
Routing durch VPN Tunnel
Frohes Neues Jahr liebe Admins!
Zum neuen Jahr stehe ich vor einem Routingproblem...
Folgender Aufbau:
Zwischen den beiden IPCops besteht ein IPSec Tunnel.
192.168.42.2 ist hierbei ein VOIP Server, das IPhone 192.168.5.4 soll nun auf diesen zugreifen.
Dazu habe ich versucht folgende Routingregel auf dem IPCop 192.168.5.1 einzutragen (er muss ja wissen, dass 192.168.42.0/24 über den IPSec Tunnel erreichbar ist):
Leider bekomme ich die Fehlermeldung: SIOCADDRT: Network is unreachable
Ebenso bei
Während der Fehlersuche habe ich festgestellt, dass die IPCops nicht ihren IPSec partner und dessen Subnetz pingen können. Zwischen den Subnetzen ist ein ping möglich.
Im IPCop 192.168.0.1 ist bereits folgende Routingregel angelegt:
Bitte um Hilfe...
Viele Grüße
Zum neuen Jahr stehe ich vor einem Routingproblem...
Folgender Aufbau:
Zwischen den beiden IPCops besteht ein IPSec Tunnel.
192.168.42.2 ist hierbei ein VOIP Server, das IPhone 192.168.5.4 soll nun auf diesen zugreifen.
Dazu habe ich versucht folgende Routingregel auf dem IPCop 192.168.5.1 einzutragen (er muss ja wissen, dass 192.168.42.0/24 über den IPSec Tunnel erreichbar ist):
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.201 ipsec0Leider bekomme ich die Fehlermeldung: SIOCADDRT: Network is unreachable
Ebenso bei
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1 ipsec0Während der Fehlersuche habe ich festgestellt, dass die IPCops nicht ihren IPSec partner und dessen Subnetz pingen können. Zwischen den Subnetzen ist ein ping möglich.
Im IPCop 192.168.0.1 ist bereits folgende Routingregel angelegt:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localhost * 255.255.255.255 UH 0 0 0 tun0
192.168.5.0 externIP 255.255.255.0 UG 0 0 0 ipsec0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.42.0 192.168.0.201 255.255.255.0 UG 0 0 0 eth0
192.168.41.0 192.168.0.201 255.255.255.0 UG 0 0 0 eth0
default externIP 0.0.0.0 UG 0 0 0 eth1Bitte um Hilfe...
Viele Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 225714
Url: https://administrator.de/forum/routing-durch-vpn-tunnel-225714.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
15 Kommentare
Neuester Kommentar
Ein Routing Eintrag ist doch auch überflüssiger Blödsinn in so einem simplen und banalen VPN Szenario ! Die beiden lokalen Netze "kennen" sich doch schon automatisch wenn der VPN Tunnel erfolgreich aufgebaut ist !!
Die IPCops wissen damit das sie die beiden lokalen LANs in den Tunnel routen müssen und alles andere eben ins Internet.
Eine zusätzliche Route ist da also völliger Blödsinn udn obsolet, das müsste dir einleuchten !
Fragen wir erstmal die VPN Kardinalsfragen:
Wenn das erreicht ist dann wird aber der Rest schon automatisch klappen, denn dann sind beide lokalen netze per Routing verbunden und man kann dort ALLES auch erreichen ! ...Der tiefere Sinn eines jeden Site to Site VPNs !!
<update>
Ergänzung siehe Thread unten
</update>
Grundlagen zu solchen Szenarien erklären die folgenden Tutorials:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
oder mit OpenVPN
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die IPCops wissen damit das sie die beiden lokalen LANs in den Tunnel routen müssen und alles andere eben ins Internet.
Eine zusätzliche Route ist da also völliger Blödsinn udn obsolet, das müsste dir einleuchten !
Fragen wir erstmal die VPN Kardinalsfragen:
- Welches VPN Protokoll nutzt du ? L2TP, IPsec, PPTP, OpenVPN, SSL oder...??
- Ist das VPN denn schon so aktiv und korrekt eingerichtet ?
- Sind die statischen Routen in allen 3 Komponenten eingetragen <Update !>
- Kannst du vom 192.168.42.0 /24er Netz alles pingen im 192.168.5.0 /24er Netz ? Und vice versa...
- Kannst du vom 192.168.5.0 /24er Netz alles pingen im 192.16842.0 /24er Netz ?
- Wenn die Pings nicht funktionieren hast du alle lokalen Firewalls der Rechner angepasst das sie diese Zugriffe aus dem Fremdnetz zulassen ?? Per Default wird das immer geblockt wie jeder Netzwerker weiss !
Wenn das erreicht ist dann wird aber der Rest schon automatisch klappen, denn dann sind beide lokalen netze per Routing verbunden und man kann dort ALLES auch erreichen ! ...Der tiefere Sinn eines jeden Site to Site VPNs !!
<update>
Ergänzung siehe Thread unten
</update>
Grundlagen zu solchen Szenarien erklären die folgenden Tutorials:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
oder mit OpenVPN
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
1
Warum sollte ein Switch ein Gateway sein?
Das Gateway muss ja der ipcop sein. Oder riutet der nicht.
Wenn es keinen Layer3 gibt reicht als Gateway der ipcop-Port, an dem der Switch angeschlossen ist.
Gruß
Netman
Das Gateway muss ja der ipcop sein. Oder riutet der nicht.
Wenn es keinen Layer3 gibt reicht als Gateway der ipcop-Port, an dem der Switch angeschlossen ist.
Gruß
Netman
Hallo aqui,
es geht ja nicht nur um die beiden VPN Subnetze, sondern um das Subnetz 192.168.42.0. Das VPN besteht zwischen 192.168.0.0 und 192.168.5.0.
Meiner Meinung nach muss ich also dem IPCop in 192.168.5.0 mitteilen, dass er Anfragen an das Subnetz 192.168.42.0 durch den VPn Tunnel schiebt und nicht durch Internet.
Ist das VPN denn schon so aktiv und korrekt eingerichtet ?
Läuft bereits uund funktioniert.
Viele Grüße
es geht ja nicht nur um die beiden VPN Subnetze, sondern um das Subnetz 192.168.42.0. Das VPN besteht zwischen 192.168.0.0 und 192.168.5.0.
Meiner Meinung nach muss ich also dem IPCop in 192.168.5.0 mitteilen, dass er Anfragen an das Subnetz 192.168.42.0 durch den VPn Tunnel schiebt und nicht durch Internet.
Ist das VPN denn schon so aktiv und korrekt eingerichtet ?
Läuft bereits uund funktioniert.
Viele Grüße
Aber der Switch ist nicht der Endpunkt, sondern der zweite ipCop.
Hallo MrNetmann,
das Subnetz 192.168.42.0 ist nicht direkt am IPCop angeschlossen.
Das Switch ist ein Layer 3 Switch. Die Netze 192.168.0.0 und 192.168.42.0 sind VLANs an diesem. Ein Routing zwischen diesen wird vom Switch übernommen,
Grüße
das Subnetz 192.168.42.0 ist nicht direkt am IPCop angeschlossen.
Das Switch ist ein Layer 3 Switch. Die Netze 192.168.0.0 und 192.168.42.0 sind VLANs an diesem. Ein Routing zwischen diesen wird vom Switch übernommen,
Grüße
Ich habe das Bild im Beitrag noch mal aktualisiert, daraus sollten die 3 Subnetze besser hervorgehen.
Ergänzung:
Ein Hinzufügen der Route
endet auch im Fehler.
Grüße
Ein Hinzufügen der Route
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1 ipsec0Grüße
Zitat von @kopie0123:
Ergänzung:
Ein Hinzufügen der Route
endet auch im Fehler.
Grüße
Ergänzung:
Ein Hinzufügen der Route
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1 ipsec0Grüße
Moin,
kannst du zum testen mal das Interface weglassen? Der Router sollte auch so wissen über welches Interface er routen muss.
VG,
Thomas
@stingermac
Sorry...mein Fehler ! Hab die Zeichnung nicht sorgfältig genug angesehen und den Layer 3 Switch auf der anderen Seite doch glatt übersehen...
Also folgende ToDos sind dann zu machen:
Andere Seite...
Damit muss dann ein Pingen jeglicher Geräte in den 3 lokalen LANs untereinander möglich sein. Das ist die Grundvoraussetzung fürs VoIP !
Mit einem Testsetup hier mit 2 mal pfSense und 2mal Mikrotik 750 mit IPsec VPN Tunnel und einem Cisco Catalyst 3550XL als L3 Switch rennt das problemlos. (IPCop konnte ich mangels HW nicht testen).
Sorry...mein Fehler ! Hab die Zeichnung nicht sorgfältig genug angesehen und den Layer 3 Switch auf der anderen Seite doch glatt übersehen...
Meiner Meinung nach muss ich also dem IPCop in 192.168.5.0 mitteilen, dass er Anfragen an das Subnetz 192.168.42.0 durch den VPn Tunnel schiebt und nicht durch Internet.
Da hast du Recht...keine Frage !Also folgende ToDos sind dann zu machen:
- Default Gateway vom Host .42.2 auf die .42.1
- Statische Layer 3 Switch Default Route (ip route 0.0.0.0 0.0.0.0) auf die .0.1
- Statische IPCop A Route: Zielnetz 192.168.42.0 /24 auf Gateway IP .0.201 (Layer 3 Switch)
Andere Seite...
- Default Gateway vom Host .5.4 auf die .5.1
- IPCop B muss hier eine statische Route des Zielnetzes 192.168.42.0 /24 auf das VPN Tunnelinterface des anderen IPCop haben. Nimmt er das nicht an nimmt man statt des Tunnelinterfaces das lokale LAN 192.168.0.1 wie Kollege tkr104 oben schon angemerkt hat.
Damit muss dann ein Pingen jeglicher Geräte in den 3 lokalen LANs untereinander möglich sein. Das ist die Grundvoraussetzung fürs VoIP !
Mit einem Testsetup hier mit 2 mal pfSense und 2mal Mikrotik 750 mit IPsec VPN Tunnel und einem Cisco Catalyst 3550XL als L3 Switch rennt das problemlos. (IPCop konnte ich mangels HW nicht testen).
@aqui: kein problem ;)
Zwischen den beiden Subnetzen 192.168.0.0 und 192.168.42.0 ist die Kommunikation problemlos möglich.
.> Default Gateway vom Host .5.4 auf die .5.1
Default GW ist gesetzt. Der zweite ist eben genau das Problem, das Setzen der Route ist nicht möglich.
Führt ebenfalls zum Fehler.
Auf dem IPCop 192.168.5.1 gibt es folgenden Routingeintrag:
Ich habe nun mit
die Tabelle erweitert auf:
Leider eine Kommunikation zwischen 192.168.5.0 und 192.168.42.0 immer noch nicht möglich...
Für korrektes Routing müsste aber doch die IP 192.168.0.1 Ziel der Route für 192.168.42.0 sein. Genau diese Regel lässt sich nicht erstellen.
Vielleicht ein Fehler im IPCop? Versuche dies gerade herauszuinden...
Default Gateway vom Host .42.2 auf die .42.1
Statische Switch Default Route (ip route 0.0.0.0 0.0.0.0) auf die .0.1
Statische IPCop Route Zielnetz 192.168.42.0 /24 auf Gateway .0.201
Statische Switch Default Route (ip route 0.0.0.0 0.0.0.0) auf die .0.1
Statische IPCop Route Zielnetz 192.168.42.0 /24 auf Gateway .0.201
Zwischen den beiden Subnetzen 192.168.0.0 und 192.168.42.0 ist die Kommunikation problemlos möglich.
.> Default Gateway vom Host .5.4 auf die .5.1
IPCop muss hier eine statische Route des Zielnetzes 192.168.42.0 /24 auf das VPN Tunnelinterface des anderen IPCop haben. Nimmt er das nicht an nimmt man statt des Tunnelinterfaces das lokale LAN 192.168.0.1 wie Kollege tkr104 oben schon angemerkt hat.
Default GW ist gesetzt. Der zweite ist eben genau das Problem, das Setzen der Route ist nicht möglich.
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1Führt ebenfalls zum Fehler.
Auf dem IPCop 192.168.5.1 gibt es folgenden Routingeintrag:
192.168.0.0 EXTERNIP 255.255.255.0 UG 0 0 0 ipsec0Ich habe nun mit
route add -net 192.168.42.0 netmask 255.255.255.0 gw EXTERNIP ipsec0192.168.0.0 EXTERNIP 255.255.255.0 UG 0 0 0 ipsec0
192.168.42.0 EXTERNIP 255.255.255.0 UG 0 0 0 ipsec0Leider eine Kommunikation zwischen 192.168.5.0 und 192.168.42.0 immer noch nicht möglich...
Für korrektes Routing müsste aber doch die IP 192.168.0.1 Ziel der Route für 192.168.42.0 sein. Genau diese Regel lässt sich nicht erstellen.
Vielleicht ein Fehler im IPCop? Versuche dies gerade herauszuinden...
Für korrektes Routing müsste aber doch die IP 192.168.0.1 Ziel der Route für 192.168.42.0 sein.
Nein, nicht unbedingt, es kann auch ein Netzwerk Interface (wie hier bei dir das virtuelle Interface ipsec0 ) sein oder Default Netz Segment in sofern ist die o.a. Route also schon richtig. Muss sie ja auch sein weil sie genau so ja auch für das 0.0er Netz funktionell richtig ist.Routingmässig sieht das also korrekt aus ! Ist jetzt die Frage ob der IPCop auch noch Firewall Regeln auf den virtuellen Interfaces erstellt. Wenn das der Fall ist muss du da dann noch entsprechende Regeln verwenden.
pfSense ist da erheblich User freundlicher als der grausliche IPCop, da es ein erheblich besseres GUI hat...aber egal ist hier nicht das Thema.
Du musst also die Regel checken. Desweiteren wäre es interessant ob du aus dem 5.0er Netz das Layer 3 Switch interface .0.201 und .42.1 pingen kannst.
Wichtig wäre auch mal ein traceroute auf diese beiden IPs aus dem 5er Netz um mal zu sehen welche Hops noch gehen und wo es stockt. Wichtig ist zu wissen ob .5.0er Pakete vom IPCop mit Ziel .42.0 noch in den Tunnel geroutet werden oder nicht.
Der IPCop hier ist zu 98% der Problemkandidat !
Der o.a. URL erklärt das IPCop "Problem" elegant !!
Die Lösung mit dem 2ten Tunnel erscheint aber IPCop spezifisch etwas umständlich zumal sie auch noch Resourcen frisst. Der Trick mit dem "Supernetting" ist irgendwie sinnvoller in dem Zusammenhang.
Komisch das man beim IPCop solche Klimmzüge machen muss, denn andere VPN HW (und SW) erzwingt solche Workarounds nicht.
Aber die Lösung sollte damit nun für den Kollegen StingerMac ein Kinderspiel sein....
Die Lösung mit dem 2ten Tunnel erscheint aber IPCop spezifisch etwas umständlich zumal sie auch noch Resourcen frisst. Der Trick mit dem "Supernetting" ist irgendwie sinnvoller in dem Zusammenhang.
Komisch das man beim IPCop solche Klimmzüge machen muss, denn andere VPN HW (und SW) erzwingt solche Workarounds nicht.
Aber die Lösung sollte damit nun für den Kollegen StingerMac ein Kinderspiel sein....
Hallo zusammen,
mit einem zweiten Tunnel geht der Ping durch. Die Routen stimmen alle.
Ich kann zwar noch nicht die Statuswebseite aufrufen, aber das wird ein Proxy-Problem sein.
Vielen Dank für die Hilfe,
Grüße
PS: Dann werde ich mich mal mit einer IPCop Alternative beschäftigen...
mit einem zweiten Tunnel geht der Ping durch. Die Routen stimmen alle.
Ich kann zwar noch nicht die Statuswebseite aufrufen, aber das wird ein Proxy-Problem sein.
Vielen Dank für die Hilfe,
Grüße
PS: Dann werde ich mich mal mit einer IPCop Alternative beschäftigen...
pfSense und Mikrotik sind deine Freunde... 
Oder VPN spezifische Router ala Cisco 886, Lancom usw. usw. Es gibt wie immer viele wege nach Rom.
Das Forum hat diverse Infos dazu...
Oder VPN spezifische Router ala Cisco 886, Lancom usw. usw. Es gibt wie immer viele wege nach Rom.Das Forum hat diverse Infos dazu...
