Client can't see server's LAN

[opapanik]

I am sure you are right about netsh. I'm at work and checking on a Windows 10 home machine and it's fine. At home it's windows 10 pro, and up until now I thought the specific show interface x option was not available (not the command in general) because when I tried I got a command not found error. Probably I mistyped something. It is obvious I haven't been using the command.. Will try again at home but I'm sure you're right.

On other news, I set up this Windows 10 home machine as client and connected from work. No joy.. No answer when pinging other than the server machines at home. So it is not android client related.

I think that means the problem is in the server:
- configuration
- OS quirks
- TAP adapter bug
- openvnc windows-specific bug

I think it's in the latter three, unless someone shows up that has no problem seeing a Windows server's lan from the VPN client..

[TinCanTech]

unless someone shows up that has no problem seeing a Windows server's lan from the VPN client

It works for me .. Registry: enable ip_forwarding (or enable_router, what ever M$ call it) and add required routing.

[opapanik]

Great! Thanks for chiming in!

I'm not at home right now so I can try, but can you please tell how you came to do that (did you read it somewhere, were you experimenting, something else?).

Maybe if it's absolutely necessary it should be added to the howto's for the windows case?

Edit: can you please elaborate? I take it you're not talking about the registry setting already discussed and adding a route to the configuration files which I already tried..

In any case if it works for you I would appreciate it if you watched this thread and we went checking step by step for differences in my configuration and yours.

[TinCanTech]

I followed the HOWTO ..

But these are the steps you need :

• A working VPN. (which you have)
• Push the server route to the client: push "route 10.20.30.0 255.255.255.0" (That is all you require)
• Enable IP_Forwarding on the server. (Reboot)
• Disable the server, client and target hosts firewall.
  (until you get it working, then configure the firewalls with necessary rules).
• Add routes to the target hosts for the VPN subnet.

Some more Examples :

• viewtopic.php?f=7&t=23588
• viewtopic.php?f=7&t=20765
• viewtopic.php?f=7&t=20590

[opapanik]

I'm sorry, I know this gets tiring.

I have tried everything you suggested here, I have followed the guides, have read the HOWTOs. It's been 4 days now that this has taken all my free time. I am now thinking of setting up a linux machine for the sole purpose of locating the problem.

With the below configuration my only problem is vpn client can't see server's LAN.
Please everybody review the following and comment if you will. Thank you to all who suggested things and to all who will take the time to have another look at it.

LAN: 10.20.30.0/24, modem/router/gateway at 10.20.30.254, VPN server Windows 7 ultimate at 10.20.30.10, various other machines on the LAN (Windows desktops and laptops, Androids, TV's, connected by both ethernet or WiFi)

View Originalserver config

port 1194
proto udp4
dev tun
dev-node OpenVPNTAP
ca ca.crt
cert server.crt
key server.key
dh dh4096.pem
topology subnet
server 10.20.31.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.20.30.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
client-to-client
keepalive 10 120
cipher AES-256-CBC
persist-key
persist-tun
verb 6
explicit-exit-notify 1

View Originalclient config

client
dev tun
proto udp
remote xxx.xxx.xxx 1194
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
verb 6

Things I did:

On my modem router:
1. added routing from 10.20.31.0/24 (VPN addresses) to 10.20.30.10 (LAN IP of windows VPN server)

On the windows server:
2. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters] "IPEnableRouter"=dword:00000001
3. Enabled the Routing and Remote Access windows service

4. Turned off all firewalls (except the modem/router's built-in)

Things I tried suggested in various threads and guides, that actully made things worse (e.g. I lost features like internet for VPN, previously successful pings no more worked, etc.), so finally un-did them:

1. Manually added gateway to the TAP adapter
2. Enabled internet connection sharing on the TAP adapter

Questions:

1. The server's Network and Sharing center shows the TAP adapter's network as Public and does not allow me to do anything about it. Is it ok? (have read the threads about alleviating that, but following the instructions only made things worse, see above)

2. So far I have only tried to make the server-side LAN accessible to the VPN client. I have NOT also activated the configuration settings that would allow access to the client-side LAN. You think that could be a problem and I should try to enable them both at the same time?

3. Entry from the server's starting log:

Code: Select all

Tue May 09 20:27:28 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.20.31.1/255.255.255.0 on interface {48E36609-E1A9-43B5-BBEE-8D1FBEEFA676} [DHCP-serv: 10.20.31.254, lease-time: 31536000]

That 10.20.31.254 assigned DHCP-server is in the created VPN subnetwork and does not really exist. Is it normal (is it some kind of virtual server assigned by openvpn)?

Finally, some ping related server logs (android VPN client connected via 4G):

1. server-side LAN machine > VPN client (successful):

Code: Select all

Tue May 09 20:04:36 2017 G4/188.73.246.132:34192 UDPv4 WRITE [81] to [AF_INET]188.73.246.132:34192: P_DATA_V1 kid=0 DATA len=80
Tue May 09 20:04:36 2017 G4/188.73.246.132:34192 UDPv4 READ [84] from [AF_INET]188.73.246.132:34192: P_DATA_V2 kid=0 DATA len=83
Tue May 09 20:04:36 2017 G4/188.73.246.132:34192 TUN WRITE [60]

- VPN client > VPN server's LAN IP (successful):

Code: Select all

Tue May 09 20:09:40 2017 G4/188.73.246.132:34192 UDPv4 READ [108] from [AF_INET]188.73.246.132:34192: P_DATA_V2 kid=0 DATA len=107
Tue May 09 20:09:40 2017 G4/188.73.246.132:34192 TUN WRITE [84]
Tue May 09 20:09:40 2017 G4/188.73.246.132:34192 TUN READ [84]
Tue May 09 20:09:40 2017 G4/188.73.246.132:34192 UDPv4 WRITE [105] to [AF_INET]188.73.246.132:34192: P_DATA_V1 kid=0 DATA len=104

- VPN client > server-side LAN machine (unsuccessful):

Code: Select all

Tue May 09 20:11:57 2017 G4/188.73.246.132:34192 UDPv4 READ [108] from [AF_INET]188.73.246.132:34192: P_DATA_V2 kid=0 DATA len=107
Tue May 09 20:11:57 2017 G4/188.73.246.132:34192 TUN WRITE [84]

Comparing this unsuccessful ping to the previous successful (both originate from the VPN client, aimed at LAN) there's no TUN READ and UDPv4 WRITE. Does this mean anything to anyone?

Thanks anyhow..

[TinCanTech]

I am now thinking of setting up a linux machine for the sole purpose of locating the problem

I ditched windows completely and never looked back

1. added routing from 10.20.31.0/24 (VPN addresses) to 10.20.30.10 (LAN IP of windows VPN server)

You might expect this to work .. but .. instead, select a host you want to be able to ping over the VPN and add static routes to it.

So far I have only tried to make the server-side LAN accessible to the VPN client. I have NOT also activated the configuration settings that would allow access to the client-side LAN. You think that could be a problem and I should try to enable them both at the same time?

NO .. you do not require routing both ways because the server LAN host will only see the VPN IP.

Do not try to use the server log at high verb-age to confirm packet transmission, that is not what the log is telling you. Use Wireshark on the server (or other sniffer) to determine where the packets are discarded.

[opapanik]

I ditched windows completely and never looked back

I do not disagree but it's a big discussion.

1. added routing from 10.20.31.0/24 (VPN addresses) to 10.20.30.10 (LAN IP of windows VPN server)

You might expect this to work .. but .. instead, select a host you want to be able to ping over the VPN and add static routes to it.

I am not really sure I understand what you say I should switch it to. This was according to the HOWTO:
"The 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 (you won't need this if the OpenVPN server box is the gateway for the server LAN)."
and as far as I can tell it is the reason I can ping from any LAN machine to the VPN client. It is referred as static routing on the router.

NO .. you do not require routing both ways because the server LAN host will only see the VPN IP.

Thanks for clearing this.

Do not try to use the server log at high verb-age to confirm packet transmission, that is not what the log is telling you. Use Wireshark on the server (or other sniffer) to determine where the packets are discarded.

True but at least as a quick and dirty trick I could confirm the ping is routed from the client through the VPN and reaches the server, no? The problem begins there..

[opapanik]

Ok here's a good one:

if I initiate pings from both sides (as in LAN machine > VPN client and vice versa) at almost the same time, the VPN client sees the LAN machine (gets replies to its pings)!!!

Even more strange, for some of the LAN clients this lasts only a few minutes: the VPN client gets replies to its pings for some minutes after the initial "meeting". After a while it does not, and a new ping from the LAN machine toward the VPN client is required for the latter to "see" the LAN machine again!

For other LAN clients it seems to be a once-I-saw-you-I-know-you kind of thing and the VPN client can find them after the initial "meeting".

There are two switches in my network a 100mbps and a 1gbps. (I do turn off all network hardware when I have routing problems and have done it already before posting here)
Could it be a switching (hardware) problem?

[Pippin]

Windows firewall is a stateful firewall.
My guess:
Your Windows firewall is not completely shutdown.
It remembers the state for a "certain time" of the ping coming from LAN machine going to VPN client.
If ping the other way and it succeeds then the state is still in the state table.
After a "certain time" the state is deleted from the state table and ping will not succeed.

[opapanik]

Checked windows firewall like that:
Open Network and Sharing Center > Windows Firewall > Turn Windows Firewall On or Off > Off (for both Home or Work and Public networks)
Continued to Advanced Settings > Windows Firewall Off (reported) for Domain Profile, Private Profile and Public Profile
(menu) Action > Properties > (for every one of the 3 profiles) Customize (protected network connections) > unchecked TAP adapter
Continued to Monitoring > Windows Firewall Off (reported) for all networks

Shut everything (hardware) down. Restarted. No changes in my situation.

[opapanik]

Setting aside this strange behaviour and returning to the problem. Talking about the unsuccessful pings from VPN client > LAN machines now:

I have confirmed that all pings from the VPN client reach their LAN targets. It's the answer that cannot get back to the VPN client.
So I guess I have a routing problem. But how can it be that (from LAN machines) answers to pings are not routed when initiating pings are ?

[opapanik]

Nailed it! It's the router. A new TP-Link TD-W9977 VDSL N300 router.

Had to dig up my old ADSL router (TP-Link TL-WR340G). As soon as I set it up using same subnets and all and put it in place, bam! Problem gone!

Probably a firmware bug with the TD-W9977. Now I have to contact TP-Link..

Thanks everyone.

[TinCanTech]

Thanks for letting us know what the real cause of the problem

[Pippin]

Ah yup, if it`s not routing correctly that would explain it.
Happy VPN`ing :tumbsup:

[opapanik]

Correction: the TL-WR340G is not ADSL, just (wireless) router.
Anyway, I posted in TP-Link's forum.

Thanks again.

[TinCanTech]

Is there any real doubt ?

[opapanik]

I'm sorry, I don't get you. Doubt about what?

[TinCanTech]

If it is openvpn at fault .. or not ?

[opapanik]

Oh no, OpenVPN is fine I guess.
As I said above all I did was switch hardware and the problem was gone. The only setup I did was on the old router cause it had defaults like 192.168.0.1 and stuff. Didn't touch any PCs or Androids.
Sorry if it wasn't clear (English not my native language)

So, simple hardware change and problem gone, seems clear cut who's at fault, to me. Have informed TP-Link and asked to address the probable firmware bug of TD-W9977.

Waiting for reply.

[horhe713]

I would like to reopen this thread as i am at the same boat with our friend but tried 3 different routers and NONE solved the problem... In fact im doing EXACTLY what i used to do and it was working o ly now it doesnt work... There must be an error somewhere else and not the router... If somebody reads this ill post my details