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

RE: [Openvpn-users] Re: Weird problem with Open VPN... TAP only sends, doesn't receive.


  • Subject: RE: [Openvpn-users] Re: Weird problem with Open VPN... TAP only sends, doesn't receive.
  • From: Charles Duffy <cduffy@xxxxxxxxxxx>
  • Date: Sat, 15 Jan 2005 17:54:15 -0600

I hope you don't mind me CC'ing this to the list -- I don't give private
support for free [not that I have time to offer paid support presently,
either -- if you want that, talk to James].

On Sat, 2005-01-15 at 17:04 -0600, William Sellers wrote:
> I'm not sure exactly what I'm supposed to be looking for in this show-net.
> I'm not too familiar with the routes.

I'm not entirely fluent with Windows networking myself (being a Unix
sorta guy), but I'll give this a shot and try to include enough
commentary that you can do this kind of analysis yourself in the future.

> TAP-Win32 Adapter V8
>   Index = 65541
>   GUID = {F5B613AE-489D-4281-A674-B63B07CBDDF6}
>   IP = 192.168.0.121/255.255.255.0 
>   MAC = 00:ff:f5:b6:13:ae
>   GATEWAY = 192.168.0.1/0.0.0.0 

Your tap adapter is on 192.168.0.121/24, with a gateway of 192.168.0.1.
This implies that traffic going to 192.168.0.0 needs to go through the
VPN. Note that the index of the adapter is 65541. Sooo, any routes with
i=65541 are indicating that they tell traffic to go through the VPN.

> Linksys LNE100TX Fast Ethernet Adapter(LNE100TX v4)
>   Index = 65540
>   GUID = {A0549AD9-6556-41AF-8C99-1937D19C408E}
>   IP = 10.2.4.27/255.255.0.0 
>   MAC = 00:04:5a:74:e4:99
>   GATEWAY =  
>   DHCP SERV = 10.2.2.2 
>   DHCP LEASE OBTAINED = Sat Jan 15 16:21:22 2005
>   DHCP LEASE EXPIRES  = Tue Jan 18 16:21:22 2005

Your physical Ethernet adapter (that's actually being used) is this
Linksys. Your IP is 10.2.4.27, and your local network spans all o
10.2.*.



Now we get into the meat of the thing: When a packet tries to leave your
machine, where does it go through?


> 0.0.0.0 0.0.0.0 192.168.0.1 p=0 i=65541 t=4 pr=3 a=2288 h=0 m=1/-1/-1/-1/-1
  ^       ^       ^               ^
  |       |       |               \- interface index
  |       |       \- gateway
  |       \- netmask
  \- network

So: If the remote address matches the network on all netmask bits that
are high, then it gets routed with the given interface and gateway.

The above entry is setting your default route (the route to
0.0.0.0/0.0.0.0) to go through 192.168.0.1, interface 65541 (the VPN). I
presume you're using redirect-gateway, or this wouldn't be there.

> 10.2.0.0 255.255.0.0 10.2.4.27 p=0 i=65540 t=3 pr=2 a=24633 h=0 m=20/-1/-1/-1/-1

This is stating that traffic to 10.2.0.0/16 (that is, all traffic with
destination addresses that start with 10.2) is to be routed through
interface 65540 (the index of your physical Ethernet adapter).

> 10.2.4.27 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=24633 h=0 m=20/-1/-1/-1/-1

This is stating that traffic going to 10.2.4.27 (yourself) is to go
through the loopback interface (interface 1), which leads directly back
to your own machine.

> 10.255.255.255 255.255.255.255 10.2.4.27 p=0 i=65540 t=3 pr=2 a=24633 h=0 m=20/-1/-1/-1/-1

This is stating that traffic to the 10.* broadcast network goes out on
the physical ethernet adapter.

> A.B.C.D 255.255.255.255 10.2.1.1 p=0 i=65540 t=4 pr=3 a=2288 h=0 m=1/-1/-1/-1/-1

This is stating that traffic to A.B.C.D (obscured since it's a public IP
and I'm CC'ing this to the list) goes through your physical ethernet
adapter, accessed via the gateway 10.2.1.1. I'm guessing that this is
the OpenVPN server you're connecting to?

> 127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=24673 h=0 m=1/-1/-1/-1/-1

Local network.

> 192.168.0.0 255.255.255.0 192.168.0.121 p=0 i=65541 t=3 pr=2 a=2298 h=0 m=30/-1/-1/-1/-1

Connections to 192.168.0.0 go through the VPN.

> 192.168.0.121 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2298 h=0 m=30/-1/-1/-1/-1

Connections to 192.168.0.121 (your own IP address on the VPN) go through
the local interface.

> 192.168.0.255 255.255.255.255 192.168.0.121 p=0 i=65541 t=3 pr=2 a=2298 h=0 m=30/-1/-1/-1/-1

Connections to the broadcast address on the VPN go through the VPN.

> 224.0.0.0 240.0.0.0 10.2.4.27 p=0 i=65540 t=3 pr=2 a=24633 h=0 m=20/-1/-1/-1/-1
> 224.0.0.0 240.0.0.0 192.168.0.121 p=0 i=65541 t=3 pr=2 a=2298 h=0 m=30/-1/-1/-1/-1

These are class D (multicast) entries. Shouldn't be relevant.

> 255.255.255.255 255.255.255.255 10.2.4.27 p=0 i=65540 t=3 pr=2 a=24633 h=0 m=1/-1/-1/-1/-1
> 255.255.255.255 255.255.255.255 192.168.0.121 p=0 i=65541 t=3 pr=2 a=24191 h=0 m=1/-1/-1/-1/-1
> 255.255.255.255 255.255.255.255 192.168.0.121 p=0 i=65539 t=3 pr=2 a=24638 h=0 m=1/-1/-1/-1/-1

Damned if I know what these are.


When you're evaluating a routing table to for correctness (in the
context of OpenVPN), you want to look for the following things:

- Can packets trying to get to the VPN server find it?
  This is normally a non-issue, but using redirect-gateway means that a
route needs to be added such that packets going to the VPN server don't
try to go through the default gateway (which would cause them to loop
through the VPN rather than actually going out on ethernet). This route
is above, as:

  A.B.C.D 255.255.255.255 10.2.1.1 p=0 i=65540 t=4 pr=3 a=2288 h=0 m=1/-1/-1/-1/-1

- Can packets trying to get to the far side of the VPN get there?
  There needs to be a route saying that packets going to the network on
the far side of the VPN actually get routed to that network. Not only is
the default gateway set to ensure this, but there's also an explicit
route:

  192.168.0.0 255.255.255.0 192.168.0.121 p=0 i=65541 t=3 pr=2 a=2298 h=0 m=30/-1/-1/-1/-1


So, this routing table is fine.

Now, go check the routing table on the *other* side of the VPN, and make
sure it says to send packets going to your system (192.168.0.121)
through the VPN adapter. If that works, you'll also want to check that
the system that you're pinging on the other side knows to send packets
going to 192.168.0.121 over to the VPN server. (This is not infrequently
accomplished by having the VPN server be the default gateway, or having
the default gateway be a system which in turn routes packets going to
the VPN over to the VPN server).



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users