4
Problem Routing über VPN Router
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
Hier meine OpenVPN Config:
Hier die Einstellungen des Windows Rechners:
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
… und anschließend noch die Netzwerkkonfiguration
Die Firewall hab ich mittels „/etc/init.d/firewall stop“ angehalten, hier noch die laufenden Prozesse
Gruß,
Wolfgang
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
root@rtrgra:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.1 10.10.10.29 255.255.255.255 UGH 0 0 0 tun0
217.0.116.91 * 255.255.255.255 UH 0 0 0 ppp0
10.10.10.29 * 255.255.255.255 UH 0 0 0 tun0
172.16.7.0 * 255.255.255.0 U 0 0 0 br-lan
172.16.0.0 10.10.10.29 255.255.0.0 UG 0 0 0 tun0
192.168.0.0 10.10.10.29 255.255.0.0 UG 0 0 0 tun0
default 217.0.116.91 0.0.0.0 UG 0 0 0 ppp0
root@rtrgra:~# ping -c 2 192.168.1.63
PING 192.168.1.63 (192.168.1.63): 56 data bytes
64 bytes from 192.168.1.63: seq=0 ttl=127 time=95.944 ms
64 bytes from 192.168.1.63: seq=1 ttl=127 time=96.539 ms
--- 192.168.1.63 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 95.944/96.241/96.539 ms
root@rtrgra:~#Hier meine OpenVPN Config:
root@rtrgra:~# cat /etc/config/openvpn
remote <<IP Adresse>>
client
dev tun
key /etc/openvpn/AWG-wolfhu/wolfhu.key
tls-auth /etc/openvpn/AWG-wolfhu/psk.key 1
dh /etc/openvpn/AWG-wolfhu/dh2048.pem
ca /etc/openvpn/AWG-wolfhu/ca.crt
cert /etc/openvpn/AWG-wolfhu/wolfhu.crt
nobind
keepalive 10 60
comp-lzo
persist-key
persist-tun
verb 3
root@rtrgra:~#Hier die Einstellungen des Windows Rechners:
C:\>tracert 192.168.1.63
Routenverfolgung zu 192.168.1.63 über maximal 30 Abschnitte
1 1 ms <1 ms <1 ms 172.16.7.1
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 ^C
C:\>ipconfig
Windows-IP-Konfiguration
Ethernetadapter WLAN:
Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
Ethernetadapter LAN:
Verbindungsspezifisches DNS-Suffix: awg
IP-Adresse. . . . . . . . . . . . : 172.16.7.197
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 172.16.7.1
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
root@rtrgra:~# ifconfig
br-lan Link encap:Ethernet HWaddr 00:22:6B:8D:DC:C0
inet addr:172.16.7.1 Bcast:172.16.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15634 errors:0 dropped:0 overruns:0 frame:0
TX packets:12503 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1072239 (1.0 MiB) TX bytes:1367174 (1.3 MiB)
eth0 Link encap:Ethernet HWaddr 00:22:6B:8D:DC:C0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20201 errors:0 dropped:0 overruns:0 frame:0
TX packets:17580 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1993796 (1.9 MiB) TX bytes:1934339 (1.8 MiB)
Interrupt:4
eth0.0 Link encap:Ethernet HWaddr 00:22:6B:8D:DC:C0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15634 errors:0 dropped:0 overruns:0 frame:0
TX packets:12503 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1134775 (1.0 MiB) TX bytes:1417186 (1.3 MiB)
eth0.1 Link encap:Ethernet HWaddr 00:22:6B:8D:DC:C0
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:4572 errors:0 dropped:0 overruns:0 frame:0
TX packets:5080 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:495981 (484.3 KiB) TX bytes:375611 (366.8 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:36 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3203 (3.1 KiB) TX bytes:3203 (3.1 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:84.146.130.183 P-t-P:217.0.116.91 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:1982 errors:0 dropped:0 overruns:0 frame:0
TX packets:2489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:342625 (334.5 KiB) TX bytes:222714 (217.4 KiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.10.10.30 P-t-P:10.10.10.29 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@rtrgra:~#… und anschließend noch die Netzwerkkonfiguration
root@rtrgra:~# cat /etc/config/network
config 'switch' 'eth0'
option 'vlan0' '0 1 2 3 5*'
option 'vlan1' '4 5'
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'lan'
option 'type' 'bridge'
option 'ifname' 'eth0.0'
option 'proto' 'static'
option 'macaddr' ''
option 'ip6addr' ''
option 'gateway' ''
option 'ip6gw' ''
option 'dns' ''
option 'ipaddr' '172.16.7.1'
option 'netmask' '255.255.255.0'
config 'interface' 'wan'
option 'ifname' 'eth0.1'
option 'proto' 'pppoe'
option 'macaddr' ''
option 'username' 't-online-com/<<Benutzername>>@t-online-com.de'
option 'password' '<<Passwort>>'
option 'vpi' ''
option 'vci' ''
option 'defaultroute' '1'
option 'ppp_redial' 'persist'
option 'ip6addr' ''
option 'netmask' ''
option 'ip6gw' ''
option 'dns' ''
option 'mtu' '1492'
option 'keepalive' '2'
root@rtrgra:~# ping www.heise.de
PING www.heise.de (193.99.144.85): 56 data bytes
64 bytes from 193.99.144.85: seq=0 ttl=250 time=81.243 ms
64 bytes from 193.99.144.85: seq=1 ttl=250 time=76.291 ms
^C
--- www.heise.de ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 76.291/78.767/81.243 ms
root@rtrgra:~#Die Firewall hab ich mittels „/etc/init.d/firewall stop“ angehalten, hier noch die laufenden Prozesse
root@rtrgra:~# /etc/init.d/firewall stop
root@rtrgra:~# ps -uax
PID USER VSZ STAT COMMAND
1 root 1968 S init
2 root 0 SW< [kthreadd]
3 root 0 SW< [ksoftirqd/0]
4 root 0 SW< [events/0]
5 root 0 SW< [khelper]
19 root 0 SW< [kblockd/0]
50 root 0 SW [pdflush]
51 root 0 SW [pdflush]
52 root 0 SW< [kswapd0]
53 root 0 SW< [aio/0]
65 root 0 SW< [mtdblockd]
235 root 0 SWN [jffs2_gcd_mtd3]
247 root 1968 S logger -s -p 6 -t
248 root 1968 S init
257 root 1980 S /sbin/syslogd -C16 -S
259 root 1964 S /sbin/klogd
269 root 1980 S syslogd -C16
271 root 1960 S klogd
283 root 1136 S /sbin/hotplug2 --override --persistent --max-children
438 root 0 SW< [b43]
488 root 2560 S /usr/sbin/pppd plugin rp-pppoe.so mtu 1492 mru 1492 n
705 root 0 SW< [ipolldevd]
738 root 1808 S hostapd -P /var/run/wifi-wlan0.pid -B /var/run/hostap
746 root 1972 S crond -c /etc/crontabs
751 root 1940 S /usr/sbin/dropbear -p 22
756 root 1968 S /usr/sbin/httpd -p 80 -h /www -r rtrgra
777 nobody 1280 S /usr/sbin/dnsmasq -K -D -y -Z -b -E -s awg -S /awg/ -
1144 root 5120 S /usr/sbin/openvpn --config /etc/config/openvpn
1197 root 1996 S /usr/sbin/dropbear -p 22
1198 root 1980 S -ash
1226 root 1968 R ps -uax
root@rtrgra:~#Gruß,
Wolfgang
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: 111031
Url: https://administrator.de/contentid/111031
Ausgedruckt am: 06.11.2024 um 03:11 Uhr
4 Kommentare
Neuester Kommentar
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:
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:
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 !!!
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 !!
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 !!
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:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.1 10.10.10.29 255.255.255.255 UGH 0 0 0 tun0
(...)
172.16.0.0 10.10.10.29 255.255.0.0 UG 0 0 0 tun0
192.168.0.0 10.10.10.29 255.255.0.0 UG 0 0 0 tun0
root@rtrgra:~# ping -c 2 192.168.1.63
PING 192.168.1.63 (192.168.1.63): 56 data bytes
64 bytes from 192.168.1.63: seq=0 ttl=127 time=95.944 ms
64 bytes from 192.168.1.63: seq=1 ttl=127 time=96.539 ms
--- 192.168.1.63 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 95.944/96.241/96.539 ms
root@rtrgra:~#Weitere Anregungen findest du auch hier:
=> Das werd ich mir mal durchlesen. Wobei ja der Tunnel steht und ich bekomme auch eine Verbindung. Der ganze Rattenschwanz funktioniert ja, nur das letzte Stück vom Router zum Client hat ein Problem
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 !!
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 !!
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
Ich denke der Hacken an der Sache liegt an der Verbindung von Router zum Client, oder nicht?
Firewall ist abgeschaltet, da läuft auch nichts mehr.
Hier die Routingtabelle vom VPN Gateway
vgateway ~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.139.1 * 255.255.255.255 UH 0 0 0 tun2
192.168.140.1 * 255.255.255.255 UH 0 0 0 tun3
192.168.138.1 * 255.255.255.255 UH 0 0 0 tun1
217.6.196.200 * 255.255.255.248 U 0 0 0 eth1
172.16.31.0 192.168.1.13 255.255.255.240 UG 1 0 0 eth2
172.16.32.0 192.168.1.13 255.255.255.240 UG 1 0 0 eth2
172.16.4.0 192.168.1.55 255.255.255.0 UG 1 0 0 eth2
192.168.20.0 192.168.140.1 255.255.255.0 UG 0 0 0 tun3
172.16.2.0 192.168.138.1 255.255.255.0 UG 0 0 0 tun1
172.16.33.0 192.168.1.13 255.255.255.0 UG 1 0 0 eth2
172.16.1.0 192.168.139.1 255.255.255.0 UG 0 0 0 tun2
10.10.10.0 10.10.10.2 255.255.255.0 UG 0 0 0 tun0
192.168.143.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.0 * 255.255.0.0 U 0 0 0 eth2
10.234.0.0 192.168.1.59 255.255.0.0 UG 0 0 0 eth2
loopback * 255.0.0.0 U 0 0 0 lo
default 217.6.196.201 0.0.0.0 UG 0 0 0 eth1
vgateway ~ #Ich denke der Hacken an der Sache liegt an der Verbindung von Router zum Client, oder nicht?
