Menu
What's new
By:
Filters Better Search

nat-start for policy-based PORT routing

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

P

pierredugland

Occasional Visitor
Hello,

I have followed the instructions here : https://github.com/RMerl/asuswrt-merlin.ng/wiki/Policy-based-Port-routing-(manual-method)

Here is my nat-start

Code: 
#!/bin/sh

sleep 10  # During the boot process nat-start may run multiple times so this is required               

# Ensure duplicate rules are not created
for VPN_ID in 0 1 2 3 4 5
   do
      ip rule del prio 999$VPN_ID  2>/dev/null
   done

# Create the RPDB rules
ip rule add from 0/0 fwmark "0x8000/0x8000" table main   prio 9990        # WAN   fwmark
ip rule add from 0/0 fwmark "0x7000/0x7000" table ovpnc4 prio 9991        # VPN 4 fwmark
ip rule add from 0/0 fwmark "0x3000/0x3000" table ovpnc5 prio 9992        # VPN 5 fwmark
ip rule add from 0/0 fwmark "0x1000/0x1000" table ovpnc1 prio 9993        # VPN 1 fwmark
ip rule add from 0/0 fwmark "0x2000/0x2000" table ovpnc2 prio 9994        # VPN 2 fwmark
ip rule add from 0/0 fwmark "0x4000/0x4000" table ovpnc3 prio 9995        # VPN 3 fwmark

iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.1.23 -p tcp -m multiport --dport 8112,8113 -j MARK --set-mark 0x2000/0x2000

I have verified that, when routing all traffic from 192.168.1.23 (using the UI), the vpn does work (i.e the traffic does get routed through the vpn client instance 2).

I have no other jffs scripts on the router. I have the latest (384_16) firmware version and restarted the router after modifying the script just in case.

What am I doing wrong ?

PS : this is p2p traffic so I'm checking the resulting IP by adding a magnet link in my deluge instance running into a docker container on my NAS. The NAS is 192.168.1.23 and the 8112 port on the nas gets forwarded to WAN port 8112 as well.
 
pierredugland said:
re-upping since I have still not found a solution. Is there a better place to ask questions ? SO maybe ?
Click to expand...
Did you check the rules for hits?

e.g. Enter the following one-liner (redact your WAN IP from Table main before posting)
Code: 
echo -e "\n\t"RPDB Rules;ip rule;echo;for I in 1 2 3 4 5;do [ -n "$(nvram get vpn_client${I}_addr)" ] && echo -e "\t"Client ovpnc$I port $(nvram get vpn_client${I}_port) $(nvram get vpn_client${I}_proto) || echo -e "\t"Client ovpnc${I} NOT configured;ip route show table 11$I |  grep -E "^0\.|^128.|^default|^prohibit|tun1";done;echo -e "\n\t"Table main;ip route show table 254 | grep -E "^0\.|^128.|^default"; echo -e "\n\n\tFWMARK Tagging";iptables -nvL PREROUTING -t mangle --line;echo -e "\n\n\tPort Forward";nvram get vts_rulelist
 
Last edited:
Thanks for taking the time:

Code: 
   RPDB Rules
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.4
0.0.0.0/1 via 10.7.5.1 dev tun12
128.0.0.0/1 via 10.7.5.1 dev tun12
default via the_ip dev eth0
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0


        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 3416K packets, 776M bytes)
num   pkts bytes target     prot opt in     out     source               destination 
1        2   120 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7


        Port Forward
<nas-deluge-movies>8112>192.168.1.23>8112>TCP><nas-deluge-tv>8113>192.168.1.23>8113>TCP><nas-radarr>7878>192.168.1.23>7878>TCP><nas-sonarr>8989>192.168.1.23>8989>TCP><nas-dsm>5000>192.168.1.23>5000>TCP><nas-plex>32400>192.168.1.23>32400>TCP><FTP Server>20,21>192.168.1.23>21>TCP><http>80>192.168.1.23>80>TCP><https>443>192.168.1.23>443>TCP>

Interestingly my WAN IP is actually incorrect in that output (instead of XXX.YYY.ZZZ.AAA it is shown as XXX.YYY.ZZZ.1, marked as `the_ip` in the above). Does that mean anything ?
 
pierredugland said:
Thanks for taking the time:

Code: 
   RPDB Rules
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.4
0.0.0.0/1 via 10.7.5.1 dev tun12
128.0.0.0/1 via 10.7.5.1 dev tun12
default via the_ip dev eth0
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0


        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 3416K packets, 776M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        2   120 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7


        Port Forward
<nas-deluge-movies>8112>192.168.1.23>8112>TCP><nas-deluge-tv>8113>192.168.1.23>8113>TCP><nas-radarr>7878>192.168.1.23>7878>TCP><nas-sonarr>8989>192.168.1.23>8989>TCP><nas-dsm>5000>192.168.1.23>5000>TCP><nas-plex>32400>192.168.1.23>32400>TCP><FTP Server>20,21>192.168.1.23>21>TCP><http>80>192.168.1.23>80>TCP><https>443>192.168.1.23>443>TCP>

Interestingly my WAN IP is actually incorrect in that output (instead of XXX.YYY.ZZZ.AAA it is shown as XXX.YYY.ZZZ.1, marked as `the_ip` in the above). Does that mean anything ?
Click to expand...
First observation you have not ENABLED Selective Routing as evidenced by
Code: 
0.0.0.0/1 via 10.7.5.1 dev tun12
128.0.0.0/1 via 10.7.5.1 dev tun12

I suggest you ENABLE Selective Routing in the GUI and assuming you want ALL LAN traffic to default via VPN Client 2 - but ensure the router itself is always via the WAN

upload_2020-4-28_9-38-15.png


then recheck the rules
 
Last edited:
Did your manipulation thank you for that. Stupidly thought the nat-start script took precedence over the GUI. The dropdown menu was on Policy Rules but not strict and the table below was empty.

I only want to filter some ports coming from my NAS (sitting at 192.168.1.23) so I have done the below :

upload_2020-4-28_16-59-14.png


The new output of your one liner is now :

Code: 
        RPDB Rules
0:      from all lookup local
10201:  from 192.168.1.1 lookup main
10301:  from 192.168.1.23 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.2
default via 10.7.5.1 dev tun12
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0


        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 1757 packets, 663K bytes)
num   pkts bytes target     prot opt in     out     source               destination 
1      100 15023 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
 
Last edited:
pierredugland said:
Did your manipulation thank you for that. Stupidly thought the nat-start script took precedence over the GUI.
I only want to filter some ports coming from my NAS (sitting at 192.168.1.23) so I have done the below :

View attachment 23100

The new output of your one liner is now :

Code: 
        RPDB Rules
0:      from all lookup local
10201:  from 192.168.1.1 lookup main
10301:  from 192.168.1.23 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.2
default via 10.7.5.1 dev tun12
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0


        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 1757 packets, 663K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      100 15023 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
Click to expand...
OK, so the VPN Client 2 default gateway is now via VPN tun12 interface (10.7.5.1) rather than the WAN eth0 interface

If you only want to route ALL traffic from a single device (192.168.1.23) via the VPN then you don't need the explicit router rule via the WAN as that is the default anyway.

So now it appears nat-start hasn't run correctly to create the RPDB rules, and the fwmark mark tagging rule for Selective Port routing.

you should manually rerun nat-start
Code: 
cd /jffs/scripts

./nat-start
then recheck the rules
 
Thank you.

I would like to route only specific ports traffic from 192.168.1.23 to the VPN, [the rest of the ports on 192.168.1.23] and [all the other devices] should run through WAN (the default as you mention). Not ALL traffic from this device.

When I try to manually run the script :
upload_2020-4-28_17-20-0.png


Do I need to run it as root ?
 
pierredugland said:
When I try to manually run the script :
View attachment 23101

Do I need to run it as root ?
Click to expand...
Run
Code: 
dos2unix /jffs/scripts/nat-start
then retry.
pierredugland said:
I would like to route only specific ports traffic from 192.168.1.23 to the VPN, [the rest of the ports on 192.168.1.23] and [all the other devices] should run through WAN (the default as you mention).

Not ALL traffic from this device.
Click to expand...
You should remove the NAS (192.168.1.23) entry from the Selective Routing GUI
 
Last edited:
Ahah that's why the table was empty then ! :)
Thks for the dos2unix trick. I ran the script but unfortunately it didn't seem to do anything as my IP tracker still indicates my WAN IP.
The output of your one liner is now :
Code: 
        RPDB Rules
0:      from all lookup local
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9992:   from all fwmark 0x3000/0x3000 lookup ovpnc5
9993:   from all fwmark 0x1000/0x1000 lookup ovpnc1
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x4000/0x4000 lookup ovpnc3
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.2
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0

        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 24655 packets, 21M bytes)
num   pkts bytes target     prot opt in     out     source               destination  
1        1    60 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2        0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.1.23-192.168.1.23 multiport dports 8112,8113 MARK or 0x2000

the_ip still does not match my actual WAN IP though. Should I care ?
Looks like the rules are now active. Do I need to restart my router ?
 
pierredugland said:
Ahah that's why the table was empty then ! :)
Thks for the dos2unix trick.
I ran the script but unfortunately it didn't seem to do anything as my IP tracker still indicates my WAN IP.
The output of your one liner is now :
Code: 
        RPDB Rules
0:      from all lookup local
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9992:   from all fwmark 0x3000/0x3000 lookup ovpnc5
9993:   from all fwmark 0x1000/0x1000 lookup ovpnc1
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x4000/0x4000 lookup ovpnc3
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.2
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0

        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 24655 packets, 21M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        1    60 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2        0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.1.23-192.168.1.23 multiport dports 8112,8113 MARK or 0x2000

the_ip still does not match my actual WAN IP though. Should I care ?
Looks like the rules are now active. Do I need to restart my router ?
Click to expand...
pierredugland said:
Ahah that's why the table was empty then ! :)
Thks for the dos2unix trick.
Click to expand...
Only use a native unix LF aware editor, i.e. notepad++ or if using windows, install WinSCP then use its internal editor, or use the router's nano editor.
pierredugland said:
the_ip still does not match my actual WAN IP though. Should I care ?
Click to expand...
Well it depends.....if you are double NAT etc. but clearly if you are able to surf the Internet then does it matter?

pierredugland said:
Looks like the rules are now active. Do I need to restart my router ?
Click to expand...
No

So finally the Selective Port Routing environment is almost correct... i.e. I don't know why this
Code: 
default via 10.7.5.1 dev tun12
route that you previously had before shown in post #6 is now missing? (you may need to add a dummy entry say 172.16.2.1 to the Selective Routing GUI)

Anyway, you now need to generate traffic for the destination ports 8112/8113 from the NAS to see if there are hits on the fwmark tagging rule.
​
 
Last edited:
Thanks again for your detailed replies.

Well it depends.....if you are double NAT etc. but clearly if you are able to surf the Internet then does it matter?
Click to expand...
I only asked in case it was an issue to redirect the traffic. Clearly, as long as the redirection through the VPN works I don't care :)

route that you previously had before shown in post #6 is now missing? (you may need to add a dummy entry say 172.16.2.1 to the Selective Routing GUI)
Click to expand...
The only difference is I emptied the table again (removing the WAN default for the router and the 192.168.1.23 rule). Shall I put in the WAN default for the router again ? Even though it should not matter one iota for this.


Anyway, you now need to generate traffic for the destination ports 8112/8113 from the NAS to see if there are hits on the fwmark tagging rule.
Click to expand...
There is constant traffic through those ports.
The output is now (after adding the dummy entry in the GUI):
Code: 
        RPDB Rules
0:      from all lookup local
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9992:   from all fwmark 0x3000/0x3000 lookup ovpnc5
9993:   from all fwmark 0x1000/0x1000 lookup ovpnc1
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x4000/0x4000 lookup ovpnc3
10301:  from 172.16.2.1 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

        Client ovpnc1 port 8443 tcp-client
        Client ovpnc2 port 8443 tcp-client
10.7.5.0/24 dev tun12  proto kernel  scope link  src 10.7.5.2
default via 10.7.5.1 dev tun12
        Client ovpnc3 NOT configured
        Client ovpnc4 NOT configured
        Client ovpnc5 NOT configured

        Table main
default via the_ip dev eth0


        FWMARK Tagging
Chain PREROUTING (policy ACCEPT 3172 packets, 392K bytes)
num   pkts bytes target     prot opt in     out     source               destination   
1        1    60 MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2        0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.1.23-192.168.1.23 multiport dports 8112,8113 MARK or 0x2000
 
Last edited:
Micheless said:
hi I'm new in the forum,i have a problem with policy rules,sometimes they work most of the time they don't work,I can't understand the cause of the problem ipv6 disabled automatic ip please help me or an rt-ac86u fails to establish the client when imposed on political rules
Click to expand...

maybe create your own thread since this seems to be a different issue ?
 
pierredugland said:
The only difference is I emptied the table again (removing the WAN default for the router and the 192.168.1.23 rule). Shall I put in the WAN default for the router again ? Even though it should not matter one iota for this.
Click to expand...
I would try inserting the dummy GUI entry (then restart VPN Client 2), if that doesn't work, then you could reinstate the redundant 'router via WAN' entry.
pierredugland said:
There is constant traffic through those ports.
Code: 
2        0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.1.23-192.168.1.23 multiport dports 8112,8113 MARK or 0x2000
Click to expand...
Well according to the iptables rule above, there is no TCP port 8112/8113 outbound from 192.168.1.23 that is to be redirected via the VPN Client?

So either the source IP / destination Ports / protocol are incorrect or the hardware acceleration feature is bypassing the iptables tagging rule.
 
Martineau said:
I would try inserting the dummy GUI entry (then restart VPN Client 2), if that doesn't work, then you could reinstate the redundant 'router via WAN' entry.
Click to expand...
As you can see in my post above the
Code: 
default via 10.7.5.1 dev tun12
is back


Martineau said:
So either the source IP / destination Ports / protocol are incorrect or the hardware acceleration feature is bypassing the iptables tagging rule.
Click to expand...
I am fairly sure that the source IP and ports are correct.
How would I test protocol and/or hardware acceleration bypassing the iptables tagging ?
 
pierredugland said:
As you can see in my post above the
Code: 
default via 10.7.5.1 dev tun12
is back



I am fairly sure that the source IP and ports are correct.
How would I test protocol and/or hardware acceleration bypassing the iptables tagging ?
Click to expand...
Just to make sure, I tested adding a rule in the GUI to route ALL traffic from 192.168.1.23 through the VPN and it works so at least the source IP is correct. And I have specifically forwarded those ports through the GUI as well so reasonnably confident the ports are correct as well.
 
pierredugland said:
As you can see in my post above the
Code: 
default via 10.7.5.1 dev tun12
is back

I am fairly sure that the source IP and ports are correct.
How would I test protocol and/or hardware acceleration bypassing the iptables tagging ?
Click to expand...

You can test if the VPN redirect is working

e.g. temporarily redirect standard Web URL HTTP/HTTPS TCP ports 80/443 via VPN Client 2 for your laptop xxx.xxx.xxx.xxx
Code: 
iptables -t mangle -A PREROUTING -i br0 --src xxx.xxx.xxx.xxx -p tcp -m multiport --dport 80,443 -j MARK --set-mark 0x2000/0x2000
then browse a few websites, and check if there are hits in the fwmark tagging rule.

Use the following command to remove the temporary Web URL rediection.
Code: 
iptables -t mangle -D PREROUTING -i br0 --src xxx.xxx.xxx.xxx -p tcp -m multiport --dport 80,443 -j MARK --set-mark 0x2000/0x2000
 
pierredugland said:
And I have specifically forwarded those ports through the GUI as well so reasonnably confident the ports are correct as well.
Click to expand...
GUI Port Forwarding is inbound from the WAN:rolleyes::rolleyes:
 
Martineau said:
GUI Port Forwarding is inbound from the WAN:rolleyes::rolleyes:
Click to expand...
Damn I knew it was something stupid !
Tested the above and it shows correct redirection. Thank you so much for figuring out that PEBKAC :)

So the command for outbound redirection would then be :
Code: 
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.23 -p tcp -m multiport --dport 8112,8113 -j MARK --set-mark 0x2000/0x2000
?

Do I need to add that to the nat-start script for it not to be lost on router restart or whatnot ?
 
pierredugland said:
Damn I knew it was something stupid !
Tested the above and it shows correct redirection. Thank you so much for figuring out that PEBKAC :)

So the command for outbound redirection would then be :
Code: 
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.23 -p tcp -m multiport --dport 8112,8113 -j MARK --set-mark 0x2000/0x2000
Click to expand...
NO!
The '-D' means delete the iptables rule, it has nothing to do with (inbound/outbound) 'direction'.

I have no idea what NAS application uses destination port 8112/8113, but if you are trying to host a 'hidden' service on your NAS that can only be accessed by 'your friends' inbound through the VPN Client 2 tunnel, then you need to customise other features....

i.e. Does your VPN ISP actually allow unsolicited traffic requests inbound via the VPN Client 2 tunnel to your LAN? - most don't.

However, if it does then you will need to setup the port forward rules(s) on the VPN ISP's dashboard, and enable VPN inbound firewall on the router etc.

upload_2020-4-28_15-12-42.png


Good luck.
 
You must log in or register to reply here.

Similar threads

deefour
Forcing device-specific port-range through VPN
Replies
9
Views
697
ZebMcKayhan
Z
A
Policy-based port routing to bypass NordVPN client
Replies
10
Views
1K
Don->
D
GShlomi
Sharing my DualWan with port forwarding and DDNS experience
Replies
0
Views
133
GShlomi
GShlomi
G
VPN Client with Public IP, split tunnel web server over VPN and other traffic not on the VPN
Replies
4
Views
398
Grefyne
G
R
Domain VPN Routing
2
Replies
24
Views
2K
Ranger802004
R
Similar threads
Thread starter Title Forum Replies Date
Z wgclient-start with iptables nat rules after router reboot Asuswrt-Merlin 19
Mr Solis Enabling NAT Acceleration (CTF) breaks Port Forwarding? (RT-AC68U w/ 386.12_4) Asuswrt-Merlin 17
K Double NAT? Asuswrt-Merlin 1
H WireGuard Server "Enable NAT - IPv6" Setting Question Asuswrt-Merlin 0
M NAT over VPN? Asuswrt-Merlin 1
Nas.CloudBusinessPortal Double nat & dhcp Asuswrt-Merlin 10
N Asus AC66U and full cone NAT Asuswrt-Merlin 11
Y ASUS AC86U Firmware merlin 386.11 - NAT Loopback not working please help ! Asuswrt-Merlin 6
Mogsy Solved Need help with NAT fix. Asuswrt-Merlin 1
F Disable/enable NAT Loopback? Asuswrt-Merlin 4

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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

Members online

Total: 661 (members: 20, guests: 641)
Top