Configure to reach server IP address in client-to-client

mikejansen

I have my OpenVPN server set up for client-to-client which is working well for our current needs. However, I am moving the OpenVPN to another server which will be remote (I currently have physical access to the "server") and so I will need to Remote Desktop into the server. My concern is that I can't currently remote desktop to my OpenVPN server via the VPN. So I'm trying to figure out if I have configured something incorrectly.

The server is Windows based and here is the server config. I would think that via the VPN I should be able to hit 10.8.0.1 and get to the server, but it doesn't work. And on Windows, I see no network adapter where the RDP service could bind to so that it would be accessible via OpenVPN.

To summarize my problem: Via the VPN on a client, I cannot connect to the VPN server via 10.8.0.1 which is what I believed was supposed to be the server IP address on the VPN.

Thanks,
Mike

Server Config

port port
proto udp
dev tun
ca "ca file"
cert "cert file"
key "key file"
dh "dh file"

server 10.8.0.0 255.255.255.0
route 10.8.0.0 255.255.255.0

client-config-dir "ccd dir"

client-to-client

keepalive 10 120
tls-auth "ta key"

comp-lzo

max-clients 10
persist-key
persist-tun

status "status file"

log "log file"
verb 3
mute 10

mikejansen

And here is the client config (also Windows OS):

client
dev tun
proto udp
remote server port

resolv-retry infinite
nobind
persist-key
persist-tun

mute-replay-warnings

ca "ca file"
cert "cert file"
key "key file"

ns-cert-type server
tls-auth "ta key" 1

comp-lzo
verb 3
mute 10

mikejansen

I have also tried pinging 10.8.0.6, which is what the client sees as the DHCP server; no response.

And here is the applicable part of the routing table on the client after connecting to the VPN:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.47      2
         10.8.0.0    255.255.255.0         10.8.0.6         10.8.0.5     30
         10.8.0.4  255.255.255.252         On-link          10.8.0.5    286
         10.8.0.5  255.255.255.255         On-link          10.8.0.5    286
         10.8.0.7  255.255.255.255         On-link          10.8.0.5    286

And the client log during connection:

Thu Mar 14 12:09:13 2013 OpenVPN 2.2.1 Win32-MSVC++ [SSL] [LZO2] built on Jul  1 2011
Thu Mar 14 12:09:13 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Mar 14 12:09:13 2013 Control Channel Authentication: using 'XXXXXXXXXXXXXXXXXXXXX' as a OpenVPN static key file
Thu Mar 14 12:09:13 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Mar 14 12:09:13 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Mar 14 12:09:13 2013 LZO compression initialized
Thu Mar 14 12:09:13 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Mar 14 12:09:13 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Mar 14 12:09:13 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Mar 14 12:09:13 2013 Local Options hash (VER=V4): '504e774e'
Thu Mar 14 12:09:13 2013 Expected Remote Options hash (VER=V4): '14168603'
Thu Mar 14 12:09:13 2013 UDPv4 link local: [undef]
Thu Mar 14 12:09:13 2013 UDPv4 link remote: XXXXXXXXXXXXXXXXXXXXX
Thu Mar 14 12:09:13 2013 TLS: Initial packet from XXXXXXXXXXXXXXXXXXXXX, sid=afcf3f83 d0c9060b
Thu Mar 14 12:09:13 2013 VERIFY OK: depth=1, /C=US/ST=OH/XXXXXXXXXXXXXXXXXXXXX
Thu Mar 14 12:09:13 2013 VERIFY OK: nsCertType=SERVER
Thu Mar 14 12:09:13 2013 VERIFY OK: depth=0, /C=US/ST=OH/XXXXXXXXXXXXXXXXXXXXX
Thu Mar 14 12:09:14 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Mar 14 12:09:14 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Mar 14 12:09:14 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Mar 14 12:09:14 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Mar 14 12:09:14 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Mar 14 12:09:14 2013 [CROWLAP1] Peer Connection Initiated with XXXXXXXXXXXXXXXXXXXXX
Thu Mar 14 12:09:16 2013 SENT CONTROL [CROWLAP1]: 'PUSH_REQUEST' (status=1)
Thu Mar 14 12:09:16 2013 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.5 10.8.0.6'
Thu Mar 14 12:09:16 2013 OPTIONS IMPORT: timers and/or timeouts modified
Thu Mar 14 12:09:16 2013 OPTIONS IMPORT: --ifconfig/up options modified
Thu Mar 14 12:09:16 2013 OPTIONS IMPORT: route options modified
Thu Mar 14 12:09:16 2013 ROUTE default_gateway=192.168.1.1
Thu Mar 14 12:09:16 2013 TAP-WIN32 device [ShrewVPN] opened: \\.\Global\{C641B4B2-66A7-4D0F-AC5B-8A559CA399CC}.tap
Thu Mar 14 12:09:16 2013 TAP-Win32 Driver Version 9.8
Thu Mar 14 12:09:16 2013 TAP-Win32 MTU=1500
Thu Mar 14 12:09:16 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.5/255.255.255.252 on interface {C641B4B2-66A7-4D0F-AC5B-8A559CA399CC} [DHCP-serv: 10.8.0.6, lease-time: 31536000]
Thu Mar 14 12:09:16 2013 Successful ARP Flush on interface [15] {C641B4B2-66A7-4D0F-AC5B-8A559CA399CC}
Thu Mar 14 12:09:21 2013 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Thu Mar 14 12:09:21 2013 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.6
Thu Mar 14 12:09:21 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu Mar 14 12:09:21 2013 Route addition via IPAPI succeeded [adaptive]
Thu Mar 14 12:09:21 2013 Initialization Sequence Completed

And the client IPCONFIG for the VPN adapter:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Win32 Adapter V9
   Physical Address. . . . . . . . . : XXXXXXXXXXXXXXX
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::61a9:1ca1:9d4d:7c97%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.8.0.5(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Lease Obtained. . . . . . . . . . : Thursday, March 14, 2013 12:09:16 PM
   Lease Expires . . . . . . . . . . : Friday, March 14, 2014 12:09:16 PM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 10.8.0.6
   DHCPv6 IAID . . . . . . . . . . . : 620822470
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-EF-7D-41-10-1F-74-59-A1-08
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

mwandelaar

To start with it, your server and client-config look fine with me. There are though some point to test.

First of all, your assumption of the vpn-server being 10.8.0.1 is correct, however:
As you are not using the directive

topology subnet

on the server, each client is granted a very small subnet, holding 2 actual ip-addresses. As you can see in your client and you were allready testing with pinging.
The directive

client-to-client

makes openvpn inside the daemon route packets through the vpn-server but this does NOT include forwarding and routing packets outside the daemon.
And as the peer2peer addresses are created on the fly when clients connect, not all the software on the server will automaticly start listening on the new ip-address. Therefore it can be possible you cannot reach the remote-desktop there.

If, on the other hand the server isn't available on the 10.8.0.1 address and in your case even not responding to ping-packets, it must be some kind of firewall application on the serverside not accepting packets from the tun-adapter to the host.

So please check if there's any kind of firewall-software active on the server blocking this.

mikejansen

mwandelaar,

So please check if there's any kind of firewall-software active on the server blocking this.

I had thought I checked that a while back, but apparently I didn't. That was the problem. Sorry about the lengthy post for such a basic issue. Thanks for your detailed response that ended with the correct solution.

Mike