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

    Can't create firewall rules with port = 0

    Scheduled Pinned Locked Moved webGUI
    17 Posts 6 Posters 12.1k 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.
    • S
      sullrich
      last edited by

      There should be spoofing protection on all WANS.

      Can you show an example?

      1 Reply Last reply Reply Quote 0
      • R
        rcarr
        last edited by

        I'm running 1.0.1-SNAPSHOT-03-27-2007.  Here's what my rules.debug has with regard to spoofing and anti-spoofing:

        LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)

        antispoof for fxp1
        antispoof for fxp2

        block anything from private networks on WAN interface

        anchor "spoofing"
        block in log quick on $wan from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
        block in log quick on $wan from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
        block in log quick on $wan from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
        block in log quick on $wan from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"

        Firewall->Rules-> doesn't show any anti-spoofing rules in the GUI for any of the interfaces.  Interfaces->WAN does present "Block private networks" and "Block bogon networks" options, but no anti-spoofing of the interface's IP addr.

        I ended up adding a rule in the GUI, which looks like this in rules.debug:

        User-defined rules follow

        block in quick on $wan from x.x.x.x to any  label "USER_RULE: Block packets spoofing WAN IP addr (LAND attacks)"

        1 Reply Last reply Reply Quote 0
        • D
          databeestje
          last edited by

          Not sure, but i would think this breaks nat reflection. Need testing.

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            Commited a antispoof for $wan.  Did not know that we where lacking this.  Thank you.

            Also, if you could please test with reflection to make sure we did not break this functionality.

            1 Reply Last reply Reply Quote 0
            • R
              rcarr
              last edited by

              NAT reflection.  I hadn't thought of that.

              Ok, I'll try testing that.

              1 Reply Last reply Reply Quote 0
              • R
                rcarr
                last edited by

                I applied the 1.2 beta snapshot from 4/22.

                rules.debug now shows antispoofing for $wan:

                LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)

                antispoof for em1
                antispoof for em2

                block anything from private networks on WAN interface

                anchor "spoofing"
                antispoof for $wan

                I disabled my custom rule for anti-spoofing on $wan.

                Haven't had a chance to test NAT reflection yet.

                Thank you also for adding:

                We use the mighty pf, we cannot be fooled.

                block quick proto { tcp, udp } from any port = 0 to any
                block quick proto { tcp, udp } from any to any port = 0

                1 Reply Last reply Reply Quote 0
                • G
                  gbelanger
                  last edited by

                  I've seen situations where the WAN is not the Internet (i.e. a DMZ or another private network). In that case, wouldn't these 'anti-spoof' rules prevent legitimate traffic to go through? (assuming the traffic doesn't get NAT'ed).

                  An example of this could be two offices connected through a point-to-point link on the WAN interfaces.

                  Shouldn't this be an option rather than a permanent rule? Maybe I'm just not getting this right …

                  1 Reply Last reply Reply Quote 0
                  • R
                    rcarr
                    last edited by

                    The antispoof rule should prevent an interface from receiving a packet which claims to have the same source IP as the interface.

                    I can't think of a scenario in which that is legitimate.

                    It means either that someone is crafting packets to spoof the source addr of one of your interfaces (for instance, during a LAND attack), or that you have two devices sharing the same IP addr – which is also bad.

                    1 Reply Last reply Reply Quote 0
                    • G
                      gbelanger
                      last edited by

                      Oh, yes, that makes sense. I was reacting to this:

                      anchor "spoofing"
                      block in log quick on $wan from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
                      block in log quick on $wan from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
                      block in log quick on $wan from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
                      block in log quick on $wan from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"

                      I was referring to the fact that theoretically, the WAN could be a private network. So blocking private networks on the WAN Interface by default might be problematic.

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

                        1 Reply Last reply Reply Quote 0
                        • T
                          techatdd
                          last edited by

                          @cmb:

                          It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

                          Not sure if this is right, actually everybody using multiwan with pppoe needs it.
                          Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible?  :)

                          Greetings,
                          techatdd

                          1 Reply Last reply Reply Quote 0
                          • C
                            cmb
                            last edited by

                            @techatdd:

                            @cmb:

                            It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

                            Not sure if this is right, actually everybody using multiwan with pppoe needs it.

                            That's not true unless you have private IP space on your WAN, which normally won't be the case with PPPoE of any kind.

                            @techatdd:

                            Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible?  :)

                            It's in the works.

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