Openvpn - Routing probleem op gateway.

[Tomsworld]

Vooreerst een mooie schematje



Zoals je ziet zijn er 2 netwerken, eentje thuis 192.168.100.0/24 en een remote 192.168.10.0/24

Ik heb de openvpn how-to gevolgd en grotendeels werkt het.

De clients van beide kanten kunnen de andere machines nbereiken.

De pc met ip 192.168.100.1 kan perfect andere aparaten pingen, 192.168.10.1 (server aan de andere kant) 192.168.10.254 (router aan de andere kant) en omgekeerd.

Het gaat maar mis als ik vanop een van de tunnelservers een ip in het andere subnet wil bereiken.

Als ik vanop tigger (192.168.100.5) de machine 192.168.10.1 wil pingen lukt dit niet.

routingtabel tigger:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.255.1   0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.10.0    192.168.255.1   255.255.255.0   UG        0 0          0 tun0
0.0.0.0         192.168.100.254 0.0.0.0         UG        0 0          0 eth0

routingtabel hera:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.255.2   0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.100.0   192.168.255.2   255.255.255.0   UG        0 0          0 tun0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         192.168.10.254  0.0.0.0         UG        0 0          0 eth0

tcpdump op hera: tcpdump -i tun0 (eerst een werkende daarna vanop tigger)

code:

tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooke
d socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:54:49.640374 IP 192.168.100.1 > adslrouter.vbsopstal.be: icmp 40: echo request seq 10240
11:54:49.641680 IP adslrouter.vbsopstal.be > 192.168.100.1: icmp 40: echo replyseq 10240
11:54:50.642666 IP 192.168.100.1 > adslrouter.vbsopstal.be: icmp 40: echo request seq 10496
11:54:50.645012 IP adslrouter.vbsopstal.be > 192.168.100.1: icmp 40: echo replyseq 10496
11:54:51.644364 IP 192.168.100.1 > adslrouter.vbsopstal.be: icmp 40: echo request seq 10752
11:54:51.646759 IP adslrouter.vbsopstal.be > 192.168.100.1: icmp 40: echo replyseq 10752
11:54:52.656124 IP 192.168.100.1 > adslrouter.vbsopstal.be: icmp 40: echo request seq 11008
11:54:52.658429 IP adslrouter.vbsopstal.be > 192.168.100.1: icmp 40: echo replyseq 11008
11:55:05.331548 IP 192.168.255.2 > adslrouter.vbsopstal.be: icmp 64: echo request seq 1
11:55:06.330666 IP 192.168.255.2 > adslrouter.vbsopstal.be: icmp 64: echo request seq 2
11:55:07.330283 IP 192.168.255.2 > adslrouter.vbsopstal.be: icmp 64: echo request seq 3
11:55:08.331059 IP 192.168.255.2 > adslrouter.vbsopstal.be: icmp 64: echo request seq 4
11:55:09.330249 IP 192.168.255.2 > adslrouter.vbsopstal.be: icmp 64: echo request seq 5

13 packets captured
13 packets received by filter
0 packets dropped by kernel

Als ik vanop een een machine ping waarop de tunnel zit gaat het mis. Het packet aan de andere zijde komt dan van het tunnelendpoint ip ipv van het werkelijke lan ip.

Wat doe ik fout ?

_{Mocht het topic hier fout staan gelieve het te moven, NT vond ik niet zo geschikt}

[ Voor 3% gewijzigd door Tomsworld op 22-02-2005 12:27 ]

[StefSybo]

Ik zie hier hetzelfde, maar dat hoeft volgens mij geen probleem te zijn, ik krijg wel antwoord van de andere kant, maar dat komt denk ik omdat het IP van de tunnel endpoint ook in mijn subnet zit. Misschien moet je de vpn endpoints gewoon in 192.168.10.0/24 en 192.168.100.0/24 pakken, dan werkt het in ieder geval. Ik denk dat het anders niet kan, omdat in de routing table nu eenmaal staat dat hij dat over tun0 moet sturen.

[Tomsworld]

StefSybo schreef op dinsdag 22 februari 2005 @ 13:29:
Ik zie hier hetzelfde, maar dat hoeft volgens mij geen probleem te zijn, ik krijg wel antwoord van de andere kant, maar dat komt denk ik omdat het IP van de tunnel endpoint ook in mijn subnet zit. Misschien moet je de vpn endpoints gewoon in 192.168.10.0/24 en 192.168.100.0/24 pakken, dan werkt het in ieder geval. Ik denk dat het anders niet kan, omdat in de routing table nu eenmaal staat dat hij dat over tun0 moet sturen.

Dat werkt idd maar hetzelfde ip op een ethernet en op een tun interface gaan binden lijkt me niet zo handig ?

En als ik dat doe, heb ik icmp problemen daarna als iemand door de andere nat router gaat.

[StefSybo]

Ik had het niet over hetzelfde IP, maar over een IP uit hetzelfde subnet

Hier heb ik ook een setup met een gateway-pc (10.2.0.1/255.255.0.0) die 10.2.254.1 en 10.2.254.2 op zijn tun-interfaces heeft, daarmee kan ik prima naar pc's aan de andere kant van de vpn connecten, maar dus wel met het adres van de tunnel endpoint als source address.

Een voorbeeldje (10.0.0.1 is de gateway aan de andere kant van de tunnel)

code:

stef@viandel stef $ ping kroket
PING kroket.bluesign.intra (10.0.0.1) 56(84) bytes of data.
64 bytes from kroket.bluesign.intra (10.0.0.1): icmp_seq=1 ttl=64 time=24.8 ms
64 bytes from kroket.bluesign.intra (10.0.0.1): icmp_seq=2 ttl=64 time=26.8 ms

En de tcpdump ervan:

code:

viandel root # tcpdump -n -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 68 bytes
13:55:07.244108 IP 10.2.254.1 > 10.0.0.1: icmp 64: echo request seq 1
13:55:07.268926 IP 10.0.0.1 > 10.2.254.1: icmp 64: echo reply seq 1
13:55:08.244132 IP 10.2.254.1 > 10.0.0.1: icmp 64: echo request seq 2
13:55:08.270934 IP 10.0.0.1 > 10.2.254.1: icmp 64: echo reply seq 2

Zoals je ziet is het pakket afkomstig van het IP van tun0, maar het werkt wel.

[ Voor 7% gewijzigd door StefSybo op 22-02-2005 14:00 ]

[Tomsworld]

Ik heb nog een beetje verder gespeeld, quagga opgezet aangezien ik toch al eens langer wou spelen met routing. Dus nu rip ipv static routing maar hetzelfde beeld.

Routes komen netjes door. Maar als je vanaf een tunnelserver pingt naar een ip op het remote net, komt het packet van het tunnelendpoint, ik snap niet waarom hij dat niet goed routeerd

Iemand nog een idee of moet ik echt uit hetzelfde subnet ips nemen

[_JGC_]

Je moet policy routing aanzetten in je kernel en zelf met ip route gaan stoeien. Wat je probleem is, is dat je source adres die meegestuurd wordt in een pakket niet je VPN adres is. Ik merk dit ook bij een VPN die ik opgezet heb tussen 2 OpenBSD boxen met ISAKMP, hierbij wil de ene kant op een of andere manier ook niet via de router het netwerk op.
Met policy routing kan je geforceerd je source address aanpassen of iig opgeven dat pakketjes niet door je default gateway moeten op eth0, maar dat ze door je VPN moeten.

[Tomsworld]

Ik heb uiteindelijk ip's uit dezelfde ranges genomen, tijdelijk icm met statische routering. Het enige probleem dat ik nu nog heb is als ik een traceroute doe naar een ip op het internet dat ik via de nat router aan de andere kant doe. Geeft mij sterretjes.

code:

P:\>tracert 195.238.0.34

Tracing route to xxx.xxxx.xx [195.238.0.xxx]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  tigger.tomsworld.local [192.168.100.5]
  2    51 ms    30 ms    30 ms  192.168.10.253
  3    31 ms    29 ms    30 ms  adslrouter.vbsopstal.be [192.168.10.254]
  4     *        *        *     Request timed out.
  5     *     ^C

Connecteren naar die machine werkt wel. Het is dus enkel het icmp antwoord voor de traceroute, dat niet komt.

Hoe los ik dit op ?

[edit]
Even op de andere kant gekeken in de tunnel

code:

11:01:44.276215 IP 192.168.100.253.33874 > news.skynet.be.33439: UDP, length: 10
11:01:44.278026 IP adslrouter.vbsopstal.be > 192.168.100.253: icmp 36: time exceeded in-transit
11:01:44.308182 IP 192.168.100.253.33874 > news.skynet.be.33440: UDP, length: 10
11:01:44.310002 IP adslrouter.vbsopstal.be > 192.168.100.253: icmp 36: time exceeded in-transit
11:01:44.387008 IP 192.168.100.253.33874 > news.skynet.be.33441: UDP, length: 10
11:01:44.399572 IP 193.241-200-80.adsl-fix.skynet.be > 192.168.100.253: icmp 36: time exceeded in-transit
11:01:49.342425 IP 192.168.100.253.33874 > news.skynet.be.33442: UDP, length: 10
11:01:49.352282 IP 193.241-200-80.adsl-fix.skynet.be > 192.168.100.253: icmp 36: time exceeded in-transit
11:01:54.340801 IP 192.168.100.253.33874 > news.skynet.be.33443: UDP, length: 10
11:01:54.352157 IP 193.241-200-80.adsl-fix.skynet.be > 192.168.100.253: icmp 36: time exceeded in-transit
11:01:59.341198 IP 192.168.100.253.33874 > news.skynet.be.33444: UDP, length: 10
11:01:59.356275 IP 192.168.255.13 > 192.168.100.253: icmp 36: time exceeded in-transit
11:02:04.340184 IP 192.168.100.253.33874 > news.skynet.be.33445: UDP, length: 10
11:02:04.528941 IP 192.168.255.13 > 192.168.100.253: icmp 36: time exceeded in-transit

[ Voor 47% gewijzigd door Tomsworld op 07-03-2005 11:02 ]