Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    After upgrade to 2.4.0 | issue with LAN connectivity [SOLVED]

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    7 Posts 2 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      D-Kun
      last edited by

      Hi folks,

      currently experiencing the issue that all LAN-clients are not able to reach the Gateway/Internet. This problem came up right after the upgrade from 2.3.x at 3 different systems.

      • @Hyper-v host + @Proxmox/KVM host + barebone host

      While changeing the "Upstream-Gateway" at the LAN-interface setting I was able to send 4 ICMP-requests during apply. But then reachability stopped again.

      Do you have any hint how to fix that?

      • All LAN-clients are allowed to access any destination.
      • at this allow all from lan to any rule within the firewall configuration I see the connection attempts
      • disabling the firewall does not show up any success
      • interfaces are all up and addressed
      • access from WAN to the pf's is possible - thats all =/
      • I am seeing the

      Greetings

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        You do not set an upstream gateway on a LAN interface. That is almost never correct and never has been correct except in certain rare circumstances.

        Setting an upstream gateway on an interface makes it a WAN.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • D
          D-Kun
          last edited by

          Hi Derelict,

          it was just a try by setting the "upstream gateway" @LAN. Even when its set to "none" (as it should be) there is no connection.
          Just during the time when the changes are beeing applied I get 4 icmps out and then it stops working again.

          Greetings

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Going to need more information.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • D
              D-Kun
              last edited by

              Hi,

              basically its a very simple setup:
              Two interfaces (WAN and LAN), I can access the pfsense through WAN from internet.
              The gateway configured at the WAN-interface is the default gateway. There is only a little bunch of NAT-rules to LAN clients (http/https/ssh) configured on.

              Clients behind the LAN-interface are addressed static with the default GW of our beloved pfsense and its LAN-interface.
              There are just these 3 default rules at the firewall LAN-tab (antilockout, allow from/to all for ipv4 and same for ipv6)

              Arp-resolution does work - pfsense recognizes the clients vice-versa. I even see the connection attempts @tcpdump.

              
tcpdump -i hn1 -vn
tcpdump: listening on hn1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:22:43.994255 IP (tos 0x0, ttl 64, id 51753, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.4.11 > 192.168.4.1: ICMP echo request, id 28245, seq 488, length 64
19:22:44.994238 IP (tos 0x0, ttl 64, id 51951, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.4.11 > 192.168.4.1: ICMP echo request, id 28245, seq 489, length 64
19:22:45.994124 IP (tos 0x0, ttl 64, id 52072, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.4.11 > 192.168.4.1: ICMP echo request, id 28245, seq 490, length 64
19:22:46.994223 IP (tos 0x0, ttl 64, id 52116, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.4.11 > 192.168.4.1: ICMP echo request, id 28245, seq 491, length 64

              When I am connecting remotely with OpenVPN, then I am able to reach the LAN-IP of the pfsense. But I am not able to access the LAN-clients. Even through the Site2Site tunnels I reach the LAN-IPs of these pfsenses (when using a remote/"road-warrior" client), but anyway not able to reach any of the LAN-clients.

              
netstat -rn output:

Internet:
Destination                       Gateway                            Flags     Netif Expire
default                           87.x.x.1                              UGS         hn0
10.10.10.1                        link#6                                 UHS         lo0
10.10.10.1/32                     link#6                                 U           hn1
WAN-Monitor-IP                    87.x.x.1 (WAN-Gateway)   UGHS        hn0
87.x.x.0/24                       link#5                                 U           hn0
87.x.x.y (pf-WAN-IP)             link#5                                UHS         lo0
87.x.x.2 (IP-alias)              link#5                                UHS         lo0
87.x.x.2/32                       link#5                                 U           hn0
87.x.x.y (pf-WAN-IP)             link#5                                UHS         lo0
87.x.x.y (pf-WAN-IP) /32         link#5                                U           hn0
127.0.0.1                          link#1                                UH          lo0
178.x.x.237 (Site2Site peer that is monitored) 87.x.x.1(WAN-Gateway)       UGHS        hn0
192.168.4.0/24 (LAN-Network)     link#6                                U           hn1
192.168.4.1                      link#6                               UHS         lo0
192.168.4.11(LAN-Monitor-IP)       192.168.4.1(pfsense-LAN-IP)        UGHS        hn1

              Everything was working like charm before the upgrade. And no changes to the firewall or the routing was done.
              If you need more information please let it me know.

              Greetings

              gateways.png
              gateways.png_thumb
              lan-fw-setting.png
              lan-fw-setting.png_thumb
              lan-interface.png
              lan-interface.png_thumb
              states-lan-allow-all.png
              states-lan-allow-all.png_thumb

              1 Reply Last reply Reply Quote 0
              • D
                D-Kun
                last edited by

                Hi folks,

                found the issue after some time - deactivating the Monitor-IP for LAN (checkbox) did not help - the Monitor-IP must be removed completely from the gateway configuration.

                Hosts that are defined as Monitor-IP for the gateway are unable to send or receive ANY traffic. Not even arp-ping is possible. I do not how to fix that issue, I guess it's a bug that came up.

                Greetings

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  It is not a bug. Host addresses that are defined as a monitor IP address have a specific host route out the interface they are defined on.

                  Same thing with DNS servers in System > General if you define a gateway there.

                  This is necessary for Multi-WAN, which is a feature people seem to like.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.