1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

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

Discussion in 'Asuswrt-Merlin' started by digdesdev, Jun 13, 2018 at 11:01 PM.

  1. digdesdev

    digdesdev Occasional Visitor

    Joined:
    Jun 5, 2018
    Messages:
    10
    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.
     
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. agilani

    agilani Regular Contributor

    Joined:
    Nov 30, 2012
    Messages:
    164
    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.
     
  4. digdesdev

    digdesdev Occasional Visitor

    Joined:
    Jun 5, 2018
    Messages:
    10
    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?
     
  5. FreshJR

    FreshJR Very Senior Member

    Joined:
    Oct 8, 2016
    Messages:
    694
    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: Jun 14, 2018 at 8:36 PM
  6. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,469
    Location:
    UK
    @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 likes this.
  7. FreshJR

    FreshJR Very Senior Member

    Joined:
    Oct 8, 2016
    Messages:
    694
    @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: Jun 16, 2018 at 3:18 AM
  8. digdesdev

    digdesdev Occasional Visitor

    Joined:
    Jun 5, 2018
    Messages:
    10
    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?
     
  9. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    12,486
    Location:
    San Diego, CA
    Just keep in mind that iptables is a chained list - so it's important to note where the new rule is placed...
     
  10. digdesdev

    digdesdev Occasional Visitor

    Joined:
    Jun 5, 2018
    Messages:
    10
    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.
     
  11. FreshJR

    FreshJR Very Senior Member

    Joined:
    Oct 8, 2016
    Messages:
    694
    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: Jun 16, 2018 at 7:26 AM
  12. Martineau

    Martineau Very Senior Member

    Joined:
    Jul 8, 2012
    Messages:
    1,601
    Location:
    UK
    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 ;)
     
    FreshJR likes this.
  13. FreshJR

    FreshJR Very Senior Member

    Joined:
    Oct 8, 2016
    Messages:
    694
    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: Jun 16, 2018 at 7:27 AM
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!