So I have built a blacklist in my Tik. I have a filter rule on the INPUT chain to drop any traffic from SRC ADDRESS list BLOCK. That is all fine for anything in the block list that is coming in to the router.
My confusion is that lets say address 185.168.4.4 is on the block list. Lets say this address is tied to a specific web page. If a computer behind my Tik reaches out to this particular address, the Tik allows it to go through and the web page presents itself. The above INPUT firewall rule doesn’t block the connection to the client behind the firewall.
So my question is do I also need a firewall rule on the FORWARD chain to block the connection to the above DST ADDRESS LIST for the blocked addresses?
Yes. The Input chain only affects traffic that will terminate on the router itself. The Forward chain affects traffic that will pass through the router. Note that you have an allow connected and related traffic in the Forward chain, that rule will allow responses to one of your users who connects to that website PROVIDED that the allow connected rule is before the block rule. If you want to prevent someone from connecting to the blocked website, you need to put the block rule BEFORE the allow connected and related rule.
Thanks for the quick reply!! Okay that makes perfect sense. Set it up like you said and is working great! Now help me understand… I understand that the OUTPUT chain is involving any traffic generate by the router itself and is outbound. What are some examples of where this would come into play? I originally had my rules from up above on the output chain instead of forward and that is why they werent doing what I wanted…
DNS queries. Either due to own router activities (see next bullet) or if router is configured as DNS relay for clients and clients query router for DNS answer while answer is not cached at router yet
updates of router … either ROS itself or some external blacklists where script on router fetches updates
BGP/OSPF data interchange with peers
There are plenty other examples where chain=output gets used.
Here’s another example of using stuff in the Output chain. I was recently troubleshooting a problem and I wanted to be able to verify that packets were going out on the interface that they should have been. So I created the following set of output chain rules that served only to count packets on each individual interface. I would then ping various IPs and could easily confirm that the packets were going out the interface that they were expected.
add action=accept chain=output comment="Only for packet counting" \
out-interface=E1-p1_DSL_Internet
add action=accept chain=output comment="Only for packet counting" \
out-interface=E2-p3_201
add action=accept chain=output comment="Only for packet counting" \
out-interface=E3-p5_203
add action=accept chain=output comment="Only for packet counting" \
out-interface=VLAN_131
add action=accept chain=output comment="Only for packet counting" \
out-interface=VLAN_202
add action=accept chain=output comment="Only for packet counting" \
out-interface=VLAN_204
add action=accept chain=output comment="Only for packet counting" \
out-interface=VLAN_209
add action=accept chain=output comment="Only for packet counting" \
out-interface="E5 Router to Router tie"
I also created some rules in the Input chain to confirm that the ping responses were coming back where I expected them to be.
With some help from forum member Sindy, my problem was solved, and I expect that I will remove those rules.