What's new

Is it possible to block IP ranges from specific ports either directly or with Skynet?

  • 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!

digdesdev

Occasional Visitor
The need is to block ranges from trying to hack the VoIP while allowing office users to access websites with IP addresses within those ranges. I.e., can I blacklist IP addresses or ranges from specific ports while allowing access to others?

I haven't been able to find any info or posts that reference this ability. No is an OK answer but if there is a way to do this I would appreciate any help or references to the information on how.
 
Did you look at the firewall netfilter? Both that and skynet have these type of features. For example, i block some of the common ports for upnp so i don't have to disable it completely.
 
Unless I'm misunderstanding the operation of netfilter (which is a good possibility) that is only a LAN to WAN filter and prevents LAN devices from accessing the Internet.

What I need is a WAN to LAN filter so remote systems from blocked addressses can't access the VoIP system ports but other IP addresses can. Can I configure it that way? If I put in the range I want to block as the Source IP, will that accomplish the function I need?
 
Unless I'm misunderstanding the operation of netfilter (which is a good possibility) that is only a LAN to WAN filter and prevents LAN devices from accessing the Internet.

What I need is a WAN to LAN filter so remote systems from blocked addressses can't access the VoIP system ports but other IP addresses can. Can I configure it that way? If I put in the range I want to block as the Source IP, will that accomplish the function I need?

EDIT: this was incorrect

Your understanding is incorrect.

The network service filter will work regardless if the direction is

LAN --> WAN
or
WAN --> LAN

Eg. the following 4 configurations are all equally valid:
1) traffic originating from LAN device 192.168.1.100
2) traffic originating from WAN server 75.75.75.75
3) traffic destined towards LAN device 192.168.1.100
4) traffic destined towards WAN server 75.75.75.75

As you can see, it doesn't matter if you are filter/matching on a WAN or LAN ip.

---

You were correct that it indeed is only a LAN -- WAN filter.

What this means is that

1) WAN traffic destined towards router itself (aka not forwarded towards a LAN device) will not match the filtering elements
&&
2) WAN traffic originating from the router (aka not forwarded from a LAN device) will also not be filter

This generally means that blacklisting known hacking IP's will not have your router drop the packets if the target is the router itself.

Only during the LAN --> WAN (or vise versa) exchange is the filter evaluated.

---

In short the netfilter only filters on traffic pushed towards or comming from the LAN side
The traffic that is pushed or originating from the ROUTER ITSELF, it will not be filtered.
 
Last edited:
Only during the LAN --> WAN (or vise versa) exchange is the filter evaluated.

In short the netfilter only filters on traffic pushed towards or comming from the LAN side
@FreshJR Can you double check that. In John's firmware it only blocks LAN to WAN, not WAN to LAN.

The reason being that the netfilter rules generated include the in-interface and out-interface. Here is the rule generated if I try to block a source address of 1.2.3.4 and a destination of 192.168.1.33.

-A FORWARD -s 1.2.3.4/32 -d 192.168.1.33/32 -i br0 -o eth0 -p tcp -j DROP
 
@FreshJR Can you double check that. In John's firmware it only blocks LAN to WAN, not WAN to LAN.

The reason being that the netfilter rules generated include the in-interface and out-interface. Here is the rule generated if I try to block a source address of 1.2.3.4 and a destination of 192.168.1.33.

-A FORWARD -s 1.2.3.4/32 -d 192.168.1.33/32 -i br0 -o eth0 -p tcp -j DROP

@colin & @digdesdev, you are correct. Now, the second time around, when I checked iptables I actually did see the "-i br0 -o eth0" specifcation within NSFW chain individual rules. The main FORWARD rule responsible for directing traffic into the NSFW chain does not limit via interface!

So OP was correct. Netfilter:

1) is only performing LAN -> WAN filtering
2) is not performing WAN -> LAN filtering
3) is not performing filtering on locally destined/generated router traffic.


Thanks for notifying me of this shortcoming!!! Redacted my previous post.

I originally thought it was both directions since the initial rule directing traffic into the NSFW chain had ANY as the interfaces listed.

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 NSFW       all  --  any    any     anywhere             anywhere

I now see that they DO specify interfaces within the individual rules within NSFW chain!

Code:
Chain NSFW (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  br0    eth0    192.168.2.100         anywhere

EDIT:

OP If you already have firewall-start created (from installing other scripts), you can use the following code.
Code:
echo 'iptables -D FORWARD -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start
echo 'iptables -A FORWARD -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start

If you do not have firewall-start created you can use the following code. (NOTE: This will overwrite existing firewall start if it exists.)
Code:
echo '#!/bin/sh' > /jffs/scripts/firewall-start
echo 'iptables -D FORWARD -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start
echo 'iptables -A FORWARD -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start
chmod 755 /jffs/scripts/firewall-start

Look up CIDR calulator to define ipranges.

"-s" = block these originating ipranges
"-d" = if they are directed towards these destined ip ranges

--

If you want to limit by destination ports instead desitnation IP's I can provide the alternative syntax.
 
Last edited:
I appreciate all the help and discussion on how the filtering rules work for this newbie.

With regard to this line:

Code:
iptables -D FORWARD -s 75.0.0.0/8 -d 192.168.1.100/32 -j DROP

Just to clarify this for me, this will drop any traffic from any IP address in the 75.x.x.x range that is being routed to 192.168.1.100. This traffic would be routed to that destination because of another rule, probably because of a port forward. Traffic bound for another port that is not forwarded to 192.168.1.100 will not be blocked. Correct?

If my understanding is correct, it seems like it will do what I need as only the source addresses accessing the SIP ports will be forwarded to the VoIP controller and then dropped.

I do have an existing firewall-start script (as Colin and FreshJR know, having helped me get it to run.) Once I understand the rule construction I can edit it as needed.

One last point to clarify is the sequence of rules in the chain with regard to Port forwarding table entries and the firewall-start generated rules. Are we sure that the Port Forward rules come first? If not, this may not work as expected. Would I be better off clearing the GUI table and just manually creating the port forward rules in the firewall-start script so that I can force the order?
 
One last point to clarify is the sequence of rules in the chain with regard to Port forwarding table entries and the firewall-start generated rules. Are we sure that the Port Forward rules come first? If not, this may not work as expected. Would I be better off clearing the GUI table and just manually creating the port forward rules in the firewall-start script so that I can force the order?

Just keep in mind that iptables is a chained list - so it's important to note where the new rule is placed...
 
Thanks for confirming that. It seems that the best way to be sure is to create all the FORWARD rules in the firewall-start script and not use the GUI list.
 
Just keep in mind that iptables is a chained list - so it's important to note where the new rule is placed...

Did you mention this to say that the quoted filtering rule isn't going to work if appended to the end of the FORWARD chain?
Or did you mention this as something for user @digdesdev to keep in mind ?

I think for this specific rule and the default ASUS iptables setup, placing the rule at the end of the forward chain should be fine.

I am relatively green in dealing with iptables, but I understand most entries except for one.

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   0     0 ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
-------- ** Accepts existing (previously allowed and still open) connections

   0     0 other2wan  all  --  !br0   eth0    anywhere             anywhere
-------- ** Chain dealing with outgoing traffic not originating from LAN   ( Used to DROP non Tunneled --> WAN traffic)

   0     0 DROP       all  --  any    any     anywhere             anywhere             state INVALID
-------- ** Drops any invalid packets

   0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere
-------- **Accepts LAN to LAN traffic

   0     0 NSFW       all  --  any    any     anywhere             anywhere
-------- ** Chain dealing with outgoing LAN -> WAN traffic ( Used to DROP defined traffic in WebUI Net Service Filter)

   0     0 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
-------- ** Not sure

   0     0 OVPN       all  --  any    any     anywhere             anywhere             state NEW
-------- ** Chain dealing with NEW connections  ( No idea why it has the OVPN name as it is not exclusively OpenVPN traffic, but chain is empty)

   0     0 ACCEPT     all  --  br0    any     anywhere             anywhere
-------- ** Accept outgoing traffic originating from LAN

@digdesdev
If you create this rule

Code:
iptables -A FORWARD -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP

Traffic from 75.75.75.75 would typically NOT be able to reach the local device at 192.168.1.100 even if 192.168.1.100 is open / port forwarded.

This is UNLESS 192.168.1.100 would be the first one to reach out and communicate with 75.75.75.75 (assuming you havent blocked outgoing communication via NSFW/WebUI).

If 192.168.1.100 can successfully initiate communication with 75.75.75.75, the "RELATED,ESTABLISHED" rule will keep communication between the two devices open instead of iptables transversing downwards towards your “blacklist” rule and acting upon it.

Traffic from 75.75.75.75 would be able to reach every other device on the network uninhibited. This is since the blacklist rule was only defined to block 75.75.75.75 from dealing with 192.168.1.100
 
Last edited:
Code:
 0     0 OVPN       all  --  any    any     anywhere             anywhere             state NEW
-------- ** Chain dealing with NEW connections  ( No idea why it has the OVPN name as it is not exclusively OpenVPN traffic, but chain is empty)

Indeed, ALL new connections in the INPUT/FORWARD chains hit the OVPN chain, but is only populated with up to 5 lines - one for each of the OpenVPN tunxx interfaces.

NOTE: You can use www.vpnbook.com for OpenVPN testing - which may also burden you with VPN development of your QOS script ;)
 
Traffic from 75.75.75.75 would typically NOT be able to reach the local device at 192.168.1.100 even if 192.168.1.100 is open / port forwarded.

This is UNLESS 192.168.1.100 would be the first one to reach out and communicate with to 75.75.75.75 (assuming this action isn't blocked aswell via the NSFW/WebUI). If 192.168.1.100 can successfully initiate communication with 75.75.75.75, the "RELATED,ESTABLISHED" rule will keep communication between devices open instead of transversing downwards and consulting your "blacklist" rule.

Traffic from 75.75.75.75 would be able to reach every other device on the network uninhibited. This is since the blacklist rule was only defined to block 75.75.75.75 from dealing with 192.168.1.100

I would like to edit my previous response, once more.

Thanks to @ColinTaylor, I learned that this following rule's function is to ACCEPT traffic IF it is a result of a port forward /UPnP.

Code:
   0     0 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT


This makes the bolded statement in my previous post partially invalid!

To clarify, The blacklist rule would work as previously explained BUT it would be over-riden by a port forward.

So @digdesdev, your blacklist rule should ideally be placed above the "Accept (DNAT)" rule if you want the blacklist rule to get a higher evaluation priority than a port forward.

We can leverage the position of the NSFW chain being above the "Accept (DNAT)" rule to do so and use the following firewall-start entry.

Code:
echo 'iptables -D NSFW -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start
echo 'iptables -A NSFW -s 75.75.75.75/32 -d 192.168.1.100/32 -j DROP' >> /jffs/scripts/firewall-start


Hope this made sense.
 
Last edited:
Sorry for the delayed reply. Life gets in the way. :)

I'll try this new rule format. I do appreciate everyone's efforts.
 

Latest threads

Sign Up For SNBForums Daily Digest

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