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

Problem Routing über VPN Router

Frage Netzwerke

Mitglied: wolfgang85

wolfgang85 (Level 1) - Jetzt verbinden

10.03.2009, aktualisiert 17:56 Uhr, 3794 Aufrufe, 4 Kommentare

Servus!

Ich hab ein Problem mit OpenWRT, wir haben einen Linksys WRT54GL mit OpenWRT geflasht. Der soll die Verbindung über T-DSL zu unserem VPN Gateway herstellen. Der Client sollte nur auf unseren Citrix Server kommen. Die OpenVPN Verbindung kann ich wunderbar ohne herstellen, den Citrix Server kann ich auch anpingen vom Router aus, aber dies wird nicht an den Client weitergegeben.

Hier nochmal die Einstellungen im Überblick:

Router: Linksys WRT54GL
IP: 172.16.7.1 / 255.255.255.0
Firmware: 8.09 Kamikaze
IP Citrix Server: 192.168.1.63 / 255.255.0.0

Hier die Routingtables vom Router
01.
root@rtrgra:~# route 
02.
Kernel IP routing table 
03.
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
04.
10.10.10.1      10.10.10.29     255.255.255.255 UGH   0      0        0 tun0 
05.
217.0.116.91    *               255.255.255.255 UH    0      0        0 ppp0 
06.
10.10.10.29     *               255.255.255.255 UH    0      0        0 tun0 
07.
172.16.7.0      *               255.255.255.0   U     0      0        0 br-lan 
08.
172.16.0.0      10.10.10.29     255.255.0.0     UG    0      0        0 tun0 
09.
192.168.0.0     10.10.10.29     255.255.0.0     UG    0      0        0 tun0 
10.
default         217.0.116.91    0.0.0.0         UG    0      0        0 ppp0 
11.
root@rtrgra:~# ping -c 2 192.168.1.63 
12.
PING 192.168.1.63 (192.168.1.63): 56 data bytes 
13.
64 bytes from 192.168.1.63: seq=0 ttl=127 time=95.944 ms 
14.
64 bytes from 192.168.1.63: seq=1 ttl=127 time=96.539 ms 
15.
 
16.
--- 192.168.1.63 ping statistics --- 
17.
2 packets transmitted, 2 packets received, 0% packet loss 
18.
round-trip min/avg/max = 95.944/96.241/96.539 ms 
19.
root@rtrgra:~#
Hier meine OpenVPN Config:
01.
root@rtrgra:~# cat /etc/config/openvpn 
02.
remote <<IP Adresse>> 
03.
client 
04.
dev tun 
05.
key /etc/openvpn/AWG-wolfhu/wolfhu.key 
06.
tls-auth /etc/openvpn/AWG-wolfhu/psk.key 1 
07.
dh /etc/openvpn/AWG-wolfhu/dh2048.pem 
08.
ca /etc/openvpn/AWG-wolfhu/ca.crt 
09.
cert /etc/openvpn/AWG-wolfhu/wolfhu.crt 
10.
nobind 
11.
keepalive 10 60 
12.
comp-lzo 
13.
persist-key 
14.
persist-tun 
15.
verb 3 
16.
 
17.
root@rtrgra:~#

Hier die Einstellungen des Windows Rechners:
01.
C:\>tracert 192.168.1.63 
02.
 
03.
Routenverfolgung zu 192.168.1.63 über maximal 30 Abschnitte 
04.
 
05.
  1     1 ms    <1 ms    <1 ms  172.16.7.1 
06.
  2     *        *        *     Zeitüberschreitung der Anforderung. 
07.
  3     *        *        *     Zeitüberschreitung der Anforderung. 
08.
  4  ^C 
09.
C:\>ipconfig 
10.
 
11.
Windows-IP-Konfiguration 
12.
 
13.
Ethernetadapter WLAN: 
14.
        Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung 
15.
 
16.
Ethernetadapter LAN: 
17.
        Verbindungsspezifisches DNS-Suffix: awg 
18.
        IP-Adresse. . . . . . . . . . . . : 172.16.7.197 
19.
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0 
20.
        Standardgateway . . . . . . . . . : 172.16.7.1 
21.
 
22.
C:\>
Ich versteh nicht warum die Anfrage vom Client nicht vom Router über den Tunnel weitergegeben wird. Der Router ist Standardgateway und die IP wird über DHCP an den Client vergeben. Aber die 192.168.1.63 wird nach dem Hop zum Router verworfen...

Könnt ihr mir vielleicht helfen?

Gruß,
Wolfgang




// EDIT

Was ich noch vergessen habe, hier die ifconfig vom Router

01.
root@rtrgra:~# ifconfig 
02.
br-lan    Link encap:Ethernet  HWaddr 00:22:6B:8D:DC:C0 
03.
          inet addr:172.16.7.1  Bcast:172.16.7.255  Mask:255.255.255.0 
04.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
05.
          RX packets:15634 errors:0 dropped:0 overruns:0 frame:0 
06.
          TX packets:12503 errors:0 dropped:0 overruns:0 carrier:0 
07.
          collisions:0 txqueuelen:0 
08.
          RX bytes:1072239 (1.0 MiB)  TX bytes:1367174 (1.3 MiB) 
09.
 
10.
eth0      Link encap:Ethernet  HWaddr 00:22:6B:8D:DC:C0 
11.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
12.
          RX packets:20201 errors:0 dropped:0 overruns:0 frame:0 
13.
          TX packets:17580 errors:0 dropped:0 overruns:0 carrier:0 
14.
          collisions:0 txqueuelen:1000 
15.
          RX bytes:1993796 (1.9 MiB)  TX bytes:1934339 (1.8 MiB) 
16.
          Interrupt:4 
17.
 
18.
eth0.0    Link encap:Ethernet  HWaddr 00:22:6B:8D:DC:C0 
19.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
20.
          RX packets:15634 errors:0 dropped:0 overruns:0 frame:0 
21.
          TX packets:12503 errors:0 dropped:0 overruns:0 carrier:0 
22.
          collisions:0 txqueuelen:0 
23.
          RX bytes:1134775 (1.0 MiB)  TX bytes:1417186 (1.3 MiB) 
24.
 
25.
eth0.1    Link encap:Ethernet  HWaddr 00:22:6B:8D:DC:C0 
26.
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1 
27.
          RX packets:4572 errors:0 dropped:0 overruns:0 frame:0 
28.
          TX packets:5080 errors:0 dropped:0 overruns:0 carrier:0 
29.
          collisions:0 txqueuelen:0 
30.
          RX bytes:495981 (484.3 KiB)  TX bytes:375611 (366.8 KiB) 
31.
 
32.
lo        Link encap:Local Loopback 
33.
          inet addr:127.0.0.1  Mask:255.0.0.0 
34.
          UP LOOPBACK RUNNING  MTU:16436  Metric:1 
35.
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0 
36.
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 
37.
          collisions:0 txqueuelen:0 
38.
          RX bytes:3203 (3.1 KiB)  TX bytes:3203 (3.1 KiB) 
39.
 
40.
ppp0      Link encap:Point-to-Point Protocol 
41.
          inet addr:84.146.130.183  P-t-P:217.0.116.91  Mask:255.255.255.255 
42.
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1 
43.
          RX packets:1982 errors:0 dropped:0 overruns:0 frame:0 
44.
          TX packets:2489 errors:0 dropped:0 overruns:0 carrier:0 
45.
          collisions:0 txqueuelen:3 
46.
          RX bytes:342625 (334.5 KiB)  TX bytes:222714 (217.4 KiB) 
47.
 
48.
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
49.
          inet addr:10.10.10.30  P-t-P:10.10.10.29  Mask:255.255.255.255 
50.
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1 
51.
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
52.
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
53.
          collisions:0 txqueuelen:100 
54.
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B) 
55.
 
56.
root@rtrgra:~#
… und anschließend noch die Netzwerkkonfiguration
01.
root@rtrgra:~# cat /etc/config/network 
02.
 
03.
config 'switch' 'eth0' 
04.
        option 'vlan0' '0 1 2 3 5*' 
05.
        option 'vlan1' '4 5' 
06.
 
07.
config 'interface' 'loopback' 
08.
        option 'ifname' 'lo' 
09.
        option 'proto' 'static' 
10.
        option 'ipaddr' '127.0.0.1' 
11.
        option 'netmask' '255.0.0.0' 
12.
 
13.
config 'interface' 'lan' 
14.
        option 'type' 'bridge' 
15.
        option 'ifname' 'eth0.0' 
16.
        option 'proto' 'static' 
17.
        option 'macaddr' '' 
18.
        option 'ip6addr' '' 
19.
        option 'gateway' '' 
20.
        option 'ip6gw' '' 
21.
        option 'dns' '' 
22.
        option 'ipaddr' '172.16.7.1' 
23.
        option 'netmask' '255.255.255.0' 
24.
 
25.
config 'interface' 'wan' 
26.
        option 'ifname' 'eth0.1' 
27.
        option 'proto' 'pppoe' 
28.
        option 'macaddr' '' 
29.
        option 'username' 't-online-com/<<Benutzername>>@t-online-com.de' 
30.
        option 'password' '<<Passwort>>' 
31.
        option 'vpi' '' 
32.
        option 'vci' '' 
33.
        option 'defaultroute' '1' 
34.
        option 'ppp_redial' 'persist' 
35.
        option 'ip6addr' '' 
36.
        option 'netmask' '' 
37.
        option 'ip6gw' '' 
38.
        option 'dns' '' 
39.
        option 'mtu' '1492' 
40.
        option 'keepalive' '2' 
41.
 
42.
root@rtrgra:~# ping www.heise.de 
43.
PING www.heise.de (193.99.144.85): 56 data bytes 
44.
64 bytes from 193.99.144.85: seq=0 ttl=250 time=81.243 ms 
45.
64 bytes from 193.99.144.85: seq=1 ttl=250 time=76.291 ms 
46.
^C 
47.
--- www.heise.de ping statistics --- 
48.
2 packets transmitted, 2 packets received, 0% packet loss 
49.
round-trip min/avg/max = 76.291/78.767/81.243 ms 
50.
root@rtrgra:~#
Die Firewall hab ich mittels „/etc/init.d/firewall stop“ angehalten, hier noch die laufenden Prozesse

01.
root@rtrgra:~# /etc/init.d/firewall stop 
02.
root@rtrgra:~# ps -uax 
03.
  PID USER       VSZ STAT COMMAND 
04.
    1 root      1968 S    init 
05.
    2 root         0 SW<  [kthreadd] 
06.
    3 root         0 SW<  [ksoftirqd/0] 
07.
    4 root         0 SW<  [events/0] 
08.
    5 root         0 SW<  [khelper] 
09.
   19 root         0 SW<  [kblockd/0] 
10.
   50 root         0 SW   [pdflush] 
11.
   51 root         0 SW   [pdflush] 
12.
   52 root         0 SW<  [kswapd0] 
13.
   53 root         0 SW<  [aio/0] 
14.
   65 root         0 SW<  [mtdblockd] 
15.
  235 root         0 SWN  [jffs2_gcd_mtd3] 
16.
  247 root      1968 S    logger -s -p 6 -t 
17.
  248 root      1968 S    init 
18.
  257 root      1980 S    /sbin/syslogd -C16 -S 
19.
  259 root      1964 S    /sbin/klogd 
20.
  269 root      1980 S    syslogd -C16 
21.
  271 root      1960 S    klogd 
22.
  283 root      1136 S    /sbin/hotplug2 --override --persistent --max-children 
23.
  438 root         0 SW<  [b43] 
24.
  488 root      2560 S    /usr/sbin/pppd plugin rp-pppoe.so mtu 1492 mru 1492 n 
25.
  705 root         0 SW<  [ipolldevd] 
26.
  738 root      1808 S    hostapd -P /var/run/wifi-wlan0.pid -B /var/run/hostap 
27.
  746 root      1972 S    crond -c /etc/crontabs 
28.
  751 root      1940 S    /usr/sbin/dropbear -p 22 
29.
  756 root      1968 S    /usr/sbin/httpd -p 80 -h /www -r rtrgra 
30.
  777 nobody    1280 S    /usr/sbin/dnsmasq -K -D -y -Z -b -E -s awg -S /awg/ - 
31.
 1144 root      5120 S    /usr/sbin/openvpn --config /etc/config/openvpn 
32.
 1197 root      1996 S    /usr/sbin/dropbear -p 22 
33.
 1198 root      1980 S    -ash 
34.
 1226 root      1968 R    ps -uax 
35.
root@rtrgra:~#

Gruß,
Wolfgang
Mitglied: aqui
10.03.2009 um 18:33 Uhr
Vermutlich ist die Firewall im Server das Problem !! Sehr wahrscheinlich aber eine fehlende statische Route auf dem OpenWRT ??!!
Sofern dein VPN Netz ein anderes IP Netz hat blockt die Firewall dieses. Auch ist sehr oft der ICMP Support deaktiviert, den du mit einem Klick auf den Haken vor Auf eingehende Echoanforderungen antworten erst aktivieren musst, damit ein Ping (ICMP echo) funktioniert !!!

Das der Server den OpenWRT Router natürlich als default Gateway eingetragen haben muss sollte klar sein.
Hat er einen anderen Router als Gateway musst du dem Server mindestens eine statische Route auf das VPN Netz einstellen, sonst finden die Pakete den Rückweg nicht !!!
Wenn man es recht versteht, dann ist dein lokales Clientnetzwerk die 172.16.7.0 /24, der VPN Tunnel hat das IP Netzwerk 10.10.10.0 /24 und das Zielnetzwerk mit dem Server ist die 192.168.1.63 /16 !!

Das bedeutet das der Open WRT Router das Zielnetzwerk nicht kennt, denn er kennt ja nur das VLAN Netzwerk 10.10.10.x und sein lokales Netzwerk. Das Zielnetzwerk befindet sich aber HINTER dem VPN Gateway wo der OpenWRT sich einwählt.
Da er das 192.168.1.x Netzwerk nicht kennt versucht er das ins Internet zu routen wo es als RFC 1918 Netzwerk im Nirwana verschwindet !!!
Deshalb geht es auch nicht in den Tunnel !!
Du musst also nur schlicht und einfach dem OpenWRT eine statische Route eingeben damit ihm der Weg ins 192.168.0.0er Zielnetz bekannt ist ala:
ip route 192.168.0.0 Maske: 255.255.0.0, Gateway: 10.10.10.29 (oder tun0 als Interface Name !)

Das sollte das Problem sofort lösen !

Desweiteren hilft ein Blick ins Log des Servers !!

Weitere Anregungen findest du auch hier:
http://www.administrator.de/VPN_Einrichtung_mit_DSL_Routern_und_DD-WRT_ ...
Bitte warten ..
Mitglied: wolfgang85
11.03.2009 um 08:21 Uhr
Zitat von aqui:
Vermutlich ist die Firewall im Server das Problem !! Sehr
wahrscheinlich aber eine fehlende statische Route auf dem OpenWRT
??!!
Sofern dein VPN Netz ein anderes IP Netz hat blockt die Firewall
dieses. Auch ist sehr oft der ICMP Support deaktiviert, den du mit
einem Klick auf den Haken vor Auf eingehende Echoanforderungen
antworten
erst aktivieren musst, damit ein Ping (ICMP echo)
funktioniert !!!

Die Firewall vom Server ist nicht das Problem, vom Router aus kann ich den Citrix Server ja anpingen, ICMP Echos werden also nicht gefiltert.
Sobald der VPN Tunnel steht ist der PC ja sozusagen in unserem LAN (wird über unseren VPN Proxy geroutet). Denke aber nicht dass es an dem liegt, wie gesagt, vom Router aus komm ich auf den Citrix Server, nur der Router gibt das irgenwie nicht an den Client weiter.


Das der Server den OpenWRT Router natürlich als default Gateway
eingetragen haben muss sollte klar sein.
Hat er einen anderen Router als Gateway musst du dem Server
mindestens eine statische Route auf das VPN Netz einstellen, sonst
finden die Pakete den Rückweg nicht !!!
Wenn man es recht versteht, dann ist dein lokales Clientnetzwerk die
172.16.7.0 /24, der VPN Tunnel hat das IP Netzwerk 10.10.10.0 /24 und
das Zielnetzwerk mit dem Server ist die 192.168.1.63 /16 !!

Richtig, genau so ist es eingestellt. Statische Routen sollten nicht nötig sein, da ja das Standard Gateway (also der Router) die Pakete weiterleiten sollte. Hab es aber auch schon mit einer statischen Route versucht am Client. Funktioniert auch nicht.


Das bedeutet das der Open WRT Router das Zielnetzwerk nicht kennt,
denn er kennt ja nur das VLAN Netzwerk 10.10.10.x und sein lokales
Netzwerk. Das Zielnetzwerk befindet sich aber HINTER dem VPN Gateway
wo der OpenWRT sich einwählt.
Da er das 192.168.1.x Netzwerk nicht kennt versucht er das ins
Internet zu routen wo es als RFC 1918 Netzwerk im Nirwana verschwindet
!!!
Deshalb geht es auch nicht in den Tunnel !!
Du musst also nur schlicht und einfach dem OpenWRT eine statische
Route eingeben damit ihm der Weg ins 192.168.0.0er Zielnetz bekannt
ist ala:
ip route 192.168.0.0 Maske: 255.255.0.0, Gateway: 10.10.10.29 (oder
tun0 als Interface Name !)

Das sollte das Problem sofort lösen !

Desweiteren hilft ein Blick ins Log des Servers !!

wie gesagt, der Router kommt ja in das Zielnetzwerk, nur gibt er es nicht an die Clients weiter. Die Route ist bereits eingetragen im OpenWRT, siehe Routing Tabelle im ersten Beitrag:
01.
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
02.
10.10.10.1      10.10.10.29     255.255.255.255 UGH   0      0        0 tun0 
03.
(...) 
04.
172.16.0.0      10.10.10.29     255.255.0.0     UG    0      0        0 tun0 
05.
192.168.0.0     10.10.10.29     255.255.0.0     UG    0      0        0 tun0 
06.
 
07.
root@rtrgra:~# ping -c 2 192.168.1.63  
08.
PING 192.168.1.63 (192.168.1.63): 56 data bytes  
09.
64 bytes from 192.168.1.63: seq=0 ttl=127 time=95.944 ms  
10.
64 bytes from 192.168.1.63: seq=1 ttl=127 time=96.539 ms  
11.
 
12.
--- 192.168.1.63 ping statistics ---  
13.
 
14.
2 packets transmitted, 2 packets received, 0% packet loss  
15.
round-trip min/avg/max = 95.944/96.241/96.539 ms  
16.
root@rtrgra:~#

=> Das werd ich mir mal durchlesen. Wobei ja der Tunnel steht und ich bekomme auch eine Verbindung. Der ganze Ratten### funktioniert ja, nur das letzte Stück vom Router zum Client hat ein Problem
Bitte warten ..
Mitglied: aqui
11.03.2009 um 09:57 Uhr
An die Clients wird das ja auch logischerweise NICHT weitergegebn, denn die Clients haben ja nur den Router als default Gateway.
Der Router muss also die Information haben, das Pakete ins 192.168.0.0 /16er Netz aufs Tunnelinterface 10.10.10.29 oder tun0 geroutet werden müssen !!!
Das ist ja auch der tiefere Sinn einer VPN Routerverbindung, denn der Router hält die Routing Informationen in die VPN Netze nicht der Client !!

Das musst du mit einer statischen Route sicherstellen, das diese Pakete ins Tunnel Interface gehen.

Ganz genauso auf der anderen Seite !! Das Gateway was der Server mit der 192.168.1.63 eingetragen hat muss das 172.16.7.0 /24er Netz kennen. Auch dies muss hier bekannt gemacht werden !
Erst dann ist das Routing transparent !

Wenn der Router auf der 172.16.7.0er Seite diese Pakete ins 192.168.0.0er Netz nicht in den Tunnel routet hast du ein Problem auf dem VPN Router.
Hat der noch firewalltechnisch was aktiv was das ggf. blockt ???

Hat dein Client ggf. eine Firewall aktiv die Reply Pakets aus dem 192.168er Netz blockt ???
Das ist ja ein Fremdnetz und wenn du das in der FW nicht freigibst wird das geblockt !!
Bitte warten ..
Mitglied: wolfgang85
11.03.2009 um 14:00 Uhr
Die Verbindung über den Tunnel geht ja über das 10.10.10.0er Netz und da sind die Routen auch drinnen. Wenn eine Rückroute fehlen würd, dann bekäme ich ja vom Router auch keine Antwort wenn ich den Citrix Server anpinge.

Firewall ist abgeschaltet, da läuft auch nichts mehr.

Hier die Routingtabelle vom VPN Gateway
01.
vgateway ~ # route 
02.
Kernel IP routing table 
03.
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
04.
10.10.10.2      *               255.255.255.255 UH    0      0        0 tun0 
05.
192.168.139.1   *               255.255.255.255 UH    0      0        0 tun2 
06.
192.168.140.1   *               255.255.255.255 UH    0      0        0 tun3 
07.
192.168.138.1   *               255.255.255.255 UH    0      0        0 tun1 
08.
217.6.196.200   *               255.255.255.248 U     0      0        0 eth1 
09.
172.16.31.0     192.168.1.13    255.255.255.240 UG    1      0        0 eth2 
10.
172.16.32.0     192.168.1.13    255.255.255.240 UG    1      0        0 eth2 
11.
172.16.4.0      192.168.1.55    255.255.255.0   UG    1      0        0 eth2 
12.
192.168.20.0    192.168.140.1   255.255.255.0   UG    0      0        0 tun3 
13.
172.16.2.0      192.168.138.1   255.255.255.0   UG    0      0        0 tun1 
14.
172.16.33.0     192.168.1.13    255.255.255.0   UG    1      0        0 eth2 
15.
172.16.1.0      192.168.139.1   255.255.255.0   UG    0      0        0 tun2 
16.
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0 
17.
192.168.143.0   *               255.255.255.0   U     0      0        0 eth0 
18.
192.168.0.0     *               255.255.0.0     U     0      0        0 eth2 
19.
10.234.0.0      192.168.1.59    255.255.0.0     UG    0      0        0 eth2 
20.
loopback        *               255.0.0.0       U     0      0        0 lo 
21.
default         217.6.196.201   0.0.0.0         UG    0      0        0 eth1 
22.
vgateway ~ #
Ich denke der Hacken an der Sache liegt an der Verbindung von Router zum Client, oder nicht?
Bitte warten ..
Neuester Wissensbeitrag
Ähnliche Inhalte
Netzwerke
2 DSL-Anschluesse - 2 Router - 1 Subnet - Routing VPN (16)

Frage von beatz99 zum Thema Netzwerke ...

Switche und Hubs
gelöst VLAN fähiger VPN Router gesucht (33)

Frage von Leo-le zum Thema Switche und Hubs ...

Microsoft
AD Problem und VPN (4)

Frage von Yannosch zum Thema Microsoft ...

LAN, WAN, Wireless
gelöst VPN Router Cisco oder Andere (5)

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

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

Frage von patz223 zum Thema Windows Userverwaltung ...

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