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

    CE 2.7.2 to CE 2.7.2 routing issue

    General pfSense Questions
    4
    20
    1.3k
    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.
    • M
      MakOwner @stephenw10
      last edited by

      @stephenw10

      Something is just .. flaky.

      pfblocker was configured for two specific networks and I don't think there were any floating rules.
      After turning it off, there are no floating rules at all and the only rules on WAN now are the "block bogon" and "block private" rules.

      I'll try turning it back on see what happens.

      Still seeing 100% packet loss on the gateway monitor.
      Bldg1 LAN interface 192.168.10.1
      Bldg1 Link interface 192.168.30.1
      Bldg2 Link interface 192.168.30.2
      Bldg2 LAN interface 192.168.20.1

      from bldg1 I can't ping 192.168.30.2 or 192.168.20.1
      (192.168.20.1 is the monitor ip address for Link gateway.)

      I can get to things on the 192.168.20.0 subnet if adressing it via IP -- name resolution isn't working apparently.
      So the any to any rule on the link isn't allowing some protocols...

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

        You should not have 'block private networks' set on the link interface on either side. The source traffic there is all from private subnets.

        M 1 Reply Last reply Reply Quote 0
        • M
          MakOwner @stephenw10
          last edited by

          @stephenw10 It isn't - that's only on the WAN interface -- incoming if I read it correctly.

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

            Did you check the routing table on each side?

            M 1 Reply Last reply Reply Quote 0
            • M
              MakOwner @stephenw10
              last edited by

              @stephenw10
              oh yea.
              bldg 1
              06a86d48-2be8-4f37-9102-1afa295e0f71-image.png

              bldg 2

              afc313e3-b029-4a23-9047-136a45600e42-image.png

              M 1 Reply Last reply Reply Quote 0
              • M
                MakOwner @MakOwner
                last edited by MakOwner

                @MakOwner

                Rules on the interface where the remote system is showing down:
                e6cf5e3c-9516-41ff-b62c-c8f631526008-image.png

                Above is for bldg1 -- blow is the corresponding interface in bldg 2
                bbb23fe1-9ec0-4d34-a7cb-b29ed50d596d-image.png

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

                  Are they using the internal LAN IP addresses as the monitoring IP on each side? You seem to have static routes for those in the table which would otherwise be unexpected.

                  Do pings also fail simply to the remote side of the link?

                  Are you NATing that traffic? Do your Outbound NAT rules include the link interface?

                  M 1 Reply Last reply Reply Quote 0
                  • M
                    MakOwner @stephenw10
                    last edited by

                    @stephenw10

                    the monitor ip is the LAN network internal gateway of the opposite pfsense.
                    Local Ip -> remote IP -> remote LAN gateway.
                    30.1 30.2 20.1

                    Previously, (2.6x) this didn't work unless static routes were manually defined.
                    It worked between 2.7.2 and 2.6, but this issue arose when I went to 2.7.2 on both ends.

                    The traffic across that .30 network is primarily between the buildings with no restrictions that I can see.
                    Any protocol, any to any on both ends.

                    Pings fail only one way. Some traffic is getting through both ways.

                    It's like the firewall rule on one end isn't really operating correctly.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      MakOwner @MakOwner
                      last edited by

                      @MakOwner

                      And that was it -- I opened and resaved both rules -- no changes mind you -- and boom -- it works as expected.

                      Sooo... lesson learned:
                      Don't restore backups.
                      Don't save them encrypted so you can read and manually transcribe the settings because restores are ...

                      Well, it did restore the settings -- they just didn't take effect. :/

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

                        Hmm, odd. I assume no alerts were shown about failures to load the ruleset?

                        M 1 Reply Last reply Reply Quote 0
                        • M
                          MakOwner @stephenw10
                          last edited by

                          @stephenw10
                          No alerts in Bldg 2.
                          Bldg 1 ... I have pfblocker installed and it spams alerts so hard I'm thinking about just removing it :/

                          Are there any alternatives?
                          I can go back to a pi-hole elsewhere on the network if there isn't.

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

                            Hmm, odd. Sometimes if the running ruleset doesn't match the configured rules it's because it's unloadable. But when that happens you see an alert in the GUI. That should be different to anything pfBlocker is alerting you to.
                            Otherwise it appears it simply hadn't loaded. I assume the firewall rebooted when you restored the config?

                            M 1 Reply Last reply Reply Quote 0
                            • M
                              MakOwner @stephenw10
                              last edited by

                              @stephenw10

                              I did not see any related alerts - and the restore in bldg 2 caused a reboot and it was rebooted manually before and after the cutover.

                              1 Reply Last reply Reply Quote 1
                              • S
                                Stewart @MakOwner
                                last edited by

                                @MakOwner

                                Is it spamming alerts on the IP rules or the DNS rules? You could just disable the rules causing issues. I was never happy with the rulesets we could come across so we do IP via pfBlocker and DNS filtering via a third party service. It also would have helped to do some packet capturing to see if packets are even making it to the other side. That would verify if it were a routing or firewall issue.

                                M 1 Reply Last reply Reply Quote 0
                                • M
                                  MakOwner @Stewart
                                  last edited by

                                  @Stewart
                                  pfBlockerNG MaxMind - MaxMind now requires a License Key! Review the IP tab: MaxMind settings for more information. @ 2024-02-29 16:15:40

                                  Once an hour.
                                  I have turned off everything I can find about IP.

                                  bmeeksB 1 Reply Last reply Reply Quote 0
                                  • bmeeksB
                                    bmeeks @MakOwner
                                    last edited by bmeeks

                                    @MakOwner said in CE 2.7.2 to CE 2.7.2 routing issue:

                                    @Stewart
                                    pfBlockerNG MaxMind - MaxMind now requires a License Key! Review the IP tab: MaxMind settings for more information. @ 2024-02-29 16:15:40

                                    Once an hour.
                                    I have turned off everything I can find about IP.

                                    I think it now also requires an Account ID in addition to the License Key be provided to download updates. I think this new requirement took effect in January of this year.

                                    I had to make a recent change in the Suricata IDS/IPS package because of the MaxMind authentication API change.

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