Can't create firewall rules with port = 0
-
Not sure, but i would think this breaks nat reflection. Need testing.
-
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.
-
NAT reflection. I hadn't thought of that.
Ok, I'll try testing that.
-
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 em2block anything from private networks on WAN interface
anchor "spoofing"
antispoof for $wanI 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 -
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 …
-
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.
-
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.
-
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.
-
@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 -
@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.
Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible? :)
It's in the works.