Access Subnet behind OpenVPN issue

long8

Hi,

I am having an issue with the following, being trying to search the forums and Google but this problem is becoming specific now.

Windows operating systems all around;

Client -10.8.0.X  ----------->  OpenVPN - 10.8.0.1 (which resides on a Windows 2008 R2 server)
                                           |
                                           | 
                                           ˅ 
                              Windows Server 2008 R2 - 192.168.1.4 (DHCP 192.168.1.X + OpenVPN Server 10.8.0.X)

Now, I had a few teething problems at first but everything seems ironed out, except actually being able to ping other computers on the 192.168.1.X subnet.

Client;
1. Can ping 10.8.0.1
2. Can ping 192.168.1.4
3. Can't ping anything else on 192.168.1.x

Windows Server:
1. Can ping 10.8.0.1
2. Can ping 10.8.0.X (any OpenVPN client)
3. Can ping 192.168.1.X (obvious one here)

The only IP I am really trying to access is 192.168.1.5, but it's boggling as to why I can access the 1 Windows server, when I really want to access the other ones (firewalls are disabled).

Here is my config file on the OpenVPN server;

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 192.168.1.0 255.255.255.0"

keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Here is the logs from the OpenVPN server

Thu Jul 03 09:48:03 2014 OpenVPN 2.1.3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Aug 20 2010
Thu Jul 03 09:48:03 2014 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 03 09:48:03 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Jul 03 09:48:04 2014 Diffie-Hellman initialized with 1024 bit key
Thu Jul 03 09:48:04 2014 TLS-Auth MTU parms [ L:1542 EF:38 EB:0 EL:0 ]
Thu Jul 03 09:48:04 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Jul 03 09:48:04 2014 ROUTE default_gateway=192.168.1.200
Thu Jul 03 09:48:04 2014 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{18X5GS423-0SV3-41FC-Q88C-93812DB81S4}.tap
Thu Jul 03 09:48:04 2014 TAP-Win32 Driver Version 9.7 
Thu Jul 03 09:48:04 2014 TAP-Win32 MTU=1500
Thu Jul 03 09:48:04 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.1/255.255.255.252 on interface {18X5GS423-0SV3-41FC-Q88C-93812DB81S4} [DHCP-serv: 10.8.0.2, lease-time: 31536000]
Thu Jul 03 09:48:04 2014 Sleeping for 10 seconds...
Thu Jul 03 09:48:14 2014 Successful ARP Flush on interface [16] {18X5GS423-0SV3-41FC-Q88C-93812DB81S4}
Thu Jul 03 09:48:14 2014 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Thu Jul 03 09:48:14 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu Jul 03 09:48:14 2014 Route addition via IPAPI succeeded [adaptive]
Thu Jul 03 09:48:14 2014 Data Channel MTU parms [ L:1542 EF:42 EB:135 EL:0 AF:3/1 ]
Thu Jul 03 09:48:14 2014 UDPv4 link local (bound): [undef]:1194
Thu Jul 03 09:48:14 2014 UDPv4 link remote: [undef]
Thu Jul 03 09:48:14 2014 MULTI: multi_init called, r=256 v=256
Thu Jul 03 09:48:14 2014 IFCONFIG POOL: base=10.8.0.4 size=62
Thu Jul 03 09:48:14 2014 IFCONFIG POOL LIST
Thu Jul 03 09:48:14 2014 client1,10.8.0.4
Thu Jul 03 09:48:14 2014 Initialization Sequence Completed
Thu Jul 03 09:48:45 2014 MULTI: multi_create_instance called
Thu Jul 03 09:48:45 2014 :18132 Re-using SSL/TLS context
Thu Jul 03 09:48:45 2014 :18132 LZO compression initialized
Thu Jul 03 09:48:45 2014 :18132 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Jul 03 09:48:45 2014 :18132 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Jul 03 09:48:45 2014 :18132 Local Options hash (VER=V4): '5102dCeS'
Thu Jul 03 09:48:45 2014 :18132 Expected Remote Options hash (VER=V4): '654912'
Thu Jul 03 09:48:45 2014 :18132 TLS: Initial packet from :18132, sid=634c219X ZS2bc5ec
Thu Jul 03 09:48:46 2014 :18132 VERIFY OK: depth=1, 
Thu Jul 03 09:48:46 2014 :18132 VERIFY OK: depth=0, 
Thu Jul 03 09:48:46 2014 :18132 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 03 09:48:46 2014 :18132 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 03 09:48:46 2014 :18132 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Jul 03 09:48:46 2014 :18132 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 03 09:48:46 2014 :18132 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Jul 03 09:48:46 2014 :18132 [client1] Peer Connection Initiated with :18132
Thu Jul 03 09:48:46 2014 client1/:18132 MULTI: Learn: 10.8.0.6 -> client1/:18132
Thu Jul 03 09:48:46 2014 client1/:18132 MULTI: primary virtual IP for client1/:18132: 10.8.0.6
Thu Jul 03 09:48:48 2014 client1/:18132 PUSH: Received control message: 'PUSH_REQUEST'
Thu Jul 03 09:48:48 2014 client1/:18132 SENT CONTROL [client1]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 1 ,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

Route table from client

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.100.1   192.168.100.63     10
         10.8.0.1  255.255.255.255         10.8.0.5         10.8.0.6     30
         10.8.0.4  255.255.255.252         On-link          10.8.0.6    286
         10.8.0.6  255.255.255.255         On-link          10.8.0.6    286
         10.8.0.7  255.255.255.255         On-link          10.8.0.6    286
        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.0.0    255.255.255.0         10.8.0.5         10.8.0.6     30
      192.168.1.0    255.255.255.0         10.8.0.5         10.8.0.6     30
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    276
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    276
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    276
    192.168.100.0    255.255.255.0         On-link    192.168.100.63    266
   192.168.100.63  255.255.255.255         On-link    192.168.100.63    266
  192.168.100.255  255.255.255.255         On-link    192.168.100.63    266
        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      192.168.56.1    276
        224.0.0.0        240.0.0.0         On-link          10.8.0.6    286
        224.0.0.0        240.0.0.0         On-link    192.168.100.63    266
  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      192.168.56.1    276
  255.255.255.255  255.255.255.255         On-link          10.8.0.6    286
  255.255.255.255  255.255.255.255         On-link    192.168.100.63    266
===========================================================================
Persistent Routes:
  None

long8

I pinged 192.168.1.5 and recorded it on Wireshark. Not much there.

No.     Time           Source                Destination           Protocol Length Info
      1 0.000000000    00:ff:d7:27:1e:3e     Broadcast             ARP      42     Who has 10.8.0.5?  Tell 10.8.0.6

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

No.     Time           Source                Destination           Protocol Length Info
      2 0.000124000    00:ff:d8:27:1e:3e     00:ff:d7:27:1e:3e     ARP      42     10.8.0.5 is at 00:ff:d8:27:1e:3e

Frame 2: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Ethernet II, Src: 00:ff:d8:27:1e:3e (00:ff:d8:27:1e:3e), Dst: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e)
Address Resolution Protocol (reply)

No.     Time           Source                Destination           Protocol Length Info
      3 0.000154000    10.8.0.6              192.168.1.5           ICMP     74     Echo (ping) request  id=0x0001, seq=282/6657, ttl=128

Frame 3: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: 00:ff:d8:27:1e:3e (00:ff:d8:27:1e:3e)
Internet Protocol Version 4, Src: 10.8.0.6 (10.8.0.6), Dst: 192.168.1.5 (192.168.1.5)
Internet Control Message Protocol

No.     Time           Source                Destination           Protocol Length Info
      4 4.574316000    10.8.0.6              192.168.1.5           ICMP     74     Echo (ping) request  id=0x0001, seq=283/6913, ttl=128

Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: 00:ff:d8:27:1e:3e (00:ff:d8:27:1e:3e)
Internet Protocol Version 4, Src: 10.8.0.6 (10.8.0.6), Dst: 192.168.1.5 (192.168.1.5)
Internet Control Message Protocol

No.     Time           Source                Destination           Protocol Length Info
      5 9.319734000    10.8.0.6              10.8.0.7              DB-LSP-DISC 297    Dropbox LAN sync Discovery Protocol

Frame 5: 297 bytes on wire (2376 bits), 297 bytes captured (2376 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 10.8.0.6 (10.8.0.6), Dst: 10.8.0.7 (10.8.0.7)
User Datagram Protocol, Src Port: db-lsp-disc (17500), Dst Port: db-lsp-disc (17500)
Dropbox LAN sync Discovery Protocol

No.     Time           Source                Destination           Protocol Length Info
      6 9.574606000    10.8.0.6              192.168.1.5           ICMP     74     Echo (ping) request  id=0x0001, seq=284/7169, ttl=128

Frame 6: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: 00:ff:d8:27:1e:3e (00:ff:d8:27:1e:3e)
Internet Protocol Version 4, Src: 10.8.0.6 (10.8.0.6), Dst: 192.168.1.5 (192.168.1.5)
Internet Control Message Protocol

No.     Time           Source                Destination           Protocol Length Info
      7 14.574742000   10.8.0.6              192.168.1.5           ICMP     74     Echo (ping) request  id=0x0001, seq=285/7425, ttl=128

Frame 7: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: 00:ff:d7:27:1e:3e (00:ff:d7:27:1e:3e), Dst: 00:ff:d8:27:1e:3e (00:ff:d8:27:1e:3e)
Internet Protocol Version 4, Src: 10.8.0.6 (10.8.0.6), Dst: 192.168.1.5 (192.168.1.5)
Internet Control Message Protocol

long8

I have just realized one potential issue.

Server 192.168.1.5 is on a 192.168.1.254 gateway
Server 192.168.1.4 is on a 192.168.1.200 gateway

long8

long8 wroteI have just realized one potential issue.

Server 192.168.1.5 is on a 192.168.1.254 gateway
Server 192.168.1.4 is on a 192.168.1.200 gateway

EDIT: Could this be a internal server routing issue?

I went ahead and removed the route on one of the Windows Servers (192.168.1.4, the one I could ping). I then went ahead and allowed the server to readd the routes automatically and I can no longer ping the server while connected to the VPN.

Static route (setup on the router) has no issues. I can ping the VPN clients and servers from either end any machine on the subnets without an issue.

long8

debbie10t wroteWhy do machines on the same network have different gateways ?

Not my network, but they are running some ancient software, where the developer hard coded the static IP in the software that sends information from the client to the server. That's all I know.

debbie10t wroteAnyway, your issue is almost certain to be a lack of static routing on your gateways:
HOWTO: Expanding the scope of the VPN to include additional machines

The Howto wroteThe last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box

Static routes on the gateway are set. And even then, if it wasn't set then it wouldn't make sense that I could ping 192.168.1.4 which is a server-side lan.

The only thing I can think of, is the crappy Netgear router (DG834G) they are using doesn't fully support proper static routing. I have set this up before on a Sonicwall with no issues.

long8

Please close, I have decided to put the VPN client on the server at 192.168.1.5 and I can access it that way.

long8

debbie10t wroteYour static route:

Destination IP: 10.8.0.0/24
Gateway: 192.168.1.200

is incorrect (or was before you changed your setup)

The routing should be (according to your previous posts):

Destination IP: 10.8.0.0/24
Gateway: 192.168.1.4

I will close the thread if you are finished with it ?

Hi,

Yes I also tried the static route that you suggested to no avail though.

I have the work around running though, so you can close.

Thanks