Echo Reply (ICMP) necessary for OpenVPN client to work?

wifimasters

Setting up OpenVPN for a "work from home" due to the virus. 10 users working from home using separate accounts each. 3 out of the 10 users are NOT able to create the VPN the rest are working fine. The only difference with these problematic users are they are NOT able to ping the access server (pfSense). Netcat test from these 3 locations shows client can reached port 1194/UDP but not ping.

Question: is echo reply (ICMP) from the access server back to the client necessary for the remote clients to work? Same telco provider.

johnpoz

Ability to ping is not a requirement for openvpn connection.. But if your clients are unable to ping the IP of your server, and you allow it (your other clients can ping)... That points to something on the clients network (isp or them) that is causing issue.

noplan

we stumble across the net bios settings for some unknown reasons after turnin this on
settin it on m-mode at openVPN server it works. so no questions asked
sollution runnin under the tag quick n dirty solved

hope this can help
#staysafe n healthy

JKnott

@noplan

????

Netbios has nothing to do with ping or OpenVPN.

johnpoz

Yeah the supporting netbios setting in the vpn settings would have nothing to do with the client connecting.

jimp

@wifimasters said in Echo Reply (ICMP) necessary for OpenVPN client to work?:

Netcat test from these 3 locations shows client can reached port 1194/UDP but not ping.

What kind of test exactly? Netcat will always report success for UDP no matter what. Even for closed/firewalled ports. You can't test UDP that way. And OpenVPN won't send a banner so you can't check for a test reply either.

I bet they can't actually reach the server for one reason or another.

wifimasters

@johnpoz thanks for the response. Is there any specific port/protocol needs to be open or anything for them to investigate at?

wifimasters

@jimp thanks for your response. I thought 1194/UDP was blocked so I switched to 443/TCP and all results are the same. I tried to open up web services (port forward) and see if these 3 users/location can access and yes, they can access ports 80 & 8081.

I have the pcap file captured while the client is attempting to contact the access server. Can it be uploaded here for review? Currently these users are temporarily using remote displays (Teamviewer or Anydesk) which is very slow.

thanks.

jimp

Packet capture wouldn't be helpful, really. The OpenVPN client log and OpenVPN server log would most likely have anything you'd need.

noplan

@johnpoz & @johnpoz
true ad netbios my fault spped reading gone wrong ;(
sorry

wifimasters

@jimp I left the user location already and only left with 1 vpn client log, mostly I got are pcap files. I have attached and let me know your thought. thank you.OpenVPN_client_Netgate_Forum.txt

johnpoz

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

This says you couldn't connect.. See how it says check network connectivity..

jimp

Unfortunately that error from the client side is pretty generic. The server log would have better information. (And if there are no entries in the server log from their connection attempts, then they are definitely not connecting to the OpenVPN instance on the server side...)

johnpoz

^ true.. the log on the server will show if server is seeing any connection attempt at all..

wifimasters

@jimp let me dig the server logs corresponding to the date/time of the client. thanks

wifimasters

@wifimasters GUI logs is only 2000 lines maximum I can't dig longer. Actual log also the same.

Rico

Crank up the logfilter:

-Rico

wifimasters

@Rico thanks mate! will try this.