No route to host - DNS works

[USA-RedDragon]

After using TrueNAS Core for many years, I finally swapped over to TrueNAS Scale Bluefin a couple of weeks ago. Since then, I've been having network connectivity issues.

My gateway is IPV4 only at 192.168.1.3/24
Running `ip route` shows the routes look sane:

```
root@truenas[~]# ip r
default via 192.168.1.3 dev enp3s0 proto static
10.134.0.0/24 dev wg0 proto kernel scope link src 10.134.0.1
172.16.0.0/16 dev kube-bridge proto kernel scope link src 172.16.0.1
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.135
```

Using dig shows that DNS is working
```
root@truenas[~]# dig google.com

; <<>> DiG 9.16.27-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46224
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 29 IN A 192.178.48.142

;; Query time: 0 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Thu Apr 27 11:30:02 CDT 2023
;; MSG SIZE rcvd: 55
```

I can ping things that are local:

```
root@truenas[~]# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.243 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.262 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.253 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.324 ms
^C
--- 192.168.1.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3055ms
rtt min/avg/max/mdev = 0.243/0.270/0.324/0.031 ms
root@truenas[~]# ping 192.168.1.88
PING 192.168.1.88 (192.168.1.88) 56(84) bytes of data.
64 bytes from 192.168.1.88: icmp_seq=1 ttl=64 time=0.269 ms
64 bytes from 192.168.1.88: icmp_seq=2 ttl=64 time=0.554 ms
^C
--- 192.168.1.88 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1028ms
rtt min/avg/max/mdev = 0.269/0.411/0.554/0.142 ms
```

But aiming for anything else on the public IP space shows:
```
root@truenas[~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.134.0.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.134.0.1 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Destination address required
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1027ms
```

```
root@truenas[~]# curl -v https://google.com
* Trying 142.250.138.100:443...
* connect to 142.250.138.100 port 443 failed: No route to host
* Trying 142.250.138.102:443...
* connect to 142.250.138.102 port 443 failed: No route to host
* Trying 142.250.138.138:443...
* connect to 142.250.138.138 port 443 failed: No route to host
* Trying 142.250.138.139:443...
* connect to 142.250.138.139 port 443 failed: No route to host
* Trying 142.250.138.101:443...
* connect to 142.250.138.101 port 443 failed: No route to host
* Trying 142.250.138.113:443...
* connect to 142.250.138.113 port 443 failed: No route to host
* Trying 2607:f8b0:4000:805::200e:443...
* Immediate connect fail for 2607:f8b0:4000:805::200e: Network is unreachable
* Failed to connect to google.com port 443: No route to host
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: No route to host
```

This issue affects update checking and apps that are present on the system as well.

 

[USA-RedDragon]

Attaching output of `iptables -L -n -v` for completeness

 

[WingM]

Hi,
I have exaxtly the same issue. Did you find a solution?

 

[WingM]

OK, I could solve this issue for me - finally!

But let's start at the beginning. What was my problem:
I used an eth interface and I am using sevaral docker instances and an openvpn server. My docker applications worked find from my local network, but using OpenVPN I had no connection to any docker instance.

I found the solution in the first answer of this thread https://www.truenas.com/community/threads/vms-cant-see-host.88517/
So, I created the bridge accordingly, but I activated the "DHCP" option on the physical interface. With this configuraiton I got exactly the issue described in this thread. By deactivating this option everythings works like a charm (by also using IPv6).