[SOLVED] LAN clients lost outside connection after upgrade to 2.4.4 [2.4.5-DEV]
-
After upgrading to 2.4.4 my LAN clients are unable to resolve any addresses. There were interferences with
haproxy, I uninstalled the package.
I then upgraded to 2.4.5, same issue.DNS Resolveris running withForwarding mode enabled.pfsense can perfectly resolve:
Result Record type
172.217.21.238 A
2a00:1450:4001:815::200e AAAA
Timings
Name server Query time
127.0.0.1 20 msec
208.67.222.222 7 msec
208.67.220.220 7 msec
8.8.8.8 11 msecDHCP Server has OpenDNS servers filled in.
Tests on one of the lan clients:
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
Meaning this is not a DNS issue.Outbound NAT mode is automatic, and the rule is still present.
Any help much appreciated, I'm at a loss.
-
@rosch
ping 8.8.8.8does not need DNS to function. TheNetwork is unreachablehowever seems to indicate that you have some kind of routing issue.. Please check if you have a default-gateway configured on system/routing page. -
Gateways:
-
The Routing log shows this:
32990 attempting to reread config file
radvd 32990 invalid all-zeros prefix in /var/etc/radvd.conf, line 9 -
@rosch
Okay, that might indicate some issue with IPv6.. Does your ISP supply IPv6 ?Anyhow the
ping 8.8.8.8is using IPv4.. Can you check diagnoistics/routes, and to be sure also check the default-route on the workstation? -
Here my main routes, to me it looks good. I cut out some openvpn lines, it's not running anyway. LAN is
192.168.1.0.
workstation route:
192.168.1.0 * 255.255.255.0 U 0 0 0 br0ISP IPv6: I think IPv6 is supported, but the current WAN is IPv4.
-
@rosch
Does the workstation also have a default route ? -
@piba this is the full output:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.3.0 * 255.255.255.0 U 0 0 0 lxcbr0
10.0.5.0 * 255.255.255.0 U 0 0 0 docker0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
169.254.0.0 * 255.255.0.0 U 0 0 0 mgmt0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0It's a QNAP machine, the only one client I have access to to test.
-
@rosch
Seems to me like default route is missing then.. the ip on the qnap is statically configured? then you need to add a default route / default gateway on it somewhere.. -
It's not statically configured,
but in pfsense there's a reservation for it.In DHCP Server, I added
192.168.1.1as the gateway, restarted QNAP's networking, but no luck. -
@rosch
The192.168.1.1probably was already send 'by default'.. Would be easy to check if you had another client to put on that network, see if it picks up the proper default-route.. Now you might be able do a packet capture and analyze it with Wireshark.. That should show the dhcp packet indicating the default-route...Or perhaps check qnap's logs see if it shows anything.?. ive never seen a qnap so cant really guide much there.
-
Ok I'll check but it's not a QNAP issue because my solar inverter also has lost connection.
-
Under LAN, Reserved Networks I had
Block private networks and loopback addressesenabled..so I was shooting myself in the foot
. After unchecking, normal function resumed.Sorry about that, and thanks for your help.
-
@rosch
Ay, that would cause issues indeed for a private-network.. Surely explains the solar-inverter was not having internet access. Not sure why the qnap wouldn't show its default-route though. Does it show it now? (Just interested for my own education..) -
@piba said in [SOLVED] LAN clients lost outside connection after upgrade to 2.4.4 [2.4.5-DEV]:
@rosch
Does it show it now? (Just interested for my own education..)It does:
default 192.168.1.1 0.0.0.0 UG 100 0 0 br0 -
@rosch
Okay, would have thought that would be there even if traffic was blocked. Perhaps is has some dynamic gateway monitoring or something that told it not to define that route when it wasn't available. The dhcp packet from pfSense side wouldn't be any different though afaik. But well its fixed :) i guess no further investigation is needed just to satisfy my curiosity
. Thanks for reporting back 