Since I do not have internet access, my guess is this points to a problem with one of the forward chain rules.
What I can see is that the “accept from LAN” rule counter is increasing. So is the ”drop everything else” rule, which is at the end.
So clearly the ”accept from LAN” rule is allowing connections to (for example) 8.8.8.8 to pass through the router. I would guess the ”drop everything else” rule is dropping returning traffic. So apparently the ”accept established, related, untracked” rule is not being triggered when traffic returns.
Further, the ”drop all from WAN not dstnat” rule is not being triggered. This suggests that this rule is correct, and that returning traffic is recognized as for dstnat.
I would guess that I misunderstand something about how these rules interact as part of the configuration.
It seems like the issue is actually related to NAT.
I set up a PPPoE connection, but for some reason it did not create a default NAT rule. (I’m not sure if this is normal. Am I supposed to manually configure the NAT rule, or should it be automatically added?)
What is strange is the PPPoE connection runs using ether1, which is part of the WAN interface list.
So, it should already have NAT running for traffic which goes out via ether1, but this rule is not working.
To get it to work, I had to change from using an out interface list to using an out interface, and use pppoe1 as the interface, and not ether1.
I tried one additional thing too, but this does not work, and I am also confused by this.
I realized because I have added a default “drop everything” rule, that the “drop all from WAN not dstnat” should also be changed to “accept all from WAN if dstnat” because the default logic is no longer accept by default but reject by default.
However, I have added this rule, and it is not being triggered. The counter is not increasing.
But I must have dstnatted traffic returning via the ether1 interface, which is part of the WAN interface list. So I’m very confused as to why I am not seeing counters increase there - unless this is because for some reason the device doesn’t know that WAN list = ether1 = pppoe1. ?
You need to manually add the PPPoE client interface (pppoe-out1 for instance) to the WAN list. If you use the default PPP profile, this is not done automatically.
Alternatively, if you like me need to do the special workaround for PPPoE MSS & 1500 MTU, you an set the Interface List field of the custom PPP profile to WAN, and all PPPoE client interfaces that use the profile will be automatically added to the WAN list. See the screenshots on my linked post.
Returning traffic for connections that you initiated from your LAN to WAN are handled by either the fasttrack-connection rule or the acceptestablished,related,untracked rule right below it. The returning packets would have connection-state=established (plus some ICMP packets that have the related state).
The rules below them only have to deal with packets with connection-state=new or connection-state=invalid.
Yes, good call. I’ve added the pppoe1 interface to a list called WAN_PPPOE. I have then added WAN_PPPOE to a list called WAN_ALL.
To test this, I created a drop all rule on the forward chain for WAN_ALL. If I put this at the top, I now see all packets being dropped. So the interface list is clearly working correctly. pppoe1 is a member of WAN_PPPOE, and WAN_PPPOE is a member of WAN_ALL.
However, I am still a bit confused. It seems like the forward chain rule to accept established, related and untracked is being triggered by returning traffic. This means the rules relating to wan(s) dstnat are being ignored.
So what is the purpose of those in the default configuration?
Those rules with in-interface-list=WAN are for connections initiated from the internet. Which means some host from outside tries to make a connection to your router's public side. Like I wrote above, those rules normally only have to check the very first packet of a connection.
Normally the outside internet is a hostile environment, so we assume that people who wants to make new connection to your public IP address are evil and want to hack you, that's why in general we want to drop those connection attempts, by dropping when the state is still new (very first packet).
But sometimes we want to do "port forwarding" and open a few ports, and want to allow people from outside to initiate connections towards those ports. For port forwarding we write DSTNAT rules. DSTNAT is handled very early, so once the first packet of the connection hit the filter table, the connection-nat-state of those DSTNATed packed is already dstnat. We don't want to drop them like the rest, that's why the defconf drop rule has the connection-nat-state=!dstnat condition.
If the first packet of a connection is not dropped, then all the following packets of the same connection in both directions will be allowed by the "established" rules at the beginning of the chains.
This makes sense to me. I’m beginning to piece it together.
I think (one) problem is that I have not inverted this condition correctly.
Since I have a drop all rule, this particular rule (drop if new from WAN and not dstnat) should be changed to an accept rule, and I have messed that up.
It’s conceptually clearer (I think) when you realize this default drop rule is two things.
It is a combination of:
drop all
but allow reverse-nat connections from the external world (hence new, and dstnat)
So what I need to allow is “reverse-nat connections which are new”.
The reason I never see such a counter increasing is because there is nothing trying to connect and reverse-nat at the moment.
at that point you don't need connection-state=new, because all the other states have been caught by the fasttrack/accept established,related,related/drop invalid rules. Packet that survived past those rules all have connection-state=new, it's redundant to add that condition.
Also, for packet originating from LAN, normally you don't care about the dstnat state of them. And at that point of the filter table, they don't have the srcnat state yet.
Yes, it looks good. And you've replicated @anav usual recommendations on how to transform the defconf FW into one that uses "drop the rest" rules at the bottom of the chain.
Only as a side note, and for future memory, the changes (splitting the last rule in two or more) @anav usually suggests remains functionally equivalent to the default firewall rule, it is only easier to understand what it does (they do).
Jaclaz is darn close......... The reason I prefer the rules is that its a bit more secure than the default rules because we block all other traffic. So by stating them as such
Best mimics the default rule but adding some key clarity.
First that the default rule allows access to the WAN outbound...... and now we can control that more effectively if need be as we are aware of that flow.
Secondly, you will note that it blocks drops any LAN to LAN connectivity ( at L3) and this is where I take issue with your setup that allows LAN to anything. Too loosey goosey for me.
Having a second subnet for IOT or guests is now exposed and also the same will occur when adding vlans. Best to start off with minimal access required, similar to how one should have no services runningnot needed. Less possible attack vectors the better.
As for new traffic, the first packet is always new and the rest are established, related etc...... Thus its really of no use to state new....... The only place I have found it useful is some niche mangling situations to help differentiate traffic where NO MARK is not sufficient.
Yup, as long as you have a logic, all good.
I tend to use the LAN interface list to cover all subnets that may have a common purpose, otherwise there is no point to a LAN interface list, for example access to WAN in forward chain. Typically all subnets require that and thus the LAN interface list entry is efficient, and if not, typically one is denied which can still be covered in the single rule.
Otherwise, it makes sense to create other interface lists when two or more whole subnets need to be identified in other firewall rules. For example, if you have 6 subnets and only 3 require wan access then I would not have a LAN interface list, but more likely a Internet-Access list etc....
The other often used LAN list is to allow access to dns in the input chain.
As the saying goes form follows function. Use of address lists is useful when one has users/devices to be identified but less than a subnet, or across subnets ( with or without whole subnets )