kopie0123
Goto Top

Routing durch VPN Tunnel

Frohes Neues Jahr liebe Admins!

Zum neuen Jahr stehe ich vor einem Routingproblem...

Folgender Aufbau:
16ad01a993888e5e85526e265d68c69c


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 ipsec0

Leider 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 ipsec0

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:
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 eth1

Bitte um Hilfe...

Viele Grüße

Content-Key: 225714

Url: https://administrator.de/contentid/225714

Ausgedruckt am: 28.03.2024 um 14:03 Uhr

Mitglied: aqui
aqui 02.01.2014, aktualisiert am 03.01.2014 um 11:45:29 Uhr
Goto Top
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:
  • 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 !
Diese VPN Kopplung inkl. Pingtest ist erstmal der erste Meilenstein der genommen werden muss bevor man weitermacht !
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
Mitglied: MrNetman
MrNetman 02.01.2014, aktualisiert am 03.01.2014 um 11:45:26 Uhr
Goto Top
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
Mitglied: kopie0123
kopie0123 02.01.2014 um 14:56:38 Uhr
Goto Top
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
Mitglied: MrNetman
MrNetman 02.01.2014, aktualisiert am 03.01.2014 um 11:45:32 Uhr
Goto Top
Aber der Switch ist nicht der Endpunkt, sondern der zweite ipCop.
Mitglied: kopie0123
kopie0123 02.01.2014 um 14:58:31 Uhr
Goto Top
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
Mitglied: kopie0123
kopie0123 02.01.2014 um 15:02:48 Uhr
Goto Top
Ich habe das Bild im Beitrag noch mal aktualisiert, daraus sollten die 3 Subnetze besser hervorgehen.
Mitglied: kopie0123
kopie0123 02.01.2014 um 15:07:24 Uhr
Goto Top
Ergänzung:

Ein Hinzufügen der Route
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1 ipsec0
endet auch im Fehler.

Grüße
Mitglied: Th0mKa
Lösung Th0mKa 02.01.2014, aktualisiert am 03.01.2014 um 11:45:37 Uhr
Goto Top
Zitat von @kopie0123:

Ergänzung:

Ein Hinzufügen der Route
route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.0.1 ipsec0
endet auch im Fehler.

Grüße

Moin,

kannst du zum testen mal das Interface weglassen? Der Router sollte auch so wissen über welches Interface er routen muss.

VG,

Thomas
Mitglied: aqui
Lösung aqui 02.01.2014, aktualisiert am 03.01.2014 um 11:45:40 Uhr
Goto Top
@stingermac
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)
Hier bei den Netzen .0.42 und .0.0 muss nun ein transparentes Routing möglich sein zwischen diesen beiden lokalen Netzen.
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.
Das sind die zwingend notwendigen Routing ToDos.
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).
Mitglied: kopie0123
kopie0123 02.01.2014 aktualisiert um 17:53:14 Uhr
Goto Top
@aqui: kein problem ;)


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

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

Fü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 ipsec0

Ich habe nun mit
 route add -net 192.168.42.0 netmask 255.255.255.0 gw EXTERNIP ipsec0
die Tabelle erweitert auf:

192.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 ipsec0

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...
Mitglied: aqui
Lösung aqui 02.01.2014, aktualisiert am 03.01.2014 um 11:45:45 Uhr
Goto Top
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 !
Mitglied: sk
Lösung sk 03.01.2014 aktualisiert um 11:45:44 Uhr
Goto Top
Mitglied: aqui
aqui 03.01.2014 aktualisiert um 11:45:48 Uhr
Goto Top
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....
Mitglied: kopie0123
kopie0123 03.01.2014 um 11:45:12 Uhr
Goto Top
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...
Mitglied: aqui
aqui 03.01.2014 aktualisiert um 12:16:41 Uhr
Goto Top
pfSense und Mikrotik sind deine Freunde... face-wink Oder VPN spezifische Router ala Cisco 886, Lancom usw. usw. Es gibt wie immer viele wege nach Rom.
Das Forum hat diverse Infos dazu...