Routing problem - VPN Client not using TAP-Win32 adapter

[duffs94]

I am doing a project for a customer where I need to download and process data every hour from several remote computers.
Access to the remote computers is through a VPN using an OpenVPN client.

During development I used a local laptop running Windows 7 and everything worked fine using .ovpn and .key files supplied by the customer.
I've now decided to move the software to a dedicated server I have 'in the cloud'. It is running Windows Server 2008 R2.

I access the dedicated server using Remote Desktop. On my dedicated server, I've installed the OpenVPN client and transferred the .ovpn and .key files that worked from my development laptop.
Once I've run the OpenVPN GUI I can connect to the remote VPN and the status window seems happy and the routing table is updated. Here are the last few lines from the status window.

Code: Select all

Tue Apr 12 07:16:02 2011 us=359000 UDPv4 READ [228] from 78.40.152.40:7990:  DATA len=228
Tue Apr 12 07:16:02 2011 us=359000 Peer Connection Initiated with 78.40.152.40:7990
Tue Apr 12 07:16:05 2011 us=968000 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Tue Apr 12 07:16:05 2011 us=968000 C:\WINDOWS\system32\route.exe ADD 78.40.152.128 MASK 255.255.255.128 192.168.50.13
 OK!
Tue Apr 12 07:16:06 2011 us=46000 Initialization Sequence Completed

My problem is that I don't seem able to communicate with the remote computers. I tried pinging and telneting to ports that I know are open on them.
I then installed WireShark and found I'm getting UDP packets to 78.40.152.40:7990 sent out of my network card instead of the TAP-Win32 Adapter.

The output from 'route print' is as follows:

Code: Select all

===========================================================================
Interface List
 15...00 ff c9 f6 58 09 ......TAP-Win32 Adapter V9
 11...00 19 99 5c b0 86 ......Broadcom NetLink (TM) Gigabit Ethernet
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft 6to4 Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.255.255.1    213.165.74.98     20
     10.255.255.1  255.255.255.255     10.255.255.1    213.165.74.98     21
    78.40.152.128  255.255.255.128    192.168.50.13    192.168.50.14     31
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
    192.168.50.12  255.255.255.252         On-link     192.168.50.14    286
    192.168.50.14  255.255.255.255         On-link     192.168.50.14    286
    192.168.50.15  255.255.255.255         On-link     192.168.50.14    286
    213.165.74.98  255.255.255.255         On-link     213.165.74.98    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     213.165.74.98    276
        224.0.0.0        240.0.0.0         On-link     192.168.50.14    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     213.165.74.98    276
  255.255.255.255  255.255.255.255         On-link     192.168.50.14    286
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
     10.255.255.1  255.255.255.255     10.255.255.1       1
===========================================================================

The TAP-Win32 Adapter has IP address 192.168.50.14 and the third entry seems ok.
I've even tried specifically adding additional routes for specific IP addresses e.g.

Code: Select all

route add 78.40.152.40 mask 255.255.255.255 192.168.50.14

but this doesn't help either.

Is there something related to the fact I am doing this through a remote desktop somehow messing things up?

Here is my ipconfig as well ..

Code: Select all

Windows IP Configuration


Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::c999:1438:1c9e:2e2f%15
   IPv4 Address. . . . . . . . . . . : 192.168.50.14
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : onlinehome-server.info
   Link-local IPv6 Address . . . . . : fe80::4c0a:303d:9f19:b97d%11
   IPv4 Address. . . . . . . . . . . : 213.165.74.98
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 10.255.255.1

Tunnel adapter isatap.onlinehome-server.info:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : onlinehome-server.info

Tunnel adapter Local Area Connection* 9:

   Connection-specific DNS Suffix  . : onlinehome-server.info
   IPv6 Address. . . . . . . . . . . : 2002:d5a5:4a62::d5a5:4a62
   Default Gateway . . . . . . . . . : 2002:c058:6301::c058:6301

Tunnel adapter Local Area Connection* 12:

   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:73b8:3ca8:28e9:2a5a:b59d
   Link-local IPv6 Address . . . . . : fe80::3ca8:28e9:2a5a:b59d%14
   Default Gateway . . . . . . . . . :

Tunnel adapter isatap.{C9F65809-CE3C-4C1E-A545-3C028B536608}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Does anyone have any ideas on what I can try next? Thanks in advance.

[janjust]

where does the '10.255.255.1' route come from?
Try adding the route

Code: Select all

route add 78.40.152.40 mask 255.255.255.255 192.168.50.13

(note the GW address).

[duffs94]

Thanks for the suggestion, although it didn't fix things.
Interestingly, I had WireShark watching the TAP-Win32 interface and as soon as I ran the 'route add ...' command you suggest, I got a stream of UDP packets from my machine to the VPN server at 78.40.152.40:7990.

I was sending approx 3000 messages per second. After a minute I ran
'route delete 78.40.152.40' and the messages stopped immediately.

I don't know about the 10.255.255.1 address, it is something that is preconfigured.
The server is hosted by 1and1 in a server farm somewhere (Germany I believe) and was re-imaged a few days ago with a virgin installation of Windows 2008. Remote Desktop is enabled. I don't want to do anything that will leave me unable to communicate to it.

Another thing I've tried is changing the metric for the route. The metric for the TAP-Win32 interface was set to 'automatic' so initially any metric I specified in a 'route change/add ..' command was ignored and the route got assigned a metric greater than 20. Perhaps the 0.0.0.0 route was being favoured over the VPN?
I went into the TCP/IP settings for the TAP-Win32 interface and unchecked the 'Automatic metric' check box. I've now set the metric for this route manually.

My 'route print' now looks like this:

Code: Select all

===========================================================================
Interface List
 15...00 ff c9 f6 58 09 ......TAP-Win32 Adapter V9
 11...00 19 99 5c b0 86 ......Broadcom NetLink (TM) Gigabit Ethernet
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft 6to4 Adapter
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.255.255.1    213.165.74.98     20
     10.255.255.1  255.255.255.255     10.255.255.1    213.165.74.98     21
     78.40.152.40  255.255.255.255    192.168.50.13    192.168.50.14      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
    192.168.50.12  255.255.255.252         On-link     192.168.50.14    257
    192.168.50.14  255.255.255.255         On-link     192.168.50.14    257
    192.168.50.15  255.255.255.255         On-link     192.168.50.14    257
    213.165.74.98  255.255.255.255         On-link     213.165.74.98    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     213.165.74.98    276
        224.0.0.0        240.0.0.0         On-link     192.168.50.14    257
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     213.165.74.98    276
  255.255.255.255  255.255.255.255         On-link     192.168.50.14    257
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
     10.255.255.1  255.255.255.255     10.255.255.1       1

Like I say, in this state, I've got continuous data streaming out to 78.40.152.40 but can't actually ping it.
In fact I can't see the outgoing ICMP on either interface.

[janjust]

there are issues with running a virtualized version of win2008 with OpenVPN, but those apply mostly to the automatic startup of openvpn.

As for the udp stream working but no icmp: that can only be a firewalling issue, really ; what happens if you do a traceroute (tracert) to a host on the server side LAN? this uses UDP packets.

[duffs94]

I've logged into my remote server and ran tracert http://www.google.co.uk

I get the following

Code: Select all

PS C:\Users\Administrator> tracert www.google.co.uk

Tracing route to www.l.google.com [209.85.148.105]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.255.255.253
  2    <1 ms    <1 ms    <1 ms  vl-1995.gw-distp-a.bad.oneandone.net [195.20.247.34]
  3     1 ms     1 ms     1 ms  ae-4.bb-d.bs.kae.de.oneandone.net [212.227.122.7]
  4    24 ms     4 ms     4 ms  te-6-3.bb-d.fra3.fra.de.oneandone.net [212.227.120.30]
  5     *        *        *     Request timed out.
  6     5 ms     4 ms     4 ms  209.85.255.172
  7     7 ms    14 ms    17 ms  209.85.254.57
  8     5 ms     4 ms     4 ms  fra07s07-in-f105.1e100.net [209.85.148.105]

Trace complete.

Is it not surprising to see so much traffic on the TAP-Win32 when I set up the route?
When I had the VPN client working on my local laptop the interface was relatively quiet (the occasional Windows broadcast message) and it was very easy to see the extra packets due to me trying to connect to the remote VPN computers. I thought perhaps that all the traffic I was seeing from my dedicated server was indicating some sort of infinite loop it had got itself in to when configuring the route.

I've tried pinging 78.40.152.40 again, and this time I did catch it in Wireshark. So it appears that it is being routed correctly. It was just swamped by the other 100000 packets. The last 'route add' command you suggested must have made a difference. If it wasn't for the fact that I can connect with the VPN and communicate with no problems from my laptop I would assume there is a problem with the VPN server end.

[janjust]

this 'tracert' went via the regular network i/f ; I was interested in a 'tracert' to the server you're trying to reach (e.g. 78.40.152.40) or 78.40.152.1 .

the amount of network traffic over the tap-win32 adapter will also depend on other windows settings, such as SSDP, IPv6 configs, etc etc. What network profile is the tap-win32 adapter added ? Public or private?

[duffs94]

The tracert just times out.

Thinking about it a bit more, I've realised that adding the route is probably not the right thing to do..

The VPN server is on a public address 78.40.152.40, so my default internet gateway for 0.0.0.0 will reach it.
The subnet 78.40.152.128/25 is private and access to these addresses is though the VPN.

Using wireshark on my laptop where everything works:
If I look at the TAP-Win32 adapter I can see the traffic to each individual remote client when I ping/telnet into them. If I look at my default internet interface I can see lots of UDP traffic between my machine and 78.40.152.40:7990 while this is happening. This is obviously the 'tunnelled' data.

When I do the same thing from my dedicated server running Windows 2008. The only time I see any packets on the TAP-Win32 adapter is a bit of traffic when the VPN connection is first established. Further pings/telnets to clients in the range 78.40.152.128/25 aren't seen.
If I watch the default internet interface I see a 68 byte UDP packet every 15 seconds to 78.40.152.40:7990 which I assume is some sort of keep-alive.

[janjust]

hehe, I think we got carried away here indeed: I've never seen the server+client configs. As for not being able to ping the public IP, that is logical. The 68 byte packets sent to port 7990 are keep-alive packets sent by openvpn .

Now the main question is: what exactly are you trying to achieve here? which machines should be accessible via which route?

[duffs94]

My client has many 'monitoring devices'. scattered all over the country and for various reasons, may or may not be available at any moment in time.

They are relatively simple recorders but they each have an embedded web server through which it is possible to view a list of locally recorded files and download them.

A 3rd party has networked them and access is provided through a VPN.

The way they have implemented it, is to NAT various ports from the subnet 78.40.152.128/25 to the web servers on the physical devices. e.g. by pointing my web browser to 78.40.152.129:1234, say, I'll be able to download files from one device, 78.40.152.130:2345 might be another, etc. These mappings are static and I have a big list of them.

For me at least, it is slightly odd that the 3rd party use global IP addresses for their private lan. But that is the way it is. (Perhaps in the past they were initially public and they've only recently switched to a VPN for security? Who knows!) It should make no difference anyway.

On my laptop, I install the OpenVPN config files and this creates a tunnel to 78.40.152.40 and then defines a route so all traffic to the aforementioned range will pass through it. This works fine.

My job was to automate this process. Having established that the devices could be reached manually with a web browser, I wrote some code that ran as a service regularly polling them, keeping track of which files have been downloaded, zipping them up, emailing etc..

Having got it working, the last step was simply to transfer my code to a dedicated server - and you know the rest

[duffs94]

Finally fixed it.
It was a firewall issue.

I was aware of the web-configurable firewall provided by the 1and1 to prevent incoming packets. This is presumably associated with the router connected to my dedicated server.
I was also aware of the 'Windows Firewall with Advanced Security' which was turned off for all (Domain, Private and Public) profiles.

I've now learnt there are some more firewall settings in 'IP Security Policies on Local Computer' as part of the 'Local Security Policy'. I've been playing with some of them and lo, my OpenVPN works now!

Thanks for your help anyway.