[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 Resolver is running with Forwarding 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 msec

    DHCP 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.
    0_1538844535160_Screenshot from 2018-10-06 18-48-04.png

    Any help much appreciated, I'm at a loss.



  • @rosch
    ping 8.8.8.8 does not need DNS to function. The Network is unreachable however 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:
    0_1538846232865_routing.jpg



  • 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.8 is 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.
    0_1538848655607_routes.jpg

    workstation route:
    192.168.1.0 * 255.255.255.0 U 0 0 0 br0

    ISP 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 br0

    It'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.1 as the gateway, restarted QNAP's networking, but no luck.



  • @rosch
    The 192.168.1.1 probably 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 addresses enabled..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 👍