Firewall rule with no src

[SharkScout]

I have 2 internal subnets : lan1 and lan2.

When I use the following rule in /etc/config/firewall:

config rule 'dot'                       
        option name 'Deny-DoT'    
        option src 'lan1'
        option dest 'wan'               
        option dest_port '853'          
        option proto 'tcp udp'          
        option target 'REJECT'

Then trying to access an external IP on port 853 (via a port scan) fails as expected:

Port Scan has started…
Port Scanning host: 8.8.8.8
Port Scan has completed…

However if I change this rule to:

config rule 'dot'                       
        option name 'Deny-DoT'    
        option dest 'wan'               
        option dest_port '853'          
        option proto 'tcp udp'          
        option target 'REJECT'

(i.e. I removed the src entirely) then a port scan reveals open 853 ports on external IPs:

Port Scan has started…
Port Scanning host: 8.8.8.8
Open TCP Port: 853
Port Scan has completed…

This surprised me because the doc says:

If only dest is given, the rule matches outgoing traffic

So I was expecting that in both cases the port 853 would not appear as open on external IPs. What am I missing?

[trendy]

@SharkScout

What am I missing?

Outgoing traffic = traffic originating from the router itself.
Forward traffic = traffic traversing the router.

[vgaetera]

https://openwrt.org/docs/guide-user/firewall/firewall_configuration?s=src#options5

src - Specifies the traffic source zone. Refers to one of the defined zone names , or * for any zone. If omitted, the rule applies to output traffic.

[SharkScout]

Ah thanks, I get it now. I had the wrong mental model where a forwarded packet lan->wan would become an outgoing packet when allowed by the firewall.

[lleachii]

@SharkScout

I had the wrong mental model where a forwarded packet lan->wan would become an outgoing packet when allowed by the firewall.

@SharkScout ...you've ran into this confusion again (this is the 4th or 5th thread...)?!?!

I have a good manual for you!!!

https://tldp.org/HOWTO/IPCHAINS-HOWTO-4.html

(Especially review section 4.1 How Packets Traverse The Filters.)

[SharkScout]

I think you are slightly overstating my stupidity. Off the top of my head there's only one other thread where I got confused between forwarded and outgoing messaging. And I would argue the other case was a little different.

Thanks for the link though.

[lleachii]

@SharkScout

I think you are slightly overstating my stupidity. Off the top of my head there's only one other thread where I got confused between forwarded and outgoing messaging.

Fair enough...to be honest, I was confused about this too when I first started with Linux firewalling (I also confused FORWARD firewalling with routing - especially since you can move packets in some instances).

@SharkScout

Thanks for the link though.

No problems. That link (and other Linux manuals helped me with the concept for iptables and chaining).

[SharkScout]

Reading your link, this is actually interesting:

When a packet comes in (say, through the Ethernet card) the kernel uses the input chain to decide its fate. If it survives that step, then the kernel decides where to send the packet next (this is called routing). If it is destined for another machine, it consults the forward chain. Finally, just before a packet is to go out, the kernel consults the output chain

So it seems I actually had the correct mental model. An incoming packet will go through the three chains. So a forwarded packet lan -> wan will indeed become an "output'ed" packet in the sense that it will have to go through the OUTPUT chain.

My earlier misunderstanding actually comes from the fact that I confused outgoing and "output'ed". A forwarded lan->wan packet goes through the OUTPUT chain, but the following rule

config rule 'dot'                       
        option name 'Deny-DoT'    
        option dest 'wan'               
        option dest_port '853'          
        option proto 'tcp udp'          
        option target 'REJECT'

will not ever match such a packet because an absent src is equivalent to src_ip being set to the router's ip (i.e. outgoing traffic, as @trendy explained).

Feel free to correct any misunderstanding on my part.

[lleachii]

@SharkScout

So it seems I actually had the correct mental model.

@SharkScout

Feel free to correct any misunderstanding on my part.

No.

You followed Ethernet card as the example in parenthesis, and not Kernel. It means what it says:

• Packet hits Kernel...it passes INPUT...then it wasn't input....
• This follows...

@SharkScout

If it is destined for another machine

That means it's FORWARD (i.e. not destined for the device)...

• Is it allowed? (firewall rule)
• (is IPv4 and/opr IPv6 forwarding allowed by the Kernel - i.e. routing)

@SharkScout

Finally, just before a packet is to go out, the kernel consults the output chain

You must note though...a packet is not processed twice (i.e. looped) by the firewall.

This is a picture/diagram of it (more complex):

iptables

[trendy]

I can see that there can be some confusion with the multiple tables and chains.
Whether a packet is dropped or accepted takes place in filter table. This tables has input, forward, and output chains. Input checks the packets destined for the device itself. Forward is checking the packets traversing the router. Output checks packets generated locally on the router. So for an incoming packet only input or forward will be examined, depending on the destination address of the packet. If the device wants to send a packet only the output will be used to examine it.
In the case of the nat table, then the prerouting chain will examine all incoming packets, regardless of their destination (the router or another device) and apply the changes on the packet, if any.

[SharkScout]

I see, that makes sense. Thank you for the explanation.

@lleachii thank you as well.