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

    Static Configuration won't work - Ideas where to look?

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    36 Posts 6 Posters 10.7k 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.
    • stephenw10S Online
      stephenw10 Netgate Administrator
      last edited by

      If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.

      Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.

      Steve

      1 Reply Last reply Reply Quote 0
      • N Offline
        natelabo
        last edited by

        @stephenw10:

        If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.

        Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.

        Steve

        Well I'm still here… I got ticked off because I want to solve this. I have set the monitoring to watch 8.8.8.8. The status is now saying online but I still have no connection on my internal LAN devices.

        I have run almost every test on the webconfigurator available. Nothing fails! It has been like this since the beginning. nslookup = good, ping LAN and WAN (google, ebay, and 8.8.8.8) = all good, tracert (google, ebay) = all working. Still my devices on internal LAN cannot resolve past the pfsense gateway address (192.168.0.1) as shown in the picture way earlier.

        1 Reply Last reply Reply Quote 0
        • stephenw10S Online
          stephenw10 Netgate Administrator
          last edited by

          Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out.  Have you added/removed any firewall rules.

          Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:

          Steve

          1 Reply Last reply Reply Quote 0
          • N Offline
            natelabo
            last edited by

            @stephenw10:

            Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out.  Have you added/removed any firewall rules.

            Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:

            Steve

            I checked that the Automatic Outbound NAT was enabled and it was. Also I did not change any of the rules from the preconfigured. The firewall log is filled with many blocks but I don't know how to interpret them.

            DiagnosticsFirewallLogs.png
            DiagnosticsFirewallLogs.png_thumb

            1 Reply Last reply Reply Quote 0
            • stephenw10S Online
              stephenw10 Netgate Administrator
              last edited by

              Hmm, odd firewall hits. I assume the redacted destination IP is your WAN address? The odd thing is that it has 443 as the source port.  :-\ Anyway they are all hits on WAN which the firewall is correctly blocking by default. If the firewall was preventing your clients send traffic out you would see hits on LAN. Unless you have changed the rules these will be allowed by the default 'lan to any' rule.
              Ok so outbound NAT is set to auto (I'm not sure how to check that rules are actually being added here  :-). The other thing that commonly breaks routing is a subnet conflict or subnet mask misconfiguration but yours look OK to me.  :-
              That in no way explains why it works when you have wan set to dhcp either.

              Steve

              1 Reply Last reply Reply Quote 0
              • stephenw10S Online
                stephenw10 Netgate Administrator
                last edited by

                I think at this point I would run a packet capture on the WAN interface to check that ping requests are being correctly routed or replied to. However I'm not sure how well that will work in a VM.

                Steve

                1 Reply Last reply Reply Quote 0
                • P Offline
                  phil.davis
                  last edited by

                  Those IPs are ordinary places that people would use:
                  69.171.224.32 Facebook
                  23.48.50.110 Akamai Technologies - a web content provider that lots of pages reference
                  The packets are from port 443 - https - anyone starting a Facebook session would send stuff to Facebook on port 443, and should get an initial response back from port 443 which may soon hand off the comms for their new session to another port.
                  These packets from 443 should match a firewall state setup when the original user's packet went from LAN, NAT translation and out WAN. They should not be blocked, regardless of your firewall rules.
                  It seems that something weird is happening with the firewall states.
                  I am not familiar with all the options available when turning NAT off and on. In Firewall:NAT or System:Advanced:Firewall & NAT there might be setting that is not in its default state.
                  Enough talk, I'll let someone else thin kof what to look at next.

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S Online
                    stephenw10 Netgate Administrator
                    last edited by

                    Hmm, stateful firewall broken. Had not considered that!
                    I have no idea how one might break that or how switching from a dhcp assigned WAN to static might do it.  :-\

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • N Offline
                      natelabo
                      last edited by

                      I went into NAT configuration and moved from auto to manual. It created some rules I deleted those and then moved back to auto from manual. It seems to have fixed the blocks being reported in the firewall. Still no connectivity.

                      I did a packet capture on the wan interface… I then attempted to browse to google.com from a local device. Packets go through but I once again don't know how to interpret it.

                      OK scratch that I am still getting blocked...

                      1 Reply Last reply Reply Quote 0
                      • N Offline
                        natelabo
                        last edited by

                        Could someone take a look at these logs from the packet capture (I picked an interface and then on a local device attempted to go to google.com):

                        
WAN Interface

16:57:41.101959 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:41.108078 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23150, length 44
16:57:41.125294 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:41.144520 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23150, length 44
16:57:41.455705 IP 10.0.0.0 > 224.0.0.1: igmp
16:57:41.580017 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:41.664690 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:41.685577 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:42.039584 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:42.118017 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23406, length 44
16:57:42.149849 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23406, length 44
16:57:42.180303 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:42.638573 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:43.128024 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23662, length 44
16:57:43.161202 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23662, length 44
16:57:43.380435 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:43.838306 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:43.995745 IP 75.144.79.144.39147 > 74.125.225.70.443: tcp 0
16:57:44.017177 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
16:57:44.098672 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:44.120593 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:44.137956 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23918, length 44
16:57:44.170392 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23918, length 44
16:57:44.383626 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
16:57:44.664647 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:44.685868 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:44.699328 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
16:57:44.722696 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:44.728673 IP 75.144.79.144.4217 > 74.125.225.70.443: tcp 0
16:57:44.749215 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
16:57:44.966891 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
16:57:44.988638 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:45.147931 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24174, length 44
16:57:45.180448 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24174, length 44
16:57:45.182179 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
16:57:45.184711 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:45.410414 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:45.781167 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:45.783714 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:46.010282 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:46.157899 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24430, length 44
16:57:46.190517 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24430, length 44
16:57:46.237759 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:46.691304 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
16:57:46.734180 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:46.941749 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
16:57:46.982674 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:46.983864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:47.128039 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:47.167852 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24686, length 44
16:57:47.202763 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24686, length 44
16:57:47.210433 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:47.282514 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:47.700973 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
16:57:47.723263 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:47.729600 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:47.882395 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:47.961005 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
16:57:47.982889 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:48.116661 IP 75.144.79.144.26289 > 75.75.76.76.53: UDP, length 28
16:57:48.116694 IP 75.144.79.144.26289 > 8.8.8.8.53: UDP, length 28
16:57:48.116721 IP 75.144.79.144.26289 > 8.8.4.4.53: UDP, length 28
16:57:48.116746 IP 75.144.79.144.26289 > 75.75.75.75.53: UDP, length 28
16:57:48.132922 IP 75.75.76.76.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.136766 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
16:57:48.153083 IP 8.8.4.4.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.153130 IP 8.8.8.8.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.164292 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:48.167216 IP 75.75.75.75.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.177827 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24942, length 44
16:57:48.209769 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24942, length 44
16:57:48.456216 IP 10.0.0.0 > 224.0.0.1: igmp
16:57:48.549640 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:48.930197 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:49.084248 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:49.149509 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:49.187781 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25198, length 44
16:57:49.221121 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25198, length 44
16:57:49.385864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:49.611598 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:49.695145 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
16:57:49.741328 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:49.945167 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
16:57:49.987475 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:50.108172 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:50.135905 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:50.197745 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25454, length 44
16:57:50.229454 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25454, length 44
16:57:50.351753 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:50.583027 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:50.668264 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:50.691144 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:51.040863 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:51.139318 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
16:57:51.160980 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:51.207707 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25710, length 44
16:57:51.242954 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25710, length 44
16:57:51.332369 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:51.484095 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:52.217676 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25966, length 44

------------------------------------------------------------------
LAN Interface

16:58:53.524036 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.664922 IP 192.168.0.200.64336 > 74.125.225.134.443: tcp 0
16:58:53.723976 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.724061 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724063 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724594 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.724628 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724630 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724632 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724634 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725108 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.725146 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725148 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725150 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725152 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 495
16:58:53.725640 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.733891 IP 192.168.0.200.64337 > 74.125.142.125.443: tcp 0
16:58:53.983895 IP 192.168.0.200.64338 > 74.125.142.125.443: tcp 0
16:58:54.229110 IP 192.168.0.200.50855 > 192.168.0.99.53: UDP, length 33
16:58:54.246739 IP 192.168.0.99.53 > 192.168.0.200.50855: UDP, length 49
16:58:54.455911 IP 10.0.0.0 > 224.0.0.1: igmp
16:58:54.907004 IP 192.168.0.200.64339 > 74.125.225.32.443: tcp 0
16:58:55.137092 IP 192.168.0.200.64340 > 74.125.225.32.443: tcp 0
16:58:56.767269 IP 192.168.0.200.64341 > 74.125.225.131.443: tcp 0
16:58:56.987238 IP 192.168.0.200.64342 > 74.125.225.131.443: tcp 0
16:58:57.843056 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
16:58:58.612801 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:58:59.014081 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
16:58:59.363421 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:58:59.773368 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
16:59:00.113507 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:00.843563 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
16:59:00.910479 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:01.455647 IP 10.0.0.0 > 224.0.0.1: igmp
16:59:01.660603 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:02.013532 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
16:59:02.410700 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:02.773546 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
16:59:03.163869 IP 192.168.0.200.52811 > 192.168.0.99.53: UDP, length 37
16:59:03.182386 IP 192.168.0.99.53 > 192.168.0.200.52811: UDP, length 106
16:59:03.187650 IP 192.168.0.200.64354 > 207.46.206.137.80: tcp 0

                        I don't care about hiding the external IP anymore…. I'm not going to be using it for long.

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