Community discussions

 
User avatar
43north
Member Candidate
Member Candidate
Topic Author
Posts: 197
Joined: Fri Nov 14, 2014 7:06 am

Question on Firewall and blacklists

Wed Aug 15, 2018 4:17 am

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?
 
User avatar
k6ccc
Member
Member
Posts: 479
Joined: Fri May 13, 2016 12:01 am
Location: Glendora, CA, USA (near Los Angeles)

Re: Question on Firewall and blacklists

Wed Aug 15, 2018 5:25 am

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.



Sent from a $&@#% iPhone using Tapatalk
RB750Gr3, RB750r2, CRS326-24G-2S (in SwitchOS), CSS326-24G-2S, CSS106-5G-1S, RB260GS
Not sure if I beat them in submission, or they beat me into submission


Jim
 
User avatar
43north
Member Candidate
Member Candidate
Topic Author
Posts: 197
Joined: Fri Nov 14, 2014 7:06 am

Re: Question on Firewall and blacklists

Wed Aug 15, 2018 7:43 am

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....
 
mkx
Forum Guru
Forum Guru
Posts: 2952
Joined: Thu Mar 03, 2016 10:23 pm

Re: Question on Firewall and blacklists

Wed Aug 15, 2018 3:54 pm

Router-originating traffic examples:
  • 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.
BR,
Metod
 
User avatar
k6ccc
Member
Member
Posts: 479
Joined: Fri May 13, 2016 12:01 am
Location: Glendora, CA, USA (near Los Angeles)

Re: Question on Firewall and blacklists

Wed Aug 15, 2018 5:42 pm

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.
RB750Gr3, RB750r2, CRS326-24G-2S (in SwitchOS), CSS326-24G-2S, CSS106-5G-1S, RB260GS
Not sure if I beat them in submission, or they beat me into submission


Jim

Who is online

Users browsing this forum: No registered users and 86 guests