Firewall question

[Jstobaugh]

I am having problems getting network services filter to work for me and have read everything I can find on it. Just as a test I am trying to block https from my laptop to a web site. I have the filter enabled and the following in the black list. Source IP 192.168.2.66 with no port set, Destination IP of 64.126.47.153 and ports 1:65535 and tcp protocal. I am still able to get to the website and the active connections under system log shows the destination ip with port 443 active. I have set the filter with just port 443 on the destination IP and it still shows active. I am using 380.64 firmware. Any help would be appreciated.

 

[Zirescu]

I am having problems getting network services filter to work for me and have read everything I can find on it. Just as a test I am trying to block https from my laptop to a web site. I have the filter enabled and the following in the black list. Source IP 192.168.2.66 with no port set, Destination IP of 64.126.47.153 and ports 1:65535 and tcp protocal. I am still able to get to the website and the active connections under system log shows the destination ip with port 443 active. I have set the filter with just port 443 on the destination IP and it still shows active. I am using 380.64 firmware. Any help would be appreciated.

Near as I can tell it's not working in 380.64.

 

[Jstobaugh]

Near as I can tell it's not working in 380.64.

Thanks for the response. Does anyone know what version of firmware it was known to work?

 

[ID-Tinker]

I just spent the last 2 hours tinkering with this. I'm at such a loss that I decided to actually register for this forum. I have found the main reason for this not working is that when parental controls are enabled then network services filter doesn't work. I've disabled the parental controls and even flushed the chain in iptables but still NSF still does not work as it should. Can anyone else confirm that NSF doesnt work for them as well?

*edit im on version 380.64_2

 

[Jstobaugh]

I found it to not be working. I went back to 380.61 and was able to get it to work.

 

[RMerlin]

This was supposed to have been fixed last October. Do you have any custom firewall script modifying the default rules?

I just tested it and it's working for me. Please provide more details on your configuration.

 

[Zirescu]

Double checked my firewall-start script which had something in it, renamed it to -old and rebooted - still no luck blocking IP addresses. Content of /tmp/nat_rules_eth0_eth0:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:VSERVER - [0:0]
:LOCALSRV - [0:0]
:VUPNP - [0:0]
:PUPNP - [0:0]
:DNSFILTER - [0:0]
:PCREDIRECT - [0:0]
-A PREROUTING -d 24.71.xx.xxx -j VSERVER
-A VSERVER -j VUPNP
-A VSERVER -j TRIGGER --trigger-type dnat
-A POSTROUTING  -o eth0 ! -s 24.71.xx.xxx -j MASQUERADE
-A POSTROUTING  -m mark --mark 0x8000/0x8000 -j MASQUERADE
COMMIT

and restarted the NSF by deleting an old rule, still not joy.

Disabled my openvpn client as well. Disabled DNS filtering and custom DNS. Let me know if you need some additional info.

 

[RMerlin]

The firewall rules are added to filter_rules, not to nat_rules.

 

[Jstobaugh]

I do not use a script. I am putting the rules in the Network Services Filter under the firewall.

 

[Zirescu]

The firewall rules are added to filter_rules, not to nat_rules.

Not seeing any messages related to filter_rules when I apply changes on the NSF page. Below is what I see in syslog:

Jan 10 18:53:04 rc_service: httpds 457:notify_rc restart_firewall
Jan 10 18:53:04 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!

Contents of the filter_rules:

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:FUPNP - [0:0]
:SECURITY - [0:0]
:PControls - [0:0]
:NSFW - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -i eth0 -p icmp --icmp-type 8 -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp ! --icmp-type 8 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -o eth0 ! -i br0 -j DROP
-A FORWARD -i eth0 -m state --state INVALID -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A NSFW  -i br0 -o eth0  -p tcp -s 192.168.2.2 --sport 80 -d 64.126.47.153 --dport 80 -j DROP
-A NSFW  -i br0 -o eth0  -p tcp -s 64.126.47.153 --sport 80 -d 192.168.2.2 --dport 80 -j DROP
-A NSFW -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT
:triggers - [0:0]
-A FORWARD -o eth0 -j triggers
-A FORWARD -i eth0 -j TRIGGER --trigger-type in
-A triggers -p udp -m udp --dport 1:65535 -j TRIGGER --trigger-type out --trigger-proto udp --trigger-match 1:65535 --trigger-relate 20500
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A SECURITY -p tcp --syn -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --syn -j DROP
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j DROP
-A SECURITY -p icmp --icmp-type 8 -m limit --limit 1/s -j RETURN
-A SECURITY -p icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A FORWARD -i br0 -j ACCEPT
COMMIT

 

[RMerlin]

Not seeing any messages related to filter_rules when I apply changes on the NSF page.

filter_rules is regenerated by restart_firewall shown on your log.

Looking at your NSF rules, your config is wrong. Your source port in your first rule should NOT be 80, it should be left empty. Web connection use a random source port between 1024 and 65535.

The second with a source of 64.126.47.153 is also wrong. Destination port on the PC should be left empty. In fact that actual rule shouldn't be there, connections are initiated from your client, not from the web server.

 

[Zirescu]

Yeah, I was messing around with things as I had seen another post from John about trying to reverse the source and destinations. Here's the updated rules output. Still able to get to the website though posted by the OP.

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:FUPNP - [0:0]
:SECURITY - [0:0]
:PControls - [0:0]
:NSFW - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -i eth0 -p icmp --icmp-type 8 -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp ! --icmp-type 8 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -o eth0 ! -i br0 -j DROP
-A FORWARD -i eth0 -m state --state INVALID -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A NSFW  -i br0 -o eth0  -p tcp -s 192.168.2.150 -d 64.126.47.153 --dport 1:65535 -j DROP
-A NSFW -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT
:triggers - [0:0]
-A FORWARD -o eth0 -j triggers
-A FORWARD -i eth0 -j TRIGGER --trigger-type in
-A triggers -p udp -m udp --dport 1:65535 -j TRIGGER --trigger-type out --trigger-proto udp --trigger-match 1:65535 --trigger-relate 20500
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A SECURITY -p tcp --syn -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --syn -j DROP
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j DROP
-A SECURITY -p icmp --icmp-type 8 -m limit --limit 1/s -j RETURN
-A SECURITY -p icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A FORWARD -i br0 -j ACCEPT
COMMIT

and with CIDR:

-A NSFW  -i br0 -o eth0  -p tcp -s 192.168.2.0/24 -d 64.126.47.153 --dport 1:65535 -j DROP

Gateway used to test from two different laptops is 192.168.2.1.

 

[RMerlin]

Please post a screenshot of your Firewall page. Based on these logs, the rules are properly generated, but there's no jump to the NSFW chain, as if it wasn't enabled.

 

[Zirescu]

 

[RMerlin]

The issue occurs if you enable Parental Control, but there aren't any rules in it - the router will then fail to add the iptables rule to jump to the NSFW chain.

 

[Jstobaugh]

Several versions back I had parental controls on but had turned it off. I reset to factory defaults just to make sure all was clean and then manually put back my settings. It still wouldn't work. I then restored to 380.61 and put in the firewall rules and it worked. Very simple rules of one IP blocked all but NTP. I will try upgrading to 380.64 with the current config and see if it still works. Thanks for your help on this.

 

[Zirescu]

Don't recall ever enabling the Parental Controls on this router, but I did have the DNS filtering enabled previously, but was disabled for this test.

 

[RMerlin]

Having PC enabled without rules was just one specific scenarios where the Network Service Firewall wouldn't get processed. It wouldn't be processed either if you had PC completely disabled.

And enabling NSF also prevented port triggering from working.

I revised a bit the logic on how NSFW rules are getting applied to resolve those scenarios where it would fail to work properly.

 

[Jstobaugh]

I upgraded to 380.64 and did a hard reboot and NSF stopped working. Went back to 380.61 and it went to work again. I didn't have DNS filtering enabled but had in the past.

 

[RMerlin]

380.61 was broken for Parental Control user. Fixing it broke it for other usage scenarios.

Wait for the next release. As I posted, I revised the whole NSFW implementation to resolve the various scenarios where it wasn't working.