3

I have an OpenVPN client on a Windows 7, that connects to an OpenVPN server with tap.
The tunnel establishes correctly.
AFAIK, tap means that my virtual adapter is 'virtually' connected to the remote LAN, gets a remote LAN ip and participate in the LAN broadcast domani and so on.
When the tunnel is established, my virtual adapter gets the correct IP.
But I cannot ping the other hosts in the remote network.
It might be a problem on the sererver side, but before checking there i've noticed something strange on the client side, in the way Windows handles the virtual interface.
Let's begin.
When the tunnel is up, the virtual interface is up too. In my routing table i can see my phisical network 192.168.2.0, infact my local IP is 192.168.2.134.
Then I can see the remote network 172.16.1.0, directly attached to my interface 172.16.1.40. So far so good. (i've removed loopback entries)

          0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.134     25
       172.16.1.0    255.255.255.0         On-link       172.16.1.40    276
      172.16.1.40  255.255.255.255         On-link       172.16.1.40    276
     172.16.1.255  255.255.255.255         On-link       172.16.1.40    276
      192.168.2.0    255.255.255.0         On-link     192.168.2.134    281
    192.168.2.134  255.255.255.255         On-link     192.168.2.134    281
    192.168.2.255  255.255.255.255         On-link     192.168.2.134    281
        224.0.0.0        240.0.0.0         On-link       172.16.1.40    276
        224.0.0.0        240.0.0.0         On-link     192.168.2.134    281
  255.255.255.255  255.255.255.255         On-link       172.16.1.40    276
  255.255.255.255  255.255.255.255         On-link     192.168.2.134    281

Thus, clients on the remote network shouldn't be reached via gateway, but through direct routing via the virtual interface provided by openvpn.
But when i trace the route to an host on the remote network (that my PC should see as local) my client routes it on the gateway, and obviously, get lost.

C:\Users\agostinox>tracert 172.16.1.17
  1     1 ms     1 ms     1 ms  192.168.2.1
  2    14 ms    96 ms   101 ms  192.168.1.1
  3     *        *        *     Richiesta scaduta.
  4    24 ms    12 ms    12 ms  172.17.129.137
  5     *        *        *     Richiesta scaduta.

And here it seems that the system routes packages straight to the gateway as it didn't see the directly attached network adapter. Why does this happen?

Edit 1 - details on my OpenVPN client config

C:\Users\agostinox>openvpn --version
OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 19 2015
library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08

And my client config:

remote xxx.xxx.xxx.xxx
cipher AES-128-CBC
port 1194
proto tcp-client
dev tap
ifconfig 172.16.1.40 255.255.255.0
dev-node "Connessione alla rete locale (LAN) 3"
secret a_file_containing_my_preshared_key.key
ping 10
comp-lzo
verb 4
mute 10

Edit 2, details on my server configuration

Here is the "backup" of my (pfsense) server configuration.
As you can see the configuration is at the minimum possible.

<openvpn>
  <openvpn-server>
  <vpnid>2</vpnid> 
  <mode>p2p_shared_key</mode> 
  <protocol>TCP</protocol> 
  <dev_mode>tap</dev_mode> 
  <ipaddr /> 
  <interface>wan</interface> 
  <local_port>1194</local_port> 
  <description><![CDATA[ test tap OpenVPN server]]> 
  </description>
  <custom_options /> 
  <shared_key>... my shared key, omitted ...</shared_key> 
  <crypto>AES-128-CBC</crypto> 
  <engine>none</engine> 
  <tunnel_network /> 
  <tunnel_networkv6 /> 
  <remote_network /> 
  <remote_networkv6 /> 
  <gwredir /> 
  <local_network /> 
  <local_networkv6 /> 
  <maxclients /> 
  <compression>yes</compression> 
  <passtos /> 
  <client2client /> 
  <dynamic_ip /> 
  <pool_enable>yes</pool_enable> 
  <topology_subnet /> 
  <serverbridge_dhcp /> 
  <serverbridge_interface /> 
  <serverbridge_dhcp_start /> 
  <serverbridge_dhcp_end /> 
  <netbios_enable /> 
  <netbios_ntype>0</netbios_ntype> 
  <netbios_scope /> 
  </openvpn-server>
</openvpn>

Edit 3, output of ipconfig /all

When the tunnel is up, this is the output of

ipconfig /all
Scheda Ethernet TAP-Interface:

   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Indirizzo fisico. . . . . . . . . . . : 00-FF-7B-FB-32-C0
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : fe80::3838:3c0c:c3c6:fcca%35(Preferenziale)
   Indirizzo IPv4. . . . . . . . . . . . : 172.16.1.40(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease ottenuto. . . . . . . . . . . . : giovedì 16 aprile 2015 09:57:32
   Scadenza lease . . . . . . . . . . .  : venerdì 15 aprile 2016 09:57:32
   Gateway predefinito . . . . . . . . . : fe80::20c:29ff:fe92:2272%35
   Server DHCP . . . . . . . . . . . . . : 172.16.1.0
   IAID DHCPv6 . . . . . . . . . . . : 1107361659
   DUID Client DHCPv6. . . . . . . . : 00-01-00-01-14-AE-89-EA-F0-4D-A2-63-11-97
   Server DNS . . . . . . . . . . . . .  : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
   NetBIOS su TCP/IP . . . . . . . . . . : Attivato
14
  • 2
    Did you start OpenVPN with administrator privileges?
    – shodanshok
    Apr 12, 2015 at 11:26
  • 1
    Yes, I've used a user that has full privileges on the machine.
    – AgostinoX
    Apr 12, 2015 at 15:10
  • 1
    Could we see the server config?
    – Lenniey
    Apr 14, 2015 at 12:58
  • 1
    @Lenniey, i've updated the question adding the server configuration. it's the pfsense backup format and should be readable enough, hope it's fine.
    – AgostinoX
    Apr 14, 2015 at 13:38
  • 2
    "I've used a user that has full privileges on the machine." is not enough if UAC is active, you have to run the client with "Run as administrator" so it can add routes to the system routing table.
    – Brian
    Apr 15, 2015 at 13:56

3 Answers 3

1

Locate the OpenVPNgui.exe, openvpn.exe and openvpnserver.exe files in the bin folder of your open vpn install. Right-click the executables, select properties and then the compatibility tab. Click the "Run this program as an administrator" check box, and close the properties panel. Completely close out of OpenVPN (use task manager to confirm none of the executables are still running). Launch OpenVPN again and give it another try.

1
  • Nice solution. On modern versions of Windows, adding static routes requires admin privileges. Mar 26, 2018 at 15:32
1

Not being too Windows savvy wrt. OpenVPN, FWIW, here is my bid on what the culprit might be here:

  • Looking at the output from your Windows route command, it seems you are missing a gateway entry for the OpenVPN network. True, you have an address on the VPN net (the 172.16.1.40 address), but no gw is defined for that net. On my box, I have access to several networks, each with its own GW like so:

     0.0.0.0          0.0.0.0      172.20.68.2      172.20.69.3     20
    10.0.3.0    255.255.255.0      172.20.68.5      172.20.69.3     21
    

To fix this, open your openvpn server config and add a line like this:

 push "route 172.16.1.0 255.255.255.0"

to it. This ensures that a proper route is pushed to the client whenever the connection to the server is up.

  • You may also be missing the return route - sometimes (not always for reasons I don't quite get) you need to add an iroute to the config entry you have for a given client in the server ccd directory (/etc/openvpn/ccd/<vpn>/<client-id>). This brings up the reverse route when a client connects to the server. the contents of one of my ccd files looks like this:

    iroute 192.168.87.0 255.255.255.0
    

This ensures the OpenVPN server can correctly route stuff back to the client

  • I think you can also just add iroutes to the main server config, but then they will be defined even if the client is not connected. That would look like this:

    route 192.168.87.0 255.255.255.0 192.168.11.1
    
  • EDIT: Also note that running OpenVPN clients on Windows requires administrative privileges. Otherwise, OpenVPN will not be able to add routes and such (as noted in the comments to your question). Best thing is to run it as a service so connections come up automatically on boot. At least, that works out really well in my scenarios.

I think that might get you going again. OpenVPN is really great and I have used it successfully for both business and gaming purposes for some time now :-)

6
  • 1
    But does all this reasoning on routes apply to tap, that is non-routed vpn too?
    – AgostinoX
    Apr 16, 2015 at 20:26
  • 1
    Hmm - I may have jumped the gun on this. I have only used tun for my stuff, but I would imagine the routing stuff is still needed. How else would the OpenVPN server know about how to direct traffic back to clients? Also, since you have two networks in play (not just a bridge between two halves of one network), it seems routing is a must in any case. Have a look at this page on OpenVPN routing.
    – MrMajestyk
    Apr 17, 2015 at 6:19
  • 1
    I have two networks but the situation is more like a multihomed host (and big chances are that THIS is where problems come from) than a routed network. From the routing point of view, i should have a directly connected network. The local and remote interfaces will be bridged. The remote network will see my client as reachable via level 2 frames in the local network.
    – AgostinoX
    Apr 17, 2015 at 7:13
  • 1
    I still think you will have to do some routing to get this running - think of it from the server (B) side. Let's say your client machine (A) sends a request to some machine (C) on the remote network beyond B - how will C be able to send responses back to A unless B has published a route to A?
    – MrMajestyk
    Apr 17, 2015 at 7:18
  • 1
    C would use 'direct routing'. My address 172.16.1.40 is an address on the remote network (172.16.1.0/24). The point is that machines on the remote network won't reach my pc passing trought a gateway, but talking with the interface of the VPN server "as it was" my pc, because of the bridge. That's how tap should work, it's all about not setting routes on remote machines.
    – AgostinoX
    Apr 17, 2015 at 7:48
0

I have a feeling you are not pushing your routes correctly from the server. I noticed that your gateway for the VPN is an IPv6 address.

Try using the push option in server.conf to push your routes. You might also want to add the server directive so you can reserve the client subnet.

If you're on linux you will need to have net.ipv4.ip_forward = 1 on the VPN server set up with sysctl as well.

Best,

-Iulian

1
  • This in the case of TAP too? I'm not 'routing' to the remote network. I 'AM' in the remote network. My local virtual interface should be bridged to the remote vpn server interface, and all level 2 traffic would be forwarded with no routing activity, AFAIK.
    – AgostinoX
    Apr 17, 2015 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .