pgb195 wrote

Hi guys,
I encountered the same problem, I believe it to be a bug in the router firmware and have reported it as such, however I'm happy to tell you that there is a workaround.

The basic issue is that the router does not send back the correct routing table entries to the client after connection in all cases.
You can verify this yourself in windows by checking the routing table.

I'll illustrate this with my own configuration.

my LAN network address is 172.16.106.0
when I initially set up client - network VPN, I followed the example in the guide, and created an address pool in the range 10.10.10.10. - 10.10.10.50 for VPN clients.
When I connected to the VPN, as you have all seen, it connected fine, but I was unable to contact any machine on my LAN.
What I discovered from the windows routing table, was that no route had been created for the 172.16.106 network.
Instead, a route to 10.0.0.0 had been created, which didn't make a great deal of sense.

However, I found that if I manually created a route to 172.16.106.0 then miraculously everything started to work.
To do this manually, check what your VPN client address is (in my case it was 10.10.10.10), and add the route in an administrator command prompt with (again using my network as an example)
route add 172.16.106.0 mask 255.255.255.0 10.10.10.10

There is also an automated way to achieve the same objective by changing the address pool so that the range is contained within the same superset as the LAN addresses.
In my example, I set the pool address range to be 172.16.108.1 - 172.16.108.50

Now when I connect to the VPN, the router creates for me a route for 172.16.0.0 which includes both the VPN client range, and the LAN subnet, so everything works as expected.

I hope that works for everyone.