I have a very simple two-machine vpn connected by a single ethernet cable. When the machines are connected, the vpn functions as expected. However if I unplug the ethernet cable from one of the machines, any process that tries to use the vpn hangs awfully. Some sleuthing with ping and tcpdump has revealed that the tun0 interface on either machine happily sends ICMP echo requests off into the void and never returns anything. My expectation (as exhibited by the physical network interfaces in this situation) would be to get an ICMP destination host unreachable code back in a matter of seconds. This would allow processes trying to use the network to get on with their lives. So, the question. Why doesn't tun0 return host unreachable when the machines have been physically disconnected? Is there a setting I need to use to make this happen? [oconf=server.conf]port [port] proto udp tls-server dev tun ca [location] cert [location] key [location] askpass [location] dh [location] server [address] [netmask] ifconfig-pool-persist ipp.txt client-config-dir [location] client-to-client keepalive 10 120 tls-auth [location] cipher AES-256-CBC tls-version-min 1.2 auth SHA512 auth-nocache user nobody group nobody persist-key persist-tun status [location] log-append [location] writepid [location] verb 5 explicit-exit-notify 1[/oconf] [oconf=client.conf]client dev tun proto udp tls-client remote [server ip] [server port] resolv-retry infinite nobind user nobody group nobody persist-key persist-tun ca [location] cert [location] key [location] askpass [location] remote-cert-tls server tls-auth [location] cipher AES-256-CBC tls-version-min 1.2 auth SHA512 auth-nocache log-append [location] writepid [location] verb 5[/oconf] Here's a comparison of ping and tcpdump output for unreachable LAN and vpn addresses. Physical ping (expected behavior): [code]PING X.X.X.X (X.X.X.X) 56(84) bytes of data. From Y.Y.Y.Y icmp_seq=2 Destination Host Unreachable From Y.Y.Y.Y icmp_seq=3 Destination Host Unreachable From Y.Y.Y.Y icmp_seq=4 Destination Host Unreachable # Ctrl^C here, note host unreachable --- X.X.X.X ping statistics --- 6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5704ms pipe 3[/code] Output from tcpdump: [code]# No output[/code] VPN ping (problematic behavior): [code]PING X.X.X.X (X.X.X.X) 56(84) bytes of data. # Ctrl^C here, note no output --- X.X.X.X ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8393ms [/code] tcpdump output: [code]10:35:53.143517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 1, length 64 10:35:53.830677 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5565, length 64 10:35:54.142666 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 2, length 64 10:35:54.830766 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5566, length 64 10:35:55.142717 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 3, length 64 10:35:55.830729 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5567, length 64 10:35:56.142698 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 4, length 64 10:35:56.830686 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5568, length 64 10:35:57.142676 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 5, length 64 # ICMP echo reply and ICMP host unreachable are never returned[/code]

[quote=GraphTheory post_id=88288 time=1575655074 user_id=48650] However if I unplug the ethernet cable from one of the machines [/quote]You get what you pay for .. your test is about as cheap as they come. You may also want to [i]search[/i] for "UDP connectionless protocol"

No ICMP Destination Host Unreachable when physically disconnected

GraphTheory

I have a very simple two-machine vpn connected by a single ethernet cable. When the machines are connected, the vpn functions as expected. However if I unplug the ethernet cable from one of the machines, any process that tries to use the vpn hangs awfully. Some sleuthing with ping and tcpdump has revealed that the tun0 interface on either machine happily sends ICMP echo requests off into the void and never returns anything. My expectation (as exhibited by the physical network interfaces in this situation) would be to get an ICMP destination host unreachable code back in a matter of seconds. This would allow processes trying to use the network to get on with their lives.

So, the question. Why doesn't tun0 return host unreachable when the machines have been physically disconnected? Is there a setting I need to use to make this happen?

port [port]
proto udp
tls-server
dev tun
ca [location]
cert [location]
key [location]
askpass [location]
dh [location]
server [address] [netmask]
ifconfig-pool-persist ipp.txt
client-config-dir [location]
client-to-client
keepalive 10 120
tls-auth [location]
cipher AES-256-CBC
tls-version-min 1.2
auth SHA512
auth-nocache
user nobody
group nobody
persist-key
persist-tun
status [location]
log-append [location]
writepid [location]
verb 5
explicit-exit-notify 1

client
dev tun
proto udp
tls-client
remote [server ip] [server port]
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca [location]
cert [location]
key [location]
askpass [location]
remote-cert-tls server
tls-auth [location]
cipher AES-256-CBC
tls-version-min 1.2
auth SHA512
auth-nocache
log-append [location]
writepid [location]
verb 5

Here's a comparison of ping and tcpdump output for unreachable LAN and vpn addresses.

Physical ping (expected behavior):

PING X.X.X.X (X.X.X.X) 56(84) bytes of data.
From Y.Y.Y.Y icmp_seq=2 Destination Host Unreachable
From Y.Y.Y.Y icmp_seq=3 Destination Host Unreachable
From Y.Y.Y.Y icmp_seq=4 Destination Host Unreachable

# Ctrl^C here, note host unreachable

--- X.X.X.X ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5704ms
pipe 3

Output from tcpdump:

# No output

VPN ping (problematic behavior):

PING X.X.X.X (X.X.X.X) 56(84) bytes of data.

# Ctrl^C here, note no output

--- X.X.X.X ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8393ms

tcpdump output:

10:35:53.143517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 1, length 64
10:35:53.830677 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5565, length 64
10:35:54.142666 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 2, length 64
10:35:54.830766 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5566, length 64
10:35:55.142717 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 3, length 64
10:35:55.830729 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5567, length 64
10:35:56.142698 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 4, length 64
10:35:56.830686 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 22297, seq 5568, length 64
10:35:57.142676 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 21800, seq 5, length 64

# ICMP echo reply and ICMP host unreachable are never returned

Pippin

My take would be:
tun0 is just shuffling packets just like any interface, there is no host in between to send back a host unreachable.
Your LAN gateway is sending host unreachable.

GraphTheory

Sorry if I'm misunderstanding what you mean by LAN gateway, but this is just two machines connected by an ethernet cable. I'm assuming this means that the hardware/firmware for the ethernet port is giving back host unreachable before the echo request goes out on the ethX interface. Why would the behavior for tun0 be different in that case?

TinCanTech

GraphTheory wrote However if I unplug the ethernet cable from one of the machines

You get what you pay for .. your test is about as cheap as they come.

You may also want to search for "UDP connectionless protocol"

GraphTheory

I've tried using TCP mode instead, and the behavior is exactly the same.

EDIT: I hope I'm getting a better picture of what's happening here. When I receive host unreachable from ping, the source of that code is that machine's physical IP address. But if I restrict output of tcpdump to the ethX interface, I don't see that code. So ethX isn't actually the thing responsible for handing back host unreachable, it's...the networking hardware. Or firmware. Or whatever. Point is it's not the interface.

But the vpn interface is encrypted, so a ping across the vpn is encrypted. Which means whatever is responsible for host unreachable can't tell it's a ping? Maybe? But then how does tcpdump know it's a ping? I'm clearly still not understanding something about how exactly a ping across the vpn differs from a ping across the regular ethernet interface.