[Openvpn-users] Intermittent Connectivity

[Morris, Russell]

Hi,

OK, pulling my hair out with this. I haven't really seen this before, but having issues with intermittent connectivity (lately, also with the latest versions of OpenVPN). I noticed it over SSH (connection seems to hang for periods of time), so then I tried ping => results below, and quite interesting (and very variable).

In case someone asks - I am running over TCP, but have never seen this before (so I'm not sure that's really the issue). I did try connecting to a second machine (different location) ... and that seems OK (but it's running TUN, vs. TAP - part of the issue?). And yes, I do need TAP, as I need to bridge onto the subnet (to access different machines remotely).

Pinging XXXXX.XXXX.XXXX [192.168.2.64] with 32 bytes of data:
Reply from 192.168.2.64: bytes=32 time=22ms TTL=64
Reply from 192.168.2.64: bytes=32 time=25ms TTL=64
Reply from 192.168.2.64: bytes=32 time=15ms TTL=64
Reply from 192.168.2.64: bytes=32 time=82ms TTL=64
Reply from 192.168.2.64: bytes=32 time=77ms TTL=64
Reply from 192.168.2.64: bytes=32 time=3736ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.2.48: Destination host unreachable.
Request timed out.
Reply from 192.168.2.64: bytes=32 time=15ms TTL=64
Reply from 192.168.2.64: bytes=32 time=57ms TTL=64
Reply from 192.168.2.64: bytes=32 time=68ms TTL=64
Request timed out.
Reply from 192.168.2.64: bytes=32 time=376ms TTL=64
Reply from 192.168.2.64: bytes=32 time=24ms TTL=64
Reply from 192.168.2.64: bytes=32 time=55ms TTL=64
Reply from 192.168.2.64: bytes=32 time=67ms TTL=64
Reply from 192.168.2.64: bytes=32 time=122ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=3375ms TTL=64
Request timed out.
Reply from 192.168.2.64: bytes=32 time=1411ms TTL=64
Reply from 192.168.2.64: bytes=32 time=49ms TTL=64
Reply from 192.168.2.64: bytes=32 time=42ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=87ms TTL=64
Reply from 192.168.2.64: bytes=32 time=84ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=63ms TTL=64
Reply from 192.168.2.64: bytes=32 time=22ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=72ms TTL=64
Reply from 192.168.2.64: bytes=32 time=14ms TTL=64
Reply from 192.168.2.64: bytes=32 time=10ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.2.64: bytes=32 time=2565ms TTL=64
Reply from 192.168.2.64: bytes=32 time=62ms TTL=64
Request timed out.
Reply from 192.168.2.64: bytes=32 time=39ms TTL=64
Reply from 192.168.2.64: bytes=32 time=45ms TTL=64
Reply from 192.168.2.64: bytes=32 time=10ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=13ms TTL=64
Reply from 192.168.2.64: bytes=32 time=13ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.2.64: bytes=32 time=57ms TTL=64
Reply from 192.168.2.64: bytes=32 time=10ms TTL=64
Reply from 192.168.2.64: bytes=32 time=10ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=66ms TTL=64
Reply from 192.168.2.64: bytes=32 time=69ms TTL=64
Reply from 192.168.2.64: bytes=32 time=19ms TTL=64
Reply from 192.168.2.64: bytes=32 time=23ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=64ms TTL=64
Reply from 192.168.2.64: bytes=32 time=20ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=19ms TTL=64
Reply from 192.168.2.64: bytes=32 time=67ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64
Reply from 192.168.2.64: bytes=32 time=11ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.2.64: bytes=32 time=1840ms TTL=64
Reply from 192.168.2.64: bytes=32 time=51ms TTL=64
Reply from 192.168.2.64: bytes=32 time=221ms TTL=64
Reply from 192.168.2.64: bytes=32 time=12ms TTL=64

Thoughts? Things to try?

Thanks!

... Russell

[David Sommerseth]

Post by Morris, Russell
Hi,
OK, pulling my hair out with this. I haven't really seen this before,
but having issues with intermittent connectivity (lately, also with
the latest versions of OpenVPN). I noticed it over SSH (connection
seems to hang for periods of time), so then I tried ping => results
below, and quite interesting (and very variable).
In case someone asks - I am running over TCP, but have never seen
this before (so I'm not sure that's really the issue). I did try
connecting to a second machine (different location) ... and that
seems OK (but it's running TUN, vs. TAP - part of the issue?).

[...snip...]

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.

Post by Morris, Russell
And yes, I do need TAP, as I need to bridge onto the subnet (to
access different machines remotely).

"to access different machines remotely" is very seldom a good argument
for bridging. If your remote machines understands TCP/IP routing
properly, you will most likely have a far better result using a routed
TUN setup, with the VPN link (tun adapters) residing in their own
subnet. This will remove a lot of broadcast traffic, which can eat up
the bandwidth - especially there's lots of broadcast chatter on both
sides of the tunnel. Plus the packets transported between the VPN
client and server is also a bit smaller, as it doesn't need the Ethernet
frame (which contains MAC addresses among others).

Those scenarios where bridging really makes sense are for non-TCP/IP
protocols or where the application protocol really depends on broadcast
traffic (like older LAN games). If you think of Windows file shares, it
is far better to use WINS, which works very well over routed TUN.

[Morris, Russell]

Thanks for the comments! A couple thoughts / questions, below.

... Russell


-----Original Message-----
From: David Sommerseth [mailto:***@sf.lists.topphemmelig.net]
Sent: Friday, July 7, 2017 8:00 AM
To: Morris, Russell <***@rkmorris.us>; openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Intermittent Connectivity

Post by Morris, Russell
Hi,
OK, pulling my hair out with this. I haven't really seen this before,
but having issues with intermittent connectivity (lately, also with
the latest versions of OpenVPN). I noticed it over SSH (connection
seems to hang for periods of time), so then I tried ping => results
below, and quite interesting (and very variable).
In case someone asks - I am running over TCP, but have never seen this
before (so I'm not sure that's really the issue). I did try connecting
to a second machine (different location) ... and that seems OK (but
it's running TUN, vs. TAP - part of the issue?).

[...snip...]

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the inside and outside of the tunnel. So try switching to --proto udp.

[R. Morris] Actually, is it really TCP? Asking because the other connection I tested is TCP also, just TUN instead of TAP ... and it's rock solid. I don't really have the option to use UDP, a bit handcuffed there ... :-(.

Post by Morris, Russell
And yes, I do need TAP, as I need to bridge onto the subnet (to access
different machines remotely).

"to access different machines remotely" is very seldom a good argument for bridging. If your remote machines understands TCP/IP routing properly, you will most likely have a far better result using a routed TUN setup, with the VPN link (tun adapters) residing in their own subnet. This will remove a lot of broadcast traffic, which can eat up the bandwidth - especially there's lots of broadcast chatter on both sides of the tunnel. Plus the packets transported between the VPN client and server is also a bit smaller, as it doesn't need the Ethernet frame (which contains MAC addresses among others).

Those scenarios where bridging really makes sense are for non-TCP/IP protocols or where the application protocol really depends on broadcast traffic (like older LAN games). If you think of Windows file shares, it is far better to use WINS, which works very well over routed TUN.

[R. Morris] Intrigued ... :-). TUN would be fine, if I could get to the machines on the subnet ... but can I really? I need to run RDP, VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested to try this, but I thought to be "on" the subnet, and access all the machines (by name) I needed to use TAP.


--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

[Morris, Russell]

First of all, thanks for taking the time to provide the detailed information below - it's very much appreciated! I will try to set it up this way, let you know what I find. But I do agree, I think this is a better way to go.

BTW, do you want me to try to take some logs, or not really that big of a curiosity / issue? Just let me know, I can if it helps at all.

And also, thanks for the book recommendation - buying it tonight ... 😊.

Thanks again,
... Russell


-----Original Message-----
From: David Sommerseth [mailto:***@sf.lists.topphemmelig.net]
Sent: Friday, July 7, 2017 4:41 PM
To: Morris, Russell <***@rkmorris.us>
Subject: Re: [Openvpn-users] Intermittent Connectivity

On 07/07/17 16:36, Morris, Russell wrote:
[...snip...]

Post by David Sommerseth

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.
[R. Morris] Actually, is it really TCP? Asking because the other
connection I tested is TCP also, just TUN instead of TAP ... and it's
rock solid. I don't really have the option to use UDP, a bit
handcuffed there ... :-(.

Okay, that is a more tricky issue. It is really hard to say without seeing some logs (--verb 4). There might be packet replays, it might be packet loss, it might be packet latency, really hard to guess without logs.

Post by David Sommerseth
[R. Morris] Intrigued ... :-). TUN would be fine, if I could get to
the machines on the subnet ... but can I really? I need to run RDP,
VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested
to try this, but I thought to be "on" the subnet, and access all the
machines (by name) I needed to use TAP.

What you basically need to do is:

- Allocate the VPN on a separate subnet (our examples often use
10.8.0.0/24)

- VPN server need to push (or add directly route in client config)

route $LAN_SUBNET_IP $LAN_SUBNET_MASK

If your LAN is 192.168.1.0/24 (255.255.255.0), you need:

route 192.168.1.0 255.255.255.0

- Enable IP forwarding on the VPN server. On Linux this is typically
done with: sysctl net.ipv4.ip_forward=1

- Allow traffic passing between the LAN and the TUN adapter in the
firewall. For Linux servers, that's easily handled by:

# iptables -I FORWARD -i tun+ -o eth+ \
-m conntrack --state NEW -j ACCEPT
# iptables -I FORWARD -m conntrack --state ESTALISHED,RELATED \
-j ACCEPT

This allows traffic initiated from the VPN (any adapters named
tun-something) to access network resources on any Ethernet
interfaces named eth-something. (+ is a wildcard)

- The default gateway in the LAN needs to route the 10.8.0.0/24
via the VPN server. If the VPN server is running on your default
gateway this is already correctly set up.

a) LAN GW + VPN server on same box:

{internet}-[FW]---[LAN GW/VPN]---{LAN}

b) VPN server is on the LAN

{internet}-[FW]----[LAN GW]----{LAN}
\-{VPN-SERVER}

If the VPN server IP is 192.168.1.10, the LAN GW needs this
route: ip route add 10.8.0.0/24 via 192.168.1.10

c) VPN server is in a DMZ

{internet}-[FW]----[LAN GW]----{LAN}
|
\-{VPN-SERVER in DMZ}

If the VPN server IP is 172.16.2.20, the FW(!) needs this
route: ip route add 10.8.0.0/24 via 172.16.2.20

- To use DNS hostnames for the hosts on LAN, you need to add
this to your server config:

push "dhcp-option DNS $IP_OF_INTERNAL_DNS"

For VPN connections started by the Windows GUI, Tunnelblick (macOS)
and NetworkManager (on Linux), iOS and Android, the DNS stuff on the
client side happens automatically. If starting OpenVPN from the
command line, it needs some local tweaks. For Linux,
/etc/resolv.conf needs to get updated.

Now I know that sounds like a lot of details compared to bridging. But this is actually the path of least resistance when things go bad.

And for further details, I recommend looking into the "OpenVPN 2 Cookbook" by Jan Just Keijser, and probably also the "Mastering OpenVPN 2" by Eric Crist and Jan Just Keijser (have only skimmed through that book myself so far).

[Morris, Russell]

Hi,

OK, working my way through - with a bit of "fun" ... 😊. When I add route to the OpenVPN configuration file (without the other settings I believe), I lose my local LAN completely. Is that expected?

So then, OpenVPN off, trying to set up iptables .. but I get the following. Thoughts?
iptables v1.6.0: unknown option "--state"

I'm guessing this is replaced in more recent versions, but not having any luck finding the new flag.

Thanks!

... Russell



-----Original Message-----
From: Morris, Russell
Sent: Sunday, July 9, 2017 9:55 PM
To: 'openvpn-***@lists.sourceforge.net' <openvpn-***@lists.sourceforge.net>
Subject: RE: [Openvpn-users] Intermittent Connectivity

First of all, thanks for taking the time to provide the detailed information below - it's very much appreciated! I will try to set it up this way, let you know what I find. But I do agree, I think this is a better way to go.

BTW, do you want me to try to take some logs, or not really that big of a curiosity / issue? Just let me know, I can if it helps at all.

And also, thanks for the book recommendation - buying it tonight ... 😊.

Thanks again,
... Russell


-----Original Message-----
From: David Sommerseth [mailto:***@sf.lists.topphemmelig.net]
Sent: Friday, July 7, 2017 4:41 PM
To: Morris, Russell <***@rkmorris.us>
Subject: Re: [Openvpn-users] Intermittent Connectivity

On 07/07/17 16:36, Morris, Russell wrote:
[...snip...]

Post by David Sommerseth

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.
[R. Morris] Actually, is it really TCP? Asking because the other
connection I tested is TCP also, just TUN instead of TAP ... and it's
rock solid. I don't really have the option to use UDP, a bit
handcuffed there ... :-(.

Okay, that is a more tricky issue. It is really hard to say without seeing some logs (--verb 4). There might be packet replays, it might be packet loss, it might be packet latency, really hard to guess without logs.

Post by David Sommerseth
[R. Morris] Intrigued ... :-). TUN would be fine, if I could get to
the machines on the subnet ... but can I really? I need to run RDP,
VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested
to try this, but I thought to be "on" the subnet, and access all the
machines (by name) I needed to use TAP.

What you basically need to do is:

- Allocate the VPN on a separate subnet (our examples often use
10.8.0.0/24)

- VPN server need to push (or add directly route in client config)

route $LAN_SUBNET_IP $LAN_SUBNET_MASK

If your LAN is 192.168.1.0/24 (255.255.255.0), you need:

route 192.168.1.0 255.255.255.0

- Enable IP forwarding on the VPN server. On Linux this is typically
done with: sysctl net.ipv4.ip_forward=1

- Allow traffic passing between the LAN and the TUN adapter in the
firewall. For Linux servers, that's easily handled by:

# iptables -I FORWARD -i tun+ -o eth+ \
-m conntrack --state NEW -j ACCEPT
# iptables -I FORWARD -m conntrack --state ESTALISHED,RELATED \
-j ACCEPT

This allows traffic initiated from the VPN (any adapters named
tun-something) to access network resources on any Ethernet
interfaces named eth-something. (+ is a wildcard)

- The default gateway in the LAN needs to route the 10.8.0.0/24
via the VPN server. If the VPN server is running on your default
gateway this is already correctly set up.

a) LAN GW + VPN server on same box:

{internet}-[FW]---[LAN GW/VPN]---{LAN}

b) VPN server is on the LAN

{internet}-[FW]----[LAN GW]----{LAN}
\-{VPN-SERVER}

If the VPN server IP is 192.168.1.10, the LAN GW needs this
route: ip route add 10.8.0.0/24 via 192.168.1.10

c) VPN server is in a DMZ

{internet}-[FW]----[LAN GW]----{LAN}
|
\-{VPN-SERVER in DMZ}

If the VPN server IP is 172.16.2.20, the FW(!) needs this
route: ip route add 10.8.0.0/24 via 172.16.2.20

- To use DNS hostnames for the hosts on LAN, you need to add
this to your server config:

push "dhcp-option DNS $IP_OF_INTERNAL_DNS"

For VPN connections started by the Windows GUI, Tunnelblick (macOS)
and NetworkManager (on Linux), iOS and Android, the DNS stuff on the
client side happens automatically. If starting OpenVPN from the
command line, it needs some local tweaks. For Linux,
/etc/resolv.conf needs to get updated.

Now I know that sounds like a lot of details compared to bridging. But this is actually the path of least resistance when things go bad.

And for further details, I recommend looking into the "OpenVPN 2 Cookbook" by Jan Just Keijser, and probably also the "Mastering OpenVPN 2" by Eric Crist and Jan Just Keijser (have only skimmed through that book myself so far).

[Morris, Russell]

Hi,

OK, a bit more on this (hopefully helping others out!),
- I got the route push working, was a misunderstanding on my part ... sorry! Now the link stays up very reliably. And FYI, I still see a (much smaller) delay variation, and no drop out. Excellent!
- with iptables in Ubuntu (v1.6.0), --state does not exist, but it's now --ctstate. Again, just to help others.
- so now, I can try to ping back from the OpenVPN client to the LAN. I do see traffic showing up in the iptables counters (good!), under NEW, but it's not going past that. I assume that this is due to the (yet missing) route. But when I try to enter that command (my OpenVPN server is on a machine on my LAN, not on the GW), I get the following,

sudo ip route add 172.16.1.0/24 via 192.168.1.10
RTNETLINK answers: File exists

Thoughts?

Thanks again for all the help!

... Russell


-----Original Message-----
From: Morris, Russell
Sent: Monday, July 10, 2017 10:00 PM
To: openvpn-***@lists.sourceforge.net
Subject: RE: [Openvpn-users] Intermittent Connectivity

Hi,

OK, working my way through - with a bit of "fun" ... 😊. When I add route to the OpenVPN configuration file (without the other settings I believe), I lose my local LAN completely. Is that expected?

So then, OpenVPN off, trying to set up iptables .. but I get the following. Thoughts?
iptables v1.6.0: unknown option "--state"

I'm guessing this is replaced in more recent versions, but not having any luck finding the new flag.

Thanks!

... Russell



-----Original Message-----
From: Morris, Russell
Sent: Sunday, July 9, 2017 9:55 PM
To: 'openvpn-***@lists.sourceforge.net' <openvpn-***@lists.sourceforge.net>
Subject: RE: [Openvpn-users] Intermittent Connectivity

First of all, thanks for taking the time to provide the detailed information below - it's very much appreciated! I will try to set it up this way, let you know what I find. But I do agree, I think this is a better way to go.

BTW, do you want me to try to take some logs, or not really that big of a curiosity / issue? Just let me know, I can if it helps at all.

And also, thanks for the book recommendation - buying it tonight ... 😊.

Thanks again,
... Russell


-----Original Message-----
From: David Sommerseth [mailto:***@sf.lists.topphemmelig.net]
Sent: Friday, July 7, 2017 4:41 PM
To: Morris, Russell <***@rkmorris.us>
Subject: Re: [Openvpn-users] Intermittent Connectivity

On 07/07/17 16:36, Morris, Russell wrote:
[...snip...]

Post by David Sommerseth

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.
[R. Morris] Actually, is it really TCP? Asking because the other
connection I tested is TCP also, just TUN instead of TAP ... and it's
rock solid. I don't really have the option to use UDP, a bit
handcuffed there ... :-(.

Okay, that is a more tricky issue. It is really hard to say without seeing some logs (--verb 4). There might be packet replays, it might be packet loss, it might be packet latency, really hard to guess without logs.

Post by David Sommerseth
[R. Morris] Intrigued ... :-). TUN would be fine, if I could get to
the machines on the subnet ... but can I really? I need to run RDP,
VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested
to try this, but I thought to be "on" the subnet, and access all the
machines (by name) I needed to use TAP.

What you basically need to do is:

- Allocate the VPN on a separate subnet (our examples often use
10.8.0.0/24)

- VPN server need to push (or add directly route in client config)

route $LAN_SUBNET_IP $LAN_SUBNET_MASK

If your LAN is 192.168.1.0/24 (255.255.255.0), you need:

route 192.168.1.0 255.255.255.0

- Enable IP forwarding on the VPN server. On Linux this is typically
done with: sysctl net.ipv4.ip_forward=1

- Allow traffic passing between the LAN and the TUN adapter in the
firewall. For Linux servers, that's easily handled by:

# iptables -I FORWARD -i tun+ -o eth+ \
-m conntrack --state NEW -j ACCEPT
# iptables -I FORWARD -m conntrack --state ESTALISHED,RELATED \
-j ACCEPT

This allows traffic initiated from the VPN (any adapters named
tun-something) to access network resources on any Ethernet
interfaces named eth-something. (+ is a wildcard)

- The default gateway in the LAN needs to route the 10.8.0.0/24
via the VPN server. If the VPN server is running on your default
gateway this is already correctly set up.

a) LAN GW + VPN server on same box:

{internet}-[FW]---[LAN GW/VPN]---{LAN}

b) VPN server is on the LAN

{internet}-[FW]----[LAN GW]----{LAN}
\-{VPN-SERVER}

If the VPN server IP is 192.168.1.10, the LAN GW needs this
route: ip route add 10.8.0.0/24 via 192.168.1.10

c) VPN server is in a DMZ

{internet}-[FW]----[LAN GW]----{LAN}
|
\-{VPN-SERVER in DMZ}

If the VPN server IP is 172.16.2.20, the FW(!) needs this
route: ip route add 10.8.0.0/24 via 172.16.2.20

- To use DNS hostnames for the hosts on LAN, you need to add
this to your server config:

push "dhcp-option DNS $IP_OF_INTERNAL_DNS"

For VPN connections started by the Windows GUI, Tunnelblick (macOS)
and NetworkManager (on Linux), iOS and Android, the DNS stuff on the
client side happens automatically. If starting OpenVPN from the
command line, it needs some local tweaks. For Linux,
/etc/resolv.conf needs to get updated.

Now I know that sounds like a lot of details compared to bridging. But this is actually the path of least resistance when things go bad.

And for further details, I recommend looking into the "OpenVPN 2 Cookbook" by Jan Just Keijser, and probably also the "Mastering OpenVPN 2" by Eric Crist and Jan Just Keijser (have only skimmed through that book myself so far).

[Selva Nair]

Post by Morris, Russell
OK, a bit more on this (hopefully helping others out!),
- I got the route push working, was a misunderstanding on my part ...
sorry! Now the link stays up very reliably. And FYI, I still see a (much
smaller) delay variation, and no drop out. Excellent!
- with iptables in Ubuntu (v1.6.0), --state does not exist, but it's now
--ctstate. Again, just to help others.
- so now, I can try to ping back from the OpenVPN client to the LAN. I do
see traffic showing up in the iptables counters (good!), under NEW, but
it's not going past that. I assume that this is due to the (yet missing)
route. But when I try to enter that command (my OpenVPN server is on a
machine on my LAN, not on the GW), I get the following,
sudo ip route add 172.16.1.0/24 via 192.168.1.10
RTNETLINK answers: File exists
Thoughts?

Hi Russel,

Assuming 172.16.1.0/24 is the VPN network and 129.168.1.0/24 the LAN, make
sure that route is added on the GW. From the error message, it looks like
you are trying to add it on the VPN server.

Selva

[Morris, Russell]

Hi Selva,

Yep, that makes sense – and works, thanks! Now I can ping 172.16.1.1 from the gateway machine 
 but, I can’t ping from the OpenVPN client to machines on the subnet (only the OpenVPN machine itself, 192.168.1.10). Thoughts? I did add the forward, and the iptables entries.

Thanks again,

 Russell


From: Selva Nair [mailto:***@gmail.com]
Sent: Tuesday, July 11, 2017 12:54 PM
To: Morris, Russell <***@rkmorris.us>
Cc: openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Intermittent Connectivity


On Tue, Jul 11, 2017 at 12:51 PM, Morris, Russell <***@rkmorris.us<mailto:***@rkmorris.us>> wrote:

OK, a bit more on this (hopefully helping others out!),
- I got the route push working, was a misunderstanding on my part ... sorry! Now the link stays up very reliably. And FYI, I still see a (much smaller) delay variation, and no drop out. Excellent!
- with iptables in Ubuntu (v1.6.0), --state does not exist, but it's now --ctstate. Again, just to help others.
- so now, I can try to ping back from the OpenVPN client to the LAN. I do see traffic showing up in the iptables counters (good!), under NEW, but it's not going past that. I assume that this is due to the (yet missing) route. But when I try to enter that command (my OpenVPN server is on a machine on my LAN, not on the GW), I get the following,

sudo ip route add 172.16.1.0/24<http://172.16.1.0/24> via 192.168.1.10
RTNETLINK answers: File exists

Thoughts?

Hi Russel,

Assuming 172.16.1.0/24<http://172.16.1.0/24> is the VPN network and 129.168.1.0/24<http://129.168.1.0/24> the LAN, make sure that route is added on the GW. From the error message, it looks like you are trying to add it on the VPN server.

Selva

[Jan Just Keijser]

Hi,

Post by Morris, Russell
Hi Selva,
Yep, that makes sense – and works, thanks! Now I can ping 172.16.1.1
from the gateway machine … but, I can’t ping from the OpenVPN client
to machines on the subnet (only the OpenVPN machine itself,
192.168.1.10). Thoughts? I did add the forward, and the iptables entries.

did you add any forwarding rules in iptables, e.g.

iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

and is IP forwarding itself enabled on the server (see /etc/sysctl.conf).

HTH,

JJK

Post by Morris, Russell
*Sent:* Tuesday, July 11, 2017 12:54 PM
*Subject:* Re: [Openvpn-users] Intermittent Connectivity
OK, a bit more on this (hopefully helping others out!),
- I got the route push working, was a misunderstanding on my part
... sorry! Now the link stays up very reliably. And FYI, I still
see a (much smaller) delay variation, and no drop out. Excellent!
- with iptables in Ubuntu (v1.6.0), --state does not exist, but
it's now --ctstate. Again, just to help others.
- so now, I can try to ping back from the OpenVPN client to the
LAN. I do see traffic showing up in the iptables counters (good!),
under NEW, but it's not going past that. I assume that this is due
to the (yet missing) route. But when I try to enter that command
(my OpenVPN server is on a machine on my LAN, not on the GW), I
get the following,
sudo ip route add 172.16.1.0/24 <http://172.16.1.0/24> via
192.168.1.10
RTNETLINK answers: File exists
Thoughts?
Hi Russel,
Assuming 172.16.1.0/24 <http://172.16.1.0/24> is the VPN network and
129.168.1.0/24 <http://129.168.1.0/24> the LAN, make sure that route
is added on the GW. From the error message, it looks like you are
trying to add it on the VPN server.
Selva
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Morris, Russell]

Hi,

Yep, iptables is set up. Actually, seeing some odd results, and some debugging with tcpdump (below). By all means comment if I'm doing something dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making it to the gateway (excellent!). But no reply. Thinking that's a route issue, but ...
- if I ping from the gateway, to the OpenVPN client ... it works! Hmm .. so why is the gateway not replying. It does reply to pings on the LAN side.
- if I ssh from the OpenVPN client to the gateway ... it connects. So perhaps ping is fooling me (not replying to that subnet?). But,
- if I try to ping or ssh to another machine on the LAN ... ping works, but ssh fails (as does http). OK, this one is very odd ... as I do see the ping replies back through the gateway machine. And I see traffic (ssh and http) leaving the "another machine", but it's not seeming to get back to the OpenVPN client.

Definitely open to suggestions - thanks!

... Russell


From: Jan Just Keijser [mailto:***@nikhef.nl]
Sent: Tuesday, July 11, 2017 5:27 PM
To: Morris, Russell <***@rkmorris.us>; Selva Nair <***@gmail.com>
Cc: openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Intermittent Connectivity

Hi,

On 11/07/17 23:28, Morris, Russell wrote:
Hi Selva,

Yep, that makes sense - and works, thanks! Now I can ping 172.16.1.1 from the gateway machine ... but, I can't ping from the OpenVPN client to machines on the subnet (only the OpenVPN machine itself, 192.168.1.10). Thoughts? I did add the forward, and the iptables entries.


did you add any forwarding rules in iptables, e.g.

iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

and is IP forwarding itself enabled on the server (see /etc/sysctl.conf).

HTH,

JJK




From: Selva Nair [mailto:***@gmail.com]
Sent: Tuesday, July 11, 2017 12:54 PM
To: Morris, Russell <***@rkmorris.us><mailto:***@rkmorris.us>
Cc: openvpn-***@lists.sourceforge.net<mailto:openvpn-***@lists.sourceforge.net>
Subject: Re: [Openvpn-users] Intermittent Connectivity


On Tue, Jul 11, 2017 at 12:51 PM, Morris, Russell <***@rkmorris.us<mailto:***@rkmorris.us>> wrote:

OK, a bit more on this (hopefully helping others out!),
- I got the route push working, was a misunderstanding on my part ... sorry! Now the link stays up very reliably. And FYI, I still see a (much smaller) delay variation, and no drop out. Excellent!
- with iptables in Ubuntu (v1.6.0), --state does not exist, but it's now --ctstate. Again, just to help others.
- so now, I can try to ping back from the OpenVPN client to the LAN. I do see traffic showing up in the iptables counters (good!), under NEW, but it's not going past that. I assume that this is due to the (yet missing) route. But when I try to enter that command (my OpenVPN server is on a machine on my LAN, not on the GW), I get the following,

sudo ip route add 172.16.1.0/24<http://172.16.1.0/24> via 192.168.1.10
RTNETLINK answers: File exists

Thoughts?

Hi Russel,

Assuming 172.16.1.0/24<http://172.16.1.0/24> is the VPN network and 129.168.1.0/24<http://129.168.1.0/24> the LAN, make sure that route is added on the GW. From the error message, it looks like you are trying to add it on the VPN server.

Selva




------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot




_______________________________________________

Openvpn-users mailing list

Openvpn-***@lists.sourceforge.net<mailto:Openvpn-***@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Jan Just Keijser]

Hi Russell,

Post by Morris, Russell
Hi,
Yep, iptables is set up. Actually, seeing some odd results, and some
debugging with tcpdump (below). By all means comment if I’m doing
something dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making it
to the gateway (excellent!). But no reply. Thinking that's a route
issue, but ...

what exactly is 'the gateway' ? your VPN server? your LAN router/gateway?
does the gateway have a return route for packets coming from the VPN
subnet? which routes ARE listed on the gateway? is 172.16.1.0/24 included?

Post by Morris, Russell
- if I ping from the gateway, to the OpenVPN client ... it works! Hmm
.. so why is the gateway not replying. It does reply to pings on the
LAN side.

are you sure that packets end up on the VPN client? did you verify this
using tcpdump on the OpenVPN client?
sometimes masquerading/NATting might lead to unexpected results here.

If the gateway is your VPN server, then it does not surprise me that
packets are getting through, nor that you can reach the client but not
the LAN address of the gateway itself. A 'ping' to the OpenVPN client
will use the vpn server's IP address as the source address, not the LAN
address.

Post by Morris, Russell
- if I ssh from the OpenVPN client to the gateway ... it connects. So
perhaps ping is fooling me (not replying to that subnet?). But,
- if I try to ping or ssh to another machine on the LAN ... ping
works, but ssh fails (as does http). OK, this one is very odd ... as I
do see the ping replies back through the gateway machine. And I see
traffic (ssh and http) leaving the “another machine”, but it’s not
seeming to get back to the OpenVPN client.

again, this still looks like a 'missing return route' issue to me.
Without routing tables from the VPN server and the local LAN router it
is impossible to tell, however.


HTH,

JJK

[Morris, Russell]

Thanks for the replies! And Selva had a good lead - the firewall (gateway machine ... running pfSense).

The gateway is blocking the traffic ... because the traffic incoming from the OpenVPN client is routed directly to the other machine on the LAN (bypassing the gateway, it's on the subnet so doesn't need to go to the gateway), but the return traffic is routed through the firewall / gateway (OpenVPN subnet) ... but as the firewall didn't see the initial traffic, it believes this is an issue and blocks it.

Make sense?

Thanks again,
... Russell


From: Jan Just Keijser [mailto:***@nikhef.nl]
Sent: Wednesday, July 12, 2017 5:12 AM
To: Morris, Russell <***@rkmorris.us>; Selva Nair <***@gmail.com>
Cc: openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Intermittent Connectivity

Hi Russell,

On 12/07/17 04:35, Morris, Russell wrote:
Hi,

Yep, iptables is set up. Actually, seeing some odd results, and some debugging with tcpdump (below). By all means comment if I'm doing something dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making it to the gateway (excellent!). But no reply. Thinking that's a route issue, but ...
what exactly is 'the gateway' ? your VPN server? your LAN router/gateway?
does the gateway have a return route for packets coming from the VPN subnet? which routes ARE listed on the gateway? is 172.16.1.0/24 included?


- if I ping from the gateway, to the OpenVPN client ... it works! Hmm .. so why is the gateway not replying. It does reply to pings on the LAN side.
are you sure that packets end up on the VPN client? did you verify this using tcpdump on the OpenVPN client?
sometimes masquerading/NATting might lead to unexpected results here.

If the gateway is your VPN server, then it does not surprise me that packets are getting through, nor that you can reach the client but not the LAN address of the gateway itself. A 'ping' to the OpenVPN client will use the vpn server's IP address as the source address, not the LAN address.



- if I ssh from the OpenVPN client to the gateway ... it connects. So perhaps ping is fooling me (not replying to that subnet?). But,
- if I try to ping or ssh to another machine on the LAN ... ping works, but ssh fails (as does http). OK, this one is very odd ... as I do see the ping replies back through the gateway machine. And I see traffic (ssh and http) leaving the "another machine", but it's not seeming to get back to the OpenVPN client.

again, this still looks like a 'missing return route' issue to me. Without routing tables from the VPN server and the local LAN router it is impossible to tell, however.


HTH,

JJK

[Selva Nair]

Hi Russel,

Thanks for the replies! And Selva had a good lead – the firewall (gateway
machine 
 running pfSense).
The gateway is blocking the traffic 
 because the traffic incoming from
the OpenVPN client is routed directly to the other machine on the LAN
(bypassing the gateway, it’s on the subnet so doesn’t need to go to the
gateway), but the return traffic is routed through the firewall / gateway
(OpenVPN subnet) 
 but as the firewall didn’t see the initial traffic, it
believes this is an issue and blocks it.
Make sense?

Very likely due to asymmetric routing as you suspect. To test, try
disabling firewall rules for traffic leaving and entering same interface on
pfsense. I have dabbled with pfsense only briefly a couple of times, so no
idea whether that is a safe long-term solution.

See also the docs here
https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules

Selva

[Jan Just Keijser]

Hi,

Thanks for the replies! And Selva had a good lead – the firewall
(gateway machine … running pfSense).
The gateway is blocking the traffic … because the traffic incoming
from the OpenVPN client is routed directly to the other machine on the
LAN (bypassing the gateway, it’s on the subnet so doesn’t need to go
to the gateway), but the return traffic is routed through the firewall
/ gateway (OpenVPN subnet) … but as the firewall didn’t see the
initial traffic, it believes this is an issue and blocks it.
Make sense?

you can test this by adding a direct route on a host on your LAN, e.g.
route add -net 172.16.1.0/24 gw <LAN-IP-of-VPN-server>

and then ping that host from the VPN client - traffic should not hit the
GW at all in this case. If that does work, then indeed you are looking
at an assymetric route+pfsense issue.

HTH,

JJK

*Sent:* Wednesday, July 12, 2017 5:12 AM
*Subject:* Re: [Openvpn-users] Intermittent Connectivity
Hi Russell,
Hi,
Yep, iptables is set up. Actually, seeing some odd results, and
some debugging with tcpdump (below). By all means comment if I’m
doing something dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making
it to the gateway (excellent!). But no reply. Thinking that's a
route issue, but ...
what exactly is 'the gateway' ? your VPN server? your LAN router/gateway?
does the gateway have a return route for packets coming from the VPN
subnet? which routes ARE listed on the gateway? is 172.16.1.0/24 included?
- if I ping from the gateway, to the OpenVPN client ... it works!
Hmm .. so why is the gateway not replying. It does reply to pings
on the LAN side.
are you sure that packets end up on the VPN client? did you verify
this using tcpdump on the OpenVPN client?
sometimes masquerading/NATting might lead to unexpected results here.
If the gateway is your VPN server, then it does not surprise me that
packets are getting through, nor that you can reach the client but not
the LAN address of the gateway itself. A 'ping' to the OpenVPN client
will use the vpn server's IP address as the source address, not the
LAN address.
- if I ssh from the OpenVPN client to the gateway ... it connects.
So perhaps ping is fooling me (not replying to that subnet?). But,
- if I try to ping or ssh to another machine on the LAN ... ping
works, but ssh fails (as does http). OK, this one is very odd ...
as I do see the ping replies back through the gateway machine. And
I see traffic (ssh and http) leaving the “another machine”, but
it’s not seeming to get back to the OpenVPN client.
again, this still looks like a 'missing return route' issue to me.
Without routing tables from the VPN server and the local LAN router it
is impossible to tell, however.
HTH,
JJK

[Morris, Russell]

Yep, that works. Thanks for all the help and suggestions - very much appreciated! And I can use the workaround Selva proposed - life is good ... :).

Have a nice weekend!

... Russell



From: Jan Just Keijser [mailto:***@nikhef.nl]
Sent: Friday, July 14, 2017 5:37 AM
To: Morris, Russell <***@rkmorris.us>; Selva Nair <***@gmail.com>
Cc: openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Intermittent Connectivity

Hi,

On 13/07/17 05:29, Morris, Russell wrote:
Thanks for the replies! And Selva had a good lead - the firewall (gateway machine ... running pfSense).

The gateway is blocking the traffic ... because the traffic incoming from the OpenVPN client is routed directly to the other machine on the LAN (bypassing the gateway, it's on the subnet so doesn't need to go to the gateway), but the return traffic is routed through the firewall / gateway (OpenVPN subnet) ... but as the firewall didn't see the initial traffic, it believes this is an issue and blocks it.

Make sense?

you can test this by adding a direct route on a host on your LAN, e.g.
route add -net 172.16.1.0/24 gw <LAN-IP-of-VPN-server>

and then ping that host from the VPN client - traffic should not hit the GW at all in this case. If that does work, then indeed you are looking at an assymetric route+pfsense issue.

HTH,

JJK




From: Jan Just Keijser [mailto:***@nikhef.nl]
Sent: Wednesday, July 12, 2017 5:12 AM
To: Morris, Russell <***@rkmorris.us><mailto:***@rkmorris.us>; Selva Nair <***@gmail.com><mailto:***@gmail.com>
Cc: openvpn-***@lists.sourceforge.net<mailto:openvpn-***@lists.sourceforge.net>
Subject: Re: [Openvpn-users] Intermittent Connectivity

Hi Russell,

On 12/07/17 04:35, Morris, Russell wrote:
Hi,

Yep, iptables is set up. Actually, seeing some odd results, and some debugging with tcpdump (below). By all means comment if I'm doing something dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making it to the gateway (excellent!). But no reply. Thinking that's a route issue, but ...
what exactly is 'the gateway' ? your VPN server? your LAN router/gateway?
does the gateway have a return route for packets coming from the VPN subnet? which routes ARE listed on the gateway? is 172.16.1.0/24 included?



- if I ping from the gateway, to the OpenVPN client ... it works! Hmm .. so why is the gateway not replying. It does reply to pings on the LAN side.
are you sure that packets end up on the VPN client? did you verify this using tcpdump on the OpenVPN client?
sometimes masquerading/NATting might lead to unexpected results here.

If the gateway is your VPN server, then it does not surprise me that packets are getting through, nor that you can reach the client but not the LAN address of the gateway itself. A 'ping' to the OpenVPN client will use the vpn server's IP address as the source address, not the LAN address.




- if I ssh from the OpenVPN client to the gateway ... it connects. So perhaps ping is fooling me (not replying to that subnet?). But,
- if I try to ping or ssh to another machine on the LAN ... ping works, but ssh fails (as does http). OK, this one is very odd ... as I do see the ping replies back through the gateway machine. And I see traffic (ssh and http) leaving the "another machine", but it's not seeming to get back to the OpenVPN client.

again, this still looks like a 'missing return route' issue to me. Without routing tables from the VPN server and the local LAN router it is impossible to tell, however.


HTH,

JJK

[Selva Nair]

Hi Russel,

Post by Morris, Russell
Yep, iptables is set up. Actually, seeing some odd results, and some
debugging with tcpdump (below). By all means comment if I’m doing something
dumb (which is entirely likely)!
- if I ping from the OpenVPN client, I see the icmp packet making it to
the gateway (excellent!). But no reply. Thinking that's a route issue, but
...
- if I ping from the gateway, to the OpenVPN client ... it works! Hmm ..
so why is the gateway not replying. It does reply to pings on the LAN side.
- if I ssh from the OpenVPN client to the gateway ... it connects. So
perhaps ping is fooling me (not replying to that subnet?). But,

As your gateway router is different from the server, this shows you have
all the required routes.

Post by Morris, Russell
- if I try to ping or ssh to another machine on the LAN ... ping works,
but ssh fails (as does http). OK, this one is very odd ... as I do see the
ping replies back through the gateway machine. And I see traffic (ssh and
http) leaving the “another machine”, but it’s not seeming to get back to
the OpenVPN client.

Possibly you have a firewall on the gateway that stops this traffic. For
e.g., the gateway may be forwarding only to certain subnets.

Selva

[Jan Just Keijser]

Hi,

Post by David Sommerseth

Post by Morris, Russell
Hi,
OK, pulling my hair out with this. I haven't really seen this before,
but having issues with intermittent connectivity (lately, also with
the latest versions of OpenVPN). I noticed it over SSH (connection
seems to hang for periods of time), so then I tried ping => results
below, and quite interesting (and very variable).
In case someone asks - I am running over TCP, but have never seen
this before (so I'm not sure that's really the issue). I did try
connecting to a second machine (different location) ... and that
seems OK (but it's running TUN, vs. TAP - part of the issue?).

[...snip...]

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.

agreed, but do note that Morris is sending ICMP packets inside the tunnel - so that rules out some of the TCP-over-TCP badness.
It would be interesting to see the simultaneous ping results *outside* the tunnel, i.e. between client and VPN server.

Post by David Sommerseth

Post by Morris, Russell
And yes, I do need TAP, as I need to bridge onto the subnet (to
access different machines remotely).

"to access different machines remotely" is very seldom a good argument
for bridging. If your remote machines understands TCP/IP routing
properly, you will most likely have a far better result using a routed
TUN setup, with the VPN link (tun adapters) residing in their own
subnet. This will remove a lot of broadcast traffic, which can eat up
the bandwidth - especially there's lots of broadcast chatter on both
sides of the tunnel. Plus the packets transported between the VPN
client and server is also a bit smaller, as it doesn't need the Ethernet
frame (which contains MAC addresses among others).
Those scenarios where bridging really makes sense are for non-TCP/IP
protocols or where the application protocol really depends on broadcast
traffic (like older LAN games). If you think of Windows file shares, it
is far better to use WINS, which works very well over routed TUN.

again, I fully agree with David, *BUT* Microsoft has declared WINS to be dead; it's even so bad that there are DoS holes in the
WINS server that they will not fix; you should switch to DNS/AD style name serving instead.

JJK

[David Sommerseth]

Post by Jan Just Keijser
Hi,

Post by David Sommerseth

Post by Morris, Russell
Hi,
OK, pulling my hair out with this. I haven't really seen this before,
but having issues with intermittent connectivity (lately, also with
the latest versions of OpenVPN). I noticed it over SSH (connection
seems to hang for periods of time), so then I tried ping => results
below, and quite interesting (and very variable).
In case someone asks - I am running over TCP, but have never seen
this before (so I'm not sure that's really the issue). I did try
connecting to a second machine (different location) ... and that
seems OK (but it's running TUN, vs. TAP - part of the issue?).

[...snip...]

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.

agreed, but do note that Morris is sending ICMP packets inside the
tunnel - so that rules out some of the TCP-over-TCP badness.
It would be interesting to see the simultaneous ping results *outside*
the tunnel, i.e. between client and VPN server.

Post by David Sommerseth

Post by Morris, Russell
And yes, I do need TAP, as I need to bridge onto the subnet (to
access different machines remotely).

"to access different machines remotely" is very seldom a good argument
for bridging. If your remote machines understands TCP/IP routing
properly, you will most likely have a far better result using a routed
TUN setup, with the VPN link (tun adapters) residing in their own
subnet. This will remove a lot of broadcast traffic, which can eat up
the bandwidth - especially there's lots of broadcast chatter on both
sides of the tunnel. Plus the packets transported between the VPN
client and server is also a bit smaller, as it doesn't need the Ethernet
frame (which contains MAC addresses among others).
Those scenarios where bridging really makes sense are for non-TCP/IP
protocols or where the application protocol really depends on broadcast
traffic (like older LAN games). If you think of Windows file shares, it
is far better to use WINS, which works very well over routed TUN.

again, I fully agree with David, *BUT* Microsoft has declared WINS to
be dead; it's even so bad that there are DoS holes in the WINS server
that they will not fix; you should switch to DNS/AD style name serving
instead.

Thanks! :) As I'm not an active Windows user, I just re-iterate what
has been said for many years - and I was not aware of the DoS holes ...
no real excuse, but thanks for point that out! I agree DNS/AD is far
better though.


--
kind regards,

David Sommerseth

[Morris, Russell]

Yep, agreed - and have DNS (on the subnet) up and running. Need to follow the instructions in the other email, see if I can get that up and running over TUN.

FYI, I can't send ICMP outside the tunnel - it gets blocked (doesn't get out) ... ☹.

Thanks!

... Russell




-----Original Message-----
From: Jan Just Keijser [mailto:***@nikhef.nl]
Sent: Friday, July 7, 2017 9:38 AM
To: openvpn-***@lists.sourceforge.net; Morris, Russell <***@rkmorris.us>
Subject: Re: [Openvpn-users] Intermittent Connectivity

Hi,

Post by David Sommerseth

Post by Morris, Russell
Hi,
OK, pulling my hair out with this. I haven't really seen this before,
but having issues with intermittent connectivity (lately, also with
the latest versions of OpenVPN). I noticed it over SSH (connection
seems to hang for periods of time), so then I tried ping => results
below, and quite interesting (and very variable).
In case someone asks - I am running over TCP, but have never seen
this before (so I'm not sure that's really the issue). I did try
connecting to a second machine (different location) ... and that
seems OK (but it's running TUN, vs. TAP - part of the issue?).

[...snip...]

Post by Morris, Russell
Thoughts? Things to try?

This looks like a typical wacky connection between client and server.
And using --proto tcp with wacky connections, things tends to get ugly
quickly. And especially when sending TCP packets inside the tunnel.
That results in a lot of "resend this packet" requests both on the
inside and outside of the tunnel. So try switching to --proto udp.

agreed, but do note that Morris is sending ICMP packets inside the tunnel - so that rules out some of the TCP-over-TCP badness.
It would be interesting to see the simultaneous ping results *outside* the tunnel, i.e. between client and VPN server.

Post by David Sommerseth

Post by Morris, Russell
And yes, I do need TAP, as I need to bridge onto the subnet (to
access different machines remotely).

"to access different machines remotely" is very seldom a good argument
for bridging. If your remote machines understands TCP/IP routing
properly, you will most likely have a far better result using a routed
TUN setup, with the VPN link (tun adapters) residing in their own
subnet. This will remove a lot of broadcast traffic, which can eat up
the bandwidth - especially there's lots of broadcast chatter on both
sides of the tunnel. Plus the packets transported between the VPN
client and server is also a bit smaller, as it doesn't need the
Ethernet frame (which contains MAC addresses among others).
Those scenarios where bridging really makes sense are for non-TCP/IP
protocols or where the application protocol really depends on
broadcast traffic (like older LAN games). If you think of Windows
file shares, it is far better to use WINS, which works very well over routed TUN.

again, I fully agree with David, *BUT* Microsoft has declared WINS to be dead; it's even so bad that there are DoS holes in the WINS server that they will not fix; you should switch to DNS/AD style name serving instead.

JJK