Menu
What's new
By:
Filters Better Search

Blacklisting via Network Services Filter isn't working

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Morac

Morac

Senior Member
I'm running Merlin 382.1_2 on my AC88U and I am unable to get blacklisting to work with the Network Services Filter. I was originally trying to blacklist a NTP server so I added the ip address and set the protocol to UDP, but that didn't work. I then tried other ip addresses and TCP and was able to access them.

I checked iptables and I can see that entries are being added to the CHAIN NSFW with a rule of RETURN. Is that what it should be? I ask because from my understanding RETURN just causes iptables to go back to the previous rule and continue checking.

Here's the ip tables sections in question:

Code: 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     4940 1179K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
3        0     0 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
4        9   468 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
6      610 47856 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
7        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
8        2   152 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Chain NSFW (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        2   152 RETURN     udp  --  br0    eth0    0.0.0.0/0          
2      608 47704 ACCEPT     all  --  br0    eth0    0.0.0.0/0            0.0.0.0/0

As you can see the NSFW rule for 204.176.49.10 is hitting, but simply returning back to the FORWARD chain and being accepted by rule 8 of the FORWARD chain. I read somewhere that Network Services Filter doesn't work if Parental Controls is enabled, but it's not enabled on my router. It looks like the Network Services Filter is simply broken.

Is there something wrong with the FORWARD rules or is the NSFW rule being created wrong?
Any idea how to fix this without manually adding an iptable rule?

Here's the entire iptables list. Of note I have a number of port forward rules which don't show up anywhere in iptables even though they work.
Code: 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
2        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1194
3     8328 1243K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
4       12   480 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5     3434  647K PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0
6     1542  199K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0
7     1542  199K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
8     3024  630K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
9        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
10       0     0 SSHBFP     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:27158 state NEW
11       6   240 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
12     404 17672 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     4940 1179K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2        0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
3        0     0 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
4        9   468 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
6      610 47856 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
7        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
8        2   152 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 12487 packets, 4853K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain ACCESS_RESTRICTION (0 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain FUPNP (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.36         udp dpt:9306
2        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.1.36         udp dpt:9308

Chain INPUT_ICMP (0 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain NSFW (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        2   152 RETURN     udp  --  br0    eth0    0.0.0.0/0            204.176.49.10
2      608 47704 ACCEPT     all  --  br0    eth0    0.0.0.0/0            0.0.0.0/0

Chain PControls (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain PTCSRVLAN (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain PTCSRVWAN (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain SECURITY (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
3        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
5        0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
6        0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
7        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain SSHBFP (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0            all  --  *      *       0.0.0.0/0            0.0.0.0/0            recent: SET name: SSH side: source
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain default_block (0 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain logaccept (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
2        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
Last edited:
So I changed the rule from "Black List" to "White list' and this is what the CHAIN NSFW changed to:

Code: 
Chain NSFW (1 references)
target     prot opt source               destination
RETURN     udp  --  anywhere             sjr1.tivo.com
DROP       all  --  anywhere             anywhere

That looks correct, so I'm guessing the white list rules are being used to add entries instead of the Black list rules. In other words black listing doesn't work.

I dug through the code looking for NSFW and RETURN and found this if/else statement which looks odd since the if and else do the exact same thing. It seems to be related to whitelisting vs blacklisting. In this case, it's setting the rule to "RETURN" whether filtering is set to white list or black list.

https://github.com/RMerl/asuswrt-me...6758b9/release/src/router/rc/firewall.c#L2829

It was changed last year.

https://github.com/RMerl/asuswrt-merlin/commit/677b74c08ec20145fd99f4995a356671dbde76f5
 
Last edited:
Morac said:
No one has responded, does this mean that people think “RETURN” is the proper value? Blacklist filtering doesn’t work so I don’t see how it could be correct.
Click to expand...
Hmm, whilst I don't use NSFW, I would tend to agree.

Personally I would expect:

Blacklist​

e.g. explicitly stop 10.88.8.144 from accessing NTP server 85.199.214.101
Code: 
-A NSFW -s 10.88.8.114/32 -d 85.199.214.101/32 -i br0 -o eth0 -p udp -m udp --dport 123 -j DROP
-A NSFW -j RETURN
as I wouldn't expect a lower priority rule to override this given the NSFW chain is usually at the end of the '-t filter' table .......but I could be wrong. ​
 
Martineau said:
Hmm, whilst I don't use NSFW, I would tend to agree.

Personally I would expect:

Blacklist​

e.g. explicitly stop 10.88.8.144 from accessing NTP server 85.199.214.101
Code: 
-A NSFW -s 10.88.8.114/32 -d 85.199.214.101/32 -i br0 -o eth0 -p udp -m udp --dport 123 -j DROP
-A NSFW -j RETURN
as I wouldn't expect a lower priority rule to override this given the NSFW chain is usually at the end of the '-t filter' table .......but I could be wrong. ​
Click to expand...

They appear backward indeed. The confusion probably comes from the fact that filter_lw_default_x is the default policy, NOT the rule policy. So, DROP means you are in whitelist mode, and vice-versa.
 
RMerlin said:
They appear backward indeed. The confusion probably comes from the fact that filter_lw_default_x is the default policy, NOT the rule policy. So, DROP means you are in whitelist mode, and vice-versa.
Click to expand...

So is this a bug? Will it be fixed?

For what it’s worth I’m getting RETURN for both whitelist and blacklist mode. RETURN is okay for whitelist mode, but not for blacklist mode.
 
Morac said:
So is this a bug? Will it be fixed?
Click to expand...

For 384 yes. Don't know yet about 380, will depend if I ever find the time to issue a new release for it. Right now I can't even keep up with Asus' release rate for the 382/384 code, with still two models I haven't had time to migrate yet.
 
RMerlin said:
For 384 yes. Don't know yet about 380, will depend if I ever find the time to issue a new release for it. Right now I can't even keep up with Asus' release rate for the 382/384 code, with still two models I haven't had time to migrate yet.
Click to expand...

I’m on the 382 branch currently, so I’ll just wait for your 384 version to come out.

Thanks.
 
Hi,
Last month I bought the new WiFi 6 router RT-AX88U.
To my surprise I noticed my NAS is happily allowed access through any outbound port, eventhough I setup rules that it should only go through the VPN UDP port 1197. I've set all other TCP and UDP ports for IP 192.168.1.10 to be blocked by the blacklist.
I just updated to 386.1 on my RT-AX88U but the problem remains. Strange thing: I have seen this working before. When I disconnected my VPN and did a ping to www.google.com, it used to be blocked. But now if just seems to ignore all rules.
When I change blacklist to whitelist. everything is blocked. But I'd like to use blacklist and only block the static ip of my NAS, except for UDP 1197.
Before I used a Netgear R8000 router which worked great by blocking outbound ports. Any idea how I can get this working on the RT-AX88U? I only want my NAS to go through the VPN and if VPN is down everything should be blocked.
1612209811809.png
 
I'm not sure I'm understanding your problem. The Network Services Filter only blocks LAN traffic going through the WAN interface. It doesn't block LAN traffic going through the VPN interface.

What is UDP port 1197? Is that some service used by your NAS or is that the port used by your VPN client?

If you want to selectively route certain clients through the VPN and others through the WAN you shouldn't be using the Network Services Filter you should be using Policy Based Routing instead: https://github.com/RMerl/asuswrt-merlin.ng/wiki/Policy-based-routing
 
Last edited:
ColinTaylor said:
I'm not sure I'm understanding your problem. The Network Services Filter only blocks LAN traffic going through the WAN interface. It doesn't block LAN traffic going through the VPN interface.

What is UDP port 1197? Is that some service used by your NAS or is that the port used by your VPN client?

If you want to selectively route certain clients through the VPN and others through the WAN you shouldn't be using the Network Services Filter you should be using Policy Based Routing instead: https://github.com/RMerl/asuswrt-merlin.ng/wiki/Policy-based-routing
Click to expand...
On my Synology I have setup an openVPN connection which connects to UDP 1197. I haven't setup vpn on the router itself. I thought by blocking all ports for a specific client ip under Network Service Filter, I could block the NAS (at least this is how it worked on my Netgear). But if I understand correctly I should be using Policy Based Routing for this instead?
 
ColinTaylor said:
Bear in mind that your Network Services Filter rules are only blocking TCP and UDP. Ping uses ICMP so that won't be blocked.
Click to expand...
Thanks for pointing out. Indeed ping uses ICMP protocol. Seems to work after all when I check using wget. Maybe I'll checkout using vpn client on the router instead of Synology, since vpn connection on syno is not so reliable.
 
You must log in or register to reply here.

Similar threads

N
Skynet SkyNet/Firewall blocking all ping requests, including outbound
Replies
6
Views
545
nearlyheadlessarvie
N
octopus
  • Locked
Solved Can you connect to Wireguard server from wan side?
Replies
17
Views
2K
octopus
octopus
A
Policy-based port routing to bypass NordVPN client
Replies
10
Views
2K
Don->
D
v.y.k
iptables pkts & bytes numbers are too low on Merlin 3004.388
Replies
13
Views
1K
v.y.k
v.y.k
A
ASUS Dual WAN Failover, Then Failback, Leaves Secondary LAN in "Hot Standby"
Replies
4
Views
2K
Kingp1n
K
Similar threads
Thread starter Title Forum Replies Date
D RT-AX88U - WiFi 2.4 GHz client has degraded internet connection speed when the router has connected to the internet via 4G modem Asuswrt-Merlin 3
K Toggle VPN Director rules for WireGuard via SSH Asuswrt-Merlin 2
S Route add via SSH - persistent-how? Asuswrt-Merlin 4
S Prevent client from connecting to router but allow connection to internet via access point Asuswrt-Merlin 4
N Connecting an ax58u to a BT homehub 5, via a lan port, and not getting internet access. Asuswrt-Merlin 3
O Assigned IP address to the WAN interface via VPN director: no internet connection - why? Asuswrt-Merlin 1
T Enabling SQM only on Asymmetrical Connection (1150/40) via AX86U Pro (3004.388.4) Asuswrt-Merlin 5
M IPv6 and Router Advertisement adding route to delegated /56 via WAN interface Asuswrt-Merlin 2
A Upgraded my ASUS, issues with NordVPN via OpenVPN Asuswrt-Merlin 4
K The dreaded "HTTPS is a relatively more secured web access protocol. We strongly suggest to enter the ASUS router setting page via HTTPS protocol." Asuswrt-Merlin 16

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Members online

Total: 912 (members: 15, guests: 897)
Top