Hi,
my answer seems to have gone AWOL. Here it is again:
On 21/01/19 03:24, Daniel Miller via Openvpn-users wrote:
On 1/16/2019 6:25 AM, Jan Just Keijser wrote:
Hi,
On 14/01/19 23:04, Daniel Miller via Openvpn-users wrote:
I have a configuration that probably should be listed in the
examples/FAQ - but I'm not seeing what I need.
In theory, what you are asking is definitely possible, with proper
routing and without NATting.
In practice, you will find that your choice of subnets (esp
192.168.[01]/24 on the server side) will cause problems that are most
easily solved using NATting.
But, let's start debugging your problem first:
- is IP forwarding enabled on the VPN server (check /etc/sysctl.conf
and /proc/sys/net/ipv4/ip_forward)
- the VPN client seems to be running Windows - what type of network
adapter is the tun adapter? Public, or private/work/home? Windows
does not allow pings to *any* public adapter (or other connectivity).
- can you ping the VPN IP of a client from the VPN server? Only if
that works, move on to the server-side GW and try it there.
Well - I did figure out that my own workstation had a firewall rule
(default Windows 10) that was blocking pings! So enabling that helps
a little bit - now my corporate LAN can ping my workstation through
the VPN.
In answer to your initial questions:
Yes, forwarding enabled. (pause while I verify initial
assumption...yes it is via /proc/sys...)
The TUN adapter shows as a "private" adapter.
private is good - it means you can set it to a "work" network , in which
case you would not need a separate firewall rule...
And yes - I can ping from any connected client to the VPN server. And
now that my firewall isn't blocking...my own client can be reached by
the server.
So now my initial question remains...but let me correct some typos:
"When pinging 192.168.0.32 (an internal LAN host) from 10.0.0.2 (my
VPN client), I will see one or more "request timed out"...but at some
point I will start seeing replies. At that time the VPN client can
access the LAN host. After a period of inactivity - the "request timed
out" condition will re-occur. So I'm assuming something (whether VPN
server, gateway, or LAN host) is "learning" how to communicate."
I'm guessing this may be some of the magic of ICMP - but regardless
the fact that there's a delay before communication is established
tells me something isn't right. I'm fairly confident adding a SNAT to
the VPN server would fix this...but I don't want to if I don't have to.
if routing is configured correctly then you would not see the "request
timed out" messages; it might be worthwhile to run tcpdump or wireshark
on the VPN server to observe the flow of ICMP packets - that usually
gives a good hint as to where any routing problems may occur.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
