SOLVED TN12-U8.1 No ping response if pinging W10 PC with ProtonVPN free.

[Paul5]

All PC's can ping each other including TN. The ProtonVPN W10 PC can also ping TN successfully but for some reason as long as ProtonVPN is running TN cannot get a ping response on the PC running ProtonVPN, hence TN shutsdown as per the script I run.

I tried changing packet size but that did nothing. Is there something specific about TN's ping that ProtonVPN would block/break.

 

[Samuel Tai]

You'll need to implement split tunneling on the ProtonVPN PC, and exempt the TrueNAS IP from the tunnel.

Split tunneling on Windows and Android - Proton VPN Support

Split tunneling is a feature that allows you to route some connections through the VPN tunnel while excluding others

protonvpn.com

 

[Paul5]

You'll need to implement split tunneling on the ProtonVPN PC, and exempt the TrueNAS IP from the tunnel.

Sorry, I should have mentioned I already have it. It has made no difference as all the other PC and router are not on the list and have no problems with receiving ping responses back from the Proton PC.

I don't think it's a Proton problem for it responds to the others only not TN. It may be how TN Pings or what it's getting back doesn't make sense to it.

No Idea.

 

[Samuel Tai]

Please provide the HW details of your TrueNAS server, as per the Forum Rules.

 

[Paul5]

Please provide the HW details of your TrueNAS server

It's not a hardware issue.

1- Changed NIC from PCI to Onboard NIC which is a different brand and same result. Ping failure

2- via cli cleared and re-did NIC/s several times and failure.

3- Loaded a Linux Mint version and Pinged the same address with ProtonVPN, Success. Ping response. Rebooted back into TN and failure.

Common denominator is TN and whatever or however it controls the pings. I tried different ifconfig settings and nothing, I also tried different ping settings and again nothing. I'm assuming it might be something with TN's ICMP?

*-core
description: Motherboard
product: P7P55D LE
vendor: ASUSTeK Computer INC.

*-cpu
description: CPU
product: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz

*-network
description: Ethernet interface
product: 82540EM Gigabit Ethernet Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:05:02.0
logical name: enp5s2
version: 02
serial:
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 66MHz
capabilities: pm pcix msi bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000 driverversion=5.13.0-22-generic duplex=full ip= latency=64 link=yes mingnt=255 multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:17 memory:f7fe0000-f7ffffff memory:f7fc0000-f7fdffff ioport:ec00(size=64) memory:f7fa0000-f7fbffff

 

[Samuel Tai]

Try running tcpdump 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply' on TrueNAS during your ping tests (you'll need multiple PuTTY sessions) so you can see if the ICMP packets are actually leaving the TrueNAS server, and what replies it sees coming back.

 

[Paul5]

From what I can tell the depending on the tcpdump command used the results are either the same for VPN ON or OFF or one does nothing for VPN ON and something for VPN OFF. Maybe you can see something. I also did with and without -v for verbose.

In all cases ping command used is ping -c 4 192.168.68.116

VPN ON > no ping response - nothing changes.

root@truenas:~ # tcpdump 'icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes

VPN OFF > ping response.

root@truenas:~ # tcpdump 'icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:32:00.714291 IP Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 17935, seq 0, length 64
12:32:01.780719 IP Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 17935, seq 1, length 64
12:32:02.791105 IP Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 17935, seq 2, length 64
12:32:03.822253 IP Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 17935, seq 3, length 64

VPN ON > -v no ping response.

root@truenas:~ # tcpdump -v 'icmp[icmptype] == icmp-echoreply'
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes

VPN OFF -v ping response

root@truenas:~ # tcpdump -v 'icmp[icmptype] == icmp-echoreply'
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:45:59.927830 IP (tos 0x0, ttl 128, id 24797, offset 0, flags [none], proto ICMP (1), length 84)
Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 57872, seq 0, length 64
12:46:00.931174 IP (tos 0x0, ttl 128, id 24800, offset 0, flags [none], proto ICMP (1), length 84)
Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 57872, seq 1, length 64
12:46:01.945187 IP (tos 0x0, ttl 128, id 24803, offset 0, flags [none], proto ICMP (1), length 84)
Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 57872, seq 2, length 64
12:46:02.976133 IP (tos 0x0, ttl 128, id 24806, offset 0, flags [none], proto ICMP (1), length 84)
Lenovo-S20 > 192.168.68.116: ICMP echo reply, id 57872, seq 3, length 64

Using other tcmp command.

VPN OFF/On. Ping and no ping response output is the same as below.

root@truenas:~ # tcpdump 'icmp[icmptype] == icmp-echo'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:35:47.187560 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 46095, seq 0, length 64
12:35:48.200781 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 46095, seq 1, length 64
12:35:49.258774 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 46095, seq 2, length 64
12:35:50.292845 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 46095, seq 3, length 64
12:36:16.325595 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 52751, seq 0, length 64
12:36:17.334211 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 52751, seq 1, length 64
12:36:18.368800 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 52751, seq 2, length 64
12:36:19.427798 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 52751, seq 3, length 64
12:36:32.547472 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 53775, seq 0, length 64
12:36:33.551820 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 53775, seq 1, length 64
12:36:34.611839 IP 192.168.68.116 > Lenovo-S20: ICMP echo request, id 53775, seq 2, length 64

VPN ON but using -v for verbose > No Ping Response.

root@truenas:~ # tcpdump -v 'icmp[icmptype] == icmp-echo'
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:40:31.361823 IP (tos 0x0, ttl 64, id 32296, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f664)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 9744, seq 0, length 64
12:40:32.392884 IP (tos 0x0, ttl 64, id 32299, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f661)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 9744, seq 1, length 64
12:40:33.445701 IP (tos 0x0, ttl 64, id 32300, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f660)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 9744, seq 2, length 64
12:40:34.478813 IP (tos 0x0, ttl 64, id 17973, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->2e58)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 9744, seq 3, length 64

VPN OFF using -v verbose > Ping response result same as above.

root@truenas:~ # tcpdump -v 'icmp[icmptype] == icmp-echo'
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:42:22.160463 IP (tos 0x0, ttl 64, id 39356, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->dad0)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 24848, seq 0, length 64
12:42:23.194785 IP (tos 0x0, ttl 64, id 32301, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f65f)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 24848, seq 1, length 64
12:42:24.218753 IP (tos 0x0, ttl 64, id 17980, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->2e51)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 24848, seq 2, length 64
12:42:25.229350 IP (tos 0x0, ttl 64, id 17981, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->2e50)!)
192.168.68.116 > Lenovo-S20: ICMP echo request, id 24848, seq 3, length 64

 

[Paul5]

It looks like the main issue is with Proton VPN. Though it doesn't explain why it only affects TrueNAS Ping and as I found out LAN speed.

Very long story short:

Originally with the 2 week old version I was using I could not ping the Proton PC:

1- I added the server's IP to Proton VPN Split Tunneling. No effect, everything I tried failed.

2- Advised to update to latest.

3- I updated and no effect. Problem persisted.

4- A CLUE! I noted that my LAN transfers are also slow. (My range) > 192.168.0.0 - 192.168.255.255

5- I disabled Split Tunnelling and I can Ping Protonvpn PC and My LAN speed is back to normal.

6- I deleted the LAN Servers IP from split tunnelling and my sever can now stay alive and my LAN speed is back to normal.

It went from one bug of nothing to another if IP kept in Split Tunnelling.

To my understanding apparently with Proton vpn when using certain IP ranges as mine above there is no requirement to add the IP's to Split Tunnelling. The way I understand it should make no difference, yet it cripples TN, no Ping response and LAN speed loss is > 2/3s both uploads and downloads.

That,s been a waste of time I'm never going to get back!