Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Routing durch VPN Tunnel

Frage Netzwerke Router & Routing

Mitglied: kopie0123

kopie0123 (Level 2) - Jetzt verbinden

02.01.2014, aktualisiert 15:08 Uhr, 5762 Aufrufe, 15 Kommentare, 1 Danke

Frohes Neues Jahr liebe Admins!

Zum neuen Jahr stehe ich vor einem Routingproblem...

Folgender Aufbau:
16ad01a993888e5e85526e265d68c69c - Klicke auf das Bild, um es zu vergrößern


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

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

01.
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:
01.
Kernel IP routing table 
02.
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
03.
localhost       *               255.255.255.255 UH    0      0        0 tun0 
04.
192.168.5.0     externIP        255.255.255.0   UG    0      0        0 ipsec0 
05.
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0 
06.
192.168.42.0    192.168.0.201   255.255.255.0   UG    0      0        0 eth0 
07.
192.168.41.0    192.168.0.201   255.255.255.0   UG    0      0        0 eth0 
08.
default         externIP          0.0.0.0         UG    0      0        0 eth1
Bitte um Hilfe...

Viele Grüße
Mitglied: aqui
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
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:
http://www.administrator.de/wissen/ipsec-vpn-mit-cisco-mikrotik-pfsense ...
oder mit OpenVPN
http://www.administrator.de/wissen/openvpn-server-installieren-auf-dd-w ...
Bitte warten ..
Mitglied: MrNetman
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
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
Bitte warten ..
Mitglied: kopie0123
02.01.2014 um 14:56 Uhr
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
Bitte warten ..
Mitglied: MrNetman
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
Aber der Switch ist nicht der Endpunkt, sondern der zweite ipCop.
Bitte warten ..
Mitglied: kopie0123
02.01.2014 um 14:58 Uhr
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
Bitte warten ..
Mitglied: kopie0123
02.01.2014 um 15:02 Uhr
Ich habe das Bild im Beitrag noch mal aktualisiert, daraus sollten die 3 Subnetze besser hervorgehen.
Bitte warten ..
Mitglied: kopie0123
02.01.2014 um 15:07 Uhr
Ergänzung:

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

Grüße
Bitte warten ..
Mitglied: tkr104
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
Zitat von kopie0123:

Ergänzung:

Ein Hinzufügen der Route
01.
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
Bitte warten ..
Mitglied: aqui
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
@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).
Bitte warten ..
Mitglied: kopie0123
02.01.2014, aktualisiert um 17:53 Uhr
@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.

01.
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:

01.
192.168.0.0     EXTERNIP     255.255.255.0   UG    0      0        0 ipsec0
Ich habe nun mit
01.
 route add -net 192.168.42.0 netmask 255.255.255.0 gw EXTERNIP ipsec0
die Tabelle erweitert auf:

01.
 
02.
192.168.0.0     EXTERNIP     255.255.255.0   UG    0      0        0 ipsec0 
03.
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...
Bitte warten ..
Mitglied: aqui
LÖSUNG 02.01.2014, aktualisiert 03.01.2014
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 !
Bitte warten ..
Mitglied: aqui
LÖSUNG 03.01.2014, aktualisiert um 11:45 Uhr
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....
Bitte warten ..
Mitglied: kopie0123
03.01.2014 um 11:45 Uhr
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...
Bitte warten ..
Mitglied: aqui
LÖSUNG 03.01.2014, aktualisiert um 12:16 Uhr
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...
Bitte warten ..
Neuester Wissensbeitrag
Festplatten, SSD, Raid

12TB written pro SSD in 2 Jahren mit RAID5 auf Hyper-VServer

Erfahrungsbericht von Lochkartenstanzer zum Thema Festplatten, SSD, Raid ...

Ähnliche Inhalte
Router & Routing
PfSense Routing durch VPN-Tunnel (2)

Tipp von FA-jka zum Thema Router & Routing ...

Voice over IP
Mitel Softphone: automatischer VPN-Tunnel? (5)

Frage von chappy72 zum Thema Voice over IP ...

Heiß diskutierte Inhalte
Windows Userverwaltung
Ausgeschiedene Mitarbeiter im Unternehmen - was tun mit den AD Konten? (34)

Frage von patz223 zum Thema Windows Userverwaltung ...

LAN, WAN, Wireless
gelöst Server erkennt Client nicht wenn er ausserhalb des DHCP Pools liegt (28)

Frage von Mar-west zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
FritzBox, zwei Server, verschiedene Netze (21)

Frage von DavidGl zum Thema LAN, WAN, Wireless ...

Viren und Trojaner
Aufgepasst: Neue Ransomware Goldeneye verbreitet sich rasant (20)

Link von Penny.Cilin zum Thema Viren und Trojaner ...