What's new

Port redirection limited to source IP address range

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

Sizzlechest

Regular Contributor
I have a X4S router with Voxel's V1.0.2.43SF firmware. I'd like to do the following: Forward traffic from WAN port 443 to port 5000 on 192.168.1.100 BUT ONLY for a specific source IP range. Setting up 443:192.168.1.100:5000 port forwarding (from all IP addresses) can be done from the GUI. I'm assuming what I want can be done through a set of "iptables" commands. I know how to implement the commands so they get executed whenever the router boots, but I'm not that adept with iptables to figure out which ones will do what I want.

Instead of getting the forwarding rule to be limited, I tried to limit port 443 to only the range:

iptables -A INPUT -p tcp --dport 443 -s XXX.YYY.0.0/17 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

These rules have no effect on 443.

EDIT: Do I have to restart some service for these rules to take effect? Should these be inserted at the top of the list of rules for the INPUT chain?
 
Last edited:
I have a X4S router with Voxel's V1.0.2.43SF firmware. I'd like to do the following: Forward traffic from WAN port 443 to port 5000 on 192.168.1.100 BUT ONLY for a specific source IP range. Setting up 443:192.168.1.100:5000 port forwarding (from all IP addresses) can be done from the GUI. I'm assuming what I want can be done through a set of "iptables" commands. I know how to implement the commands so they get executed whenever the router boots, but I'm not that adept with iptables to figure out which ones will do what I want.

Instead of getting the forwarding rule to be limited, I tried to limit port 443 to only the range:

iptables -A INPUT -p tcp --dport 443 -s XXX.YYY.0.0/17 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

These rules have no effect on 443.

EDIT: Do I have to restart some service for these rules to take effect? Should these be inserted at the top of the list of rules for the INPUT chain?

Check this post regarding own iptables rules:

https://www.snbforums.com/threads/c...-0-2-40sf-1-0-2-41sf.42222/page-2#post-361291

Voxel.
 
I understand that once I have the iptables rules that work for me, I would add them to the net-wall file. However, shouldn't running the commands in the shell (via a ssh session) work? I know they won't persist over a reboot, but isn't that how I would test them?
 
This NETGEAR's firewall net-wall (no source codes due to NG's security) is executed from many pre-built binaries (also no source codes), so I cannot control the logic . So if you want to add your own rules every time when net-wall is called you should modify my script what is shell over NETGEAR's original net-wall.

E.g. I want to use my own rules (needed for OpenVPN client):

Code:
    iptables -I INPUT -i tun0 -j ACCEPT
    iptables -I OUTPUT -j ACCEPT
    iptables -I FORWARD 2 -i tun0 -j ACCEPT
    iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
    iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
    iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

But I cannot use just "iptables" command because original net-wall from NG will spoil my rules. So in my shell I do

1. Call original net-wall-bin (it is NG's binary).

2. After it is called and if it is started with argument "start" I add my own rules:

/usr/sbin/net-wall script:
Code:
. . .
/usr/sbin/net-wall-bin $*                                                                       [call original NG's firewall]
. . .
elif [ "$1" = "start" ] && [ -f /var/run/openvpn-client.pid ]; then  [add my own rules if argument is "start" and OpenVPN client is used]
    iptables -I INPUT -i tun0 -j ACCEPT
    iptables -I OUTPUT -j ACCEPT
    iptables -I FORWARD 2 -i tun0 -j ACCEPT
    iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
    iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
    iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
fi

You should do something like this with your rules. To test it, run from ssh console "net-wall stop" "net-wall start" and check that your rules are added (list rules using iptables command).

Voxel.
 
Why cannot I test my iptables commands by entering them from the command line? I can verify that they are in the list. If I were to enter the commands in the first post, I can verify they are in the list using

Code:
 iptables -nvL --line-numbers

However, they don't seem to have an effect. Are you saying the only way to test is into insert them in the net-wall file and do a stop then start each time?
 
Why cannot I test my iptables commands by entering them from the command line? I can verify that they are in the list. If I were to enter the commands in the first post, I can verify they are in the list using

Code:
 iptables -nvL --line-numbers

However, they don't seem to have an effect. Are you saying the only way to test is into insert them in the net-wall file and do a stop then start each time?

You can try to test iptable commands by entering them directly from command line. And probably they should be alive some time. But with no guarantee if some programs/daemons will execute in parallel "net-wall" immediately (or e.g. after 3 seconds or after 1 min) to rebuild iptables rules and your setting will be lost.

Voxel.
 
I got it working! The problem didn't involve adding the command in the net-wall script. The problem was finding the right iptables command. After I got the correct command figured out, I added it to the /usr/sbin/net-wall wrapper script so the setting will persist.

Add this to the end of the net-wall file:

Code:
if [ "$1" = "start" ]; then
        iptables -t nat -A PREROUTING -p tcp -m tcp -s XXX.YYY.0.0/ZZ --dport 443 -j DNAT --to 192.168.1.AAA:5000
fi

Just change it to the IP address, range, and ports for your application. I'm assuming this command is valid even if the VPN is enabled.

Voxel: Perhaps for future versions, you might consider linking to a bash script in the /root home directory in order to allow custom commands whenever net-wall is run? I'm assuming I will have to patch the net-wall file each time I upgrade the firmware.
 
Last edited:
Voxel: Perhaps for future versions, you might consider linking to a bash script in the /root home directory in order to allow custom commands whenever net-wall is run? I'm assuming I will have to patch the net-wall file each time I upgrade the firmware.

You can use backup and restore on external USB.

https://www.snbforums.com/threads/e...xel-routers-for-sky-uk-etc.41720/#post-353344

I do restore after every flashing. Including my SSH/OpenVPN and dnscrypt changes.

Voxel.
 
Yes, of course backing up the modified files is good. However, there's always the fear of overwriting changes you make on future releases with the older net-wall baseline. What I was suggesting is something along the lines of adding to net-wall:

Code:
if [ "$1" = "start" ] && [ -f "/root/net-wall-start" ]; then
       /root/net-wall-start
fi

where net-wall-start would be a script containing any custom iptables commands (or anything else) that need to get executed on a "net-wall start" condition. That way the net-wall wrapper can be updated in future builds, but the net-wall-start customization can be backed up and restored without interfering.
 
Last edited:

Sign Up For SNBForums Daily Digest

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