[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Problem with multiple push "route..."


  • Subject: Re: [Openvpn-users] Problem with multiple push "route..."
  • From: Erich Titl <erich.titl@xxxxxxxx>
  • Date: Mon, 18 Sep 2006 19:25:45 +0200

Thomas Heidemann wrote:
> Hi Erich,
> sorry for not posting such a long time but I was out over the weekend.
> Lets get's back to my problem....
> 
> In 2.0 it must be tcp-server or tcp-client. tcp alone is not sufficient.
> lport defined the local porto which openvpn has to bind to. I didn't specify the remote port (of the client) becausethe server does not know, from where the connection comes. Also some http proxies might use other ports.
> 
> Here are some tcpdumps which show my problem after connection initialisation while I pinged the server (10.8.0.1):
> 
> Server (eth0):
> 18:24:37.108929 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 0
> 18:24:37.109462 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 52
> 18:24:37.175273 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
> 18:24:37.175375 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 350
> 18:24:37.201236 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
> 18:24:39.316469 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144 <-- Connection initialised here!
> 18:24:39.552296 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
...

This is weird, all this seems to indicate traffic _from_ the server to
the client.

> 
> Server (tun0):
> - nothing -

> 
> Client (eth1):
> 18:24:37.103850 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 134
> 18:24:37.137511 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
> 18:24:37.138007 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 52
> 18:24:37.177338 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
> 18:24:37.205175 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 350
> 18:24:37.205299 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
> 18:24:39.344744 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144 <-- Connection initialised here!
> 18:24:39.580828 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
...

> 
> Client (tun0):
> 18:24:38.101454 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52

This is completely wild. Why does the client send traffic to
145.253.90.49 through the tunnel. We should only see. traffic in the
10.8.0.0/24 range pass through the tunnel. The client should _not_ use
its _real_ address to access the server. This is not normal OpenVPN traffic.

> 18:24:39.045491 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
> 18:24:40.933656 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52

Now here this is more reasonable ...
> 18:24:43.156217 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 1, length 64
> 18:24:44.165874 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 2, length 64

> 18:24:44.709906 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52

It appears that in your case tunnel traffic _and_ tunneled traffic is
interspersed

> 18:24:45.167015 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 3, length 64
> 18:24:46.166043 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 4, length 64
...

> 
> Both clocks (server and client) are in sync!
> 
> Routing table of client after initialisation:
> Kernel IP Routentabelle
> Ziel            Router          Genmask         Flags Metric Ref    Use Iface
> 10.8.0.1        10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
> 10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
> 145.253.90.32   10.8.0.9        255.255.255.224 UG    0      0        0 tun0

And here is the reason why....

The route to 145.253.90.32/27 covers/hides the server address
145.253.90.49. Your routing is flawed.

> 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
> 192.168.11.0    10.8.0.9        255.255.255.0   UG    0      0        0 tun0
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         192.168.1.10    0.0.0.0         UG    0      0        0 eth1
> 
> So the routes are correct I think.

I don't think so.

cheers

Erich

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-------------------------------------------------------------------------
Get stuff done quickly with pre-integrated technology to make your job easier
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users