Hi,
On 31/01/19 05:10, Daniel Miller via Openvpn-users wrote:
On 1/29/2019 3:45 PM, Jan Just Keijser wrote:
Hi,
my answer seems to have gone AWOL. Here it is again:
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.
tshark is available - but I don't know how to run it effectively for
this. The VPN server has both tun0 and enp2s0 interfaces available
and it appears tshark only listens on one. Do I need to run multiple
instances to capture both?
it is probably easiest to run it on the tun0 interface, as you will
capture less non-relevant traffic.
Set up the tshark/tcpdump filter, then run a 'ping' from the OpenVPN
client to the server-side LAN GW straight after the connection has been
set up.
If you want, you can email/send me the cap file privately and I will
have a quick peek.
cheers,
JJK
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
