Perfect  :) It is working everything now. THANK YOU.

About the Thing with "Force all client-generated IPv4 traffic through the tunnel." Is also fixed, i've forgot to enter every Network on the other Side (those two Office LAN and CEO LAN). When I've done that, it was working without checked "Force all client-generated IPv4 traffic through the tunnel."

Thank you.

// COLSE

@Derelict:

PIA could change that at any time.

Exactly! So for now I'm using for gw monitoring one of Level 3 resolvers - 4.2.2.[1-6]

You can achieve this by setting up client specific overrides, one for each client. VPN > OpenVPN > Client Specific Overrides.
It is required that each client has a separate, unique certificate.

Klick Add to set up a new CCO, enter the common name as it is set in the clients cert, assign an unique /30 tunnel subnet to each client, at "IPv4 Local Network/s" enter all the remote subnets the client should be able to access and at "IPv4 Remote Network/s" the subnet behind the respective client.

In the client config also enter all remote subnets, which should be accessible in the "IPv4 Remote Network/s" box.

I was experiencing similar log issues where the web UI showed "No logs to display" for OpenVPN.

I was able to fix this by going to the Settings tab on the logs screen and clicking "Rest log files".

I also ran into this issue since my ISP started throttling / rate limiting my connection speed and I saturate the WAN link with VPN traffic.  Easy to reproduce using speedtest.net.

This is typical behavior when an upstream service is throttling or rate limiting throughput, packets are delay (but not dropped) in order to choke back the downstream connection speed.

The problem your experiencing is because Gateway monitor uses dpinger, which has a configured limit on how long it waits for responses before determining they are "lost".  What's important to note is the Loss % is not actual data loss, but "missed" ping responses, because they arrived too late to be counted.

Key item that indicates this is RTTsd; RTT is of course the aggregate ping transit time, but the RTTsd is the Standard Deviation between each received ping response.  When the link is quiet the RTTsd will generally be fairly low, but when the RTTsd goes up it means that something up stream is intermittently delaying packets resulting in a larger deviation between each ping attempt. Thus if the pings are delayed beyond the configured wait time, they are considered "lost" even if they still arrive.

I was able to get around this by going to System >> Routing >> Gateways and edit each gateway to increase the "Loss Interval" under the advanced section to increase the time that dpinger waits for responses before considering them "lost".  After that, my loss percentages dropped to near 0%, but then I started seeing the real latency of the delayed packets skyrocket, so had to tweak with the Latency threshold values as well to keep the gateway from dropping out from excessively high latency when it is saturated with traffic.

You'll need to do some testing with traffic saturation on your VPN/WAN in order to come up with monitor values that do not cause the gateway monitor to considered the link offline.  I ended up having to configured some pretty high values on the upper latency threshold to keep the link from being knocked offline when running heavy traffic loads.

solved
the common name of the client's certificate was not the same

Thanks, that's good to know.

I will take a look at DNS options and investigate the Active Directory option.  (I recall reading some about Active Directory when resolving issues in setting up the OpenVPN.)

I’ve got it working, I’m not really sure how. I changed the ncp settings on the server for a different reason, redonloaded the client file, and it connected. The options in the client file look the same as the old file.

Yeah I don't see any connections or attempts even..

I saw this thread and moved on because of 5..

<grin>Something hitting your port would look something like this.

Jan 19 11:39:18 openvpn 17272 196.52.43.117:6666 Connection reset, restarting
Jan 19 11:39:18 openvpn 17272 196.52.43.117:6666 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 – please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart…]
Jan 19 11:39:16 openvpn 17272 TCP connection established with [AF_INET]196.52.43.117:6666

I would post up something hitting my UDP instance - but don't see anything going back to Jan 10th.. Would have to look through the syslog for something.  But see hits to my 443 all the time… I run an instance on tcp 443 because almost guaranteed if there is internet at the place that 443 will be open tcp.    But it does generate some noise in your logs.  While tcp not the preferred connection method - nice because makes it easy to bounce off a http proxy when your behind one like I am at work ;)</grin>

where is this 192.168.2 network in that drawing?

192.168.2 is your openvpn tunnel network – how would that create an outbound nat on your LAN??

See my attachment the 10.0.8 and 10.0.200 are my 2 vpn tunnel networks... The outbound nat is on the WAN..

openvpnnat.png
openvpnnat.png_thumb

i will try it jimp, thanks

Also keepalive directive should be configurable :)

Ok…  I gave you the "loud applause".  Nothing a shot can't cure.

Hi Derelict and viragomann,

Thank you for your responses. Yes I am testing from outside.

Just tried using do not pull routes. Disabled interfaces and re-enabled interface and it seems to be working now.

Really appreciate your help!!

Regards,
mdahal