Port Forward while using VPN Client

[mcb03]

Router: ASUS RT-AC87U
Firmware: 378.56_2

I am currently using the VPN Client on my router to selective tunnel traffic to/from some of the LAN clients.

In other words, I have "Redirect Internet traffic" set to "Policy Rules"...

..and I have rules for some of the LAN clients where I specify "Destination IP" "0.0.0.0" and "Iface" "VPN".

If I add a "WAN -> Port Forward" entry to forward traffic for a particular port to the device, it will not be received as long as it is a VPN user.

Can this be achieved with some additional iptable rules? If so, please provide an example.

I can SSH port forward through the router to the desired host and port even when it is a VPN user.

However, I need help figuring out how to achieve this without using an SSH port forward.

Thanks!

 

[cosmoxl]

iptables -I FORWARD -i tun11 -p udp -d 192.168.2.42 --dport 61370 -j ACCEPT

iptables -I FORWARD -i tun11 -p tcp -d 192.168.2.42 --dport 61370 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 61370 -j DNAT --to-destination 192.168.2.42

iptables -t nat -I PREROUTING -i tun11 -p udp --dport 61370 -j DNAT --to-destination 192.168.2.42

there's the pattern you need. change TUN device, port, IP address to suit.

 

[mcb03]

Thanks for the quick reply!

I left out the fact that I want the port forward to be from the router's regular public IP address (eth0) to the private IP address of the host in question.

I modified your example a little and tried this:

iptables -I FORWARD -p tcp -d 192.168.1.150 --dport 8883 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp -i eth0 --dport 8883 -j DNAT --to-destination 192.168.1.150:8883

However, when I sniff for 8883 traffic on the .150 host, I see no packets.

To summarize, I want to send TCP traffic over port 8883 to my router's public IP address and have it forwarded to one of it's LAN hosts that is using the router's VPN client.

 

[mcb03]

Sorry FORWARD rule I tried is:

iptables -I FORWARD -i eth0 -p tcp --dport 8883 -j ACCEPT

 

[RMerlin]

You will have to disable the VPN tunnel for that client. You cannot accept inbound connections on the WAN and send back traffic on the VPN - traffic must go in both direction on the same interface.

 

[Mikeyy]

You will have to disable the VPN tunnel for that client. You cannot accept inbound connections on the WAN and send back traffic on the VPN - traffic must go in both direction on the same interface.

This is script that works:

#!/bin/sh
sleep 10
for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 0 > $i
done

#
# Delete table 100 and flush any existing rules if they exist.
#
ip route flush table 100
ip route del default table 100
ip rule del fwmark 1 table 100
ip route flush cache
iptables -t mangle -F PREROUTING

#
# Copy all non-default and non-VPN related routes from the main table into table 100.
# Then configure table 100 to route all traffic out the WAN gateway and assign it mark "1"
#
# NOTE: Here I assume the OpenVPN tunnel is named "tun11".
#
#

ip route show table main | grep -Ev ^default | grep -Ev tun11 \
| while read ROUTE ; do
ip route add table 100 $ROUTE
done
ip route add default table 100 via $(nvram get wan_gateway)
ip rule add fwmark 1 table 100
ip route flush cache

#
# Define the routing policies for the traffic. The rules will be applied in the order that they
# are listed. In the end, packets with MARK set to "0" will pass through the VPN. If MARK is set
# to "1" it will bypass the VPN.
#

# SSH Traffic: Bypass VPN
iptables -t mangle -A PREROUTING -i br0 -p tcp --sport 6001 --match iprange --src-range 192.168.1.100 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p tcp --match multiport --sports 7001:7005,7748 --match iprange --src-range 192.168.1.101 -j MARK --set-mark 1

Problem is, it sometimes doesn't work.
For example, if script is working and I change something in router settings (via GUI), script stops working.
Not all settings, but some probably restart some of needed components and they revert to default.

Anyway, I also tried using just last 2 lines without script before them, and it won't work.

Do you know why?

P.S. Didn't make this script, it's based on your web wiki, and CODYQX4 was first to make it work. I don't really understand what it does.

 

[Martineau]

This is script that works:

<snip>

Problem is, it sometimes doesn't work.
For example, if script is working and I change something in router settings (via GUI), script stops working.
Not all settings, but some probably restart some of needed components and they revert to default.

Anyway, I also tried using just last 2 lines without script before them, and it won't work.

Do you know why?

P.S. Didn't make this script, it's based on your web wiki, and CODYQX4 was first to make it work. I don't really understand what it does.

If the routing suddenly fails then this previously was due to the (RT-AC56U/RT-AC68U etc. ) TrendMicro DPI engine flushing the

iptables -t mangle PREROUTING

entries....I believe the DPI engine restarts itself overnight every couple of days or so?

If your script is executed/defined as part of the VPN Client custom configuration, you could try adding the following to /jffs/scripts/nat-start

# Is the actual VPN client UP....well is there a route to the VPN? or does folder /etc/openvpn/clientx exist?
# If so then selective routing tagging will be broken until the '-t mangle PREROUTING' chain is reinstated for the VPN Client
VPN_LIST="1 2"
for VPNID in $VPN_LIST
   do
       VPNROUTE=`ip route show | grep -i -a "dev tun1"$VPNID`
       logger -s -t "($(basename $0))" $$ "Checking if VPN Client$VPNID is UP...."$VPNROUTE
       if [ "$VPNROUTE" != "" ];then
          logger -s -t "($(basename $0))" $$ "**Warning VPN Client$VPNID is UP.... restarting VPN Client$VPNID"
          service restart_vpnclient$VPNID
          sleep 30        # Delay starting the second VPN client just to keep the syslog entries separate for easier debugging
       fi
   done

 

[Mikeyy]

If the routing suddenly fails then this previously was due to the (RT-AC56U/RT-AC68U etc. ) TrendMicro DPI engine flushing the

iptables -t mangle PREROUTING

entries....I believe the DPI engine restarts itself overnight every couple of days or so?

Using N66U. I don't think I have TrendMicro as option, maybe if it's active in background without GUI.
But your guess sounds close since port forwarding would work again after next "openvpn-event".

If your script is executed/defined as part of the VPN Client custom configuration, you could try adding the following to /jffs/scripts/nat-start

I'm using openvpn-event script.

# Is the actual VPN client UP....well is there a route to the VPN? or does folder /etc/openvpn/clientx exist?
# If so then selective routing tagging will be broken until the '-t mangle PREROUTING' chain is reinstated for the VPN Client
VPN_LIST="1 2"
for VPNID in $VPN_LIST
   do
       VPNROUTE=`ip route show | grep -i -a "dev tun1"$VPNID`
       logger -s -t "($(basename $0))" $$ "Checking if VPN Client$VPNID is UP...."$VPNROUTE
       if [ "$VPNROUTE" != "" ];then
          logger -s -t "($(basename $0))" $$ "**Warning VPN Client$VPNID is UP.... restarting VPN Client$VPNID"
          service restart_vpnclient$VPNID
          sleep 30        # Delay starting the second VPN client just to keep the syslog entries separate for easier debugging
       fi
   done

So this script just jumpstarts VPN client on every nat start if it's down?

 

[Martineau]

Using N66U. I don't think I have TrendMicro as option, maybe if it's active in background without GUI.
But your guess sounds close since port forwarding would work again after next "openvpn-event".



I'm using openvpn-event script.



So this script just jumpstarts VPN client on every nat start if it's down?

When nat-start fires, then if there is a VPN Client1 and/or VPN Client2 running (although the script should probably be modified to reflect the fact that firmware 378.56 now allows up to 5 VPN Clients) then this will force the VPN client(s) to invoke your openvpn-event script.

However, if there are no VPN Clients 'running' then it will not start any VPN Client(s) as it could be inappropriate to do so i.e. you may have deliberately manually stopped the VPN Client(s) etc.

 

[Mikeyy]

When nat-start fires, then if there is a VPN Client1 and/or VPN Client2 running (although the script should probably be modified to reflect the fact that firmware 378.56 now allows up to 5 VPN Clients) then this will force the VPN client(s) to invoke your openvpn-event script.

However, if there are no VPN Clients 'running' then it will not start any VPN Client(s) as it could be inappropriate to do so i.e. you may have deliberately manually stopped the VPN Client(s) etc.

Thank you, will keep that in mind if it starts happening again.
Since I flashed latest firmware and reseted all settings, it's without problems.

Any explanation why you can't enter only last 2 lines of script I posted above instead of whole script part?

 

[Martineau]

Thank you, will keep that in mind if it starts happening again.
Since I flashed latest firmware and reseted all settings, it's without problems.

Any explanation why you can't enter only last 2 lines of script I posted above instead of whole script part?

YES - Computers only do what you tell them to do, not want you want them to do.

So your assumption is that when you issue the two lines, that all of the preceding table definitions/configuration are still in place to process your selective routing tag MARK 1 request?
Since you appear to concur that re-running the script always restores your routing, then is it not logical to ensure that the script should be run in its entirety rather than taking a chance that only a little bit of the script is suddenly required to re-work the magic??

i.e. What do you think would happen if table 100 is suddenly empty or has been deleted?

 

[Mikeyy]

So your assumption is that when you issue the two lines, that all of the preceding table definitions/configuration are still in place to process your selective routing tag MARK 1 request?
Since you appear to concur that re-running the script always restores your routing, then is it not logical to ensure that the script should be run in its entirety rather than taking a chance that only a little bit of the script is suddenly required to re-work the magic??

i.e. What do you think would happen if table 100 is suddenly empty or has been deleted?

Maybe I didn't explain it in a good way.
I know port forwarding will not work to VPN clients without whole script (if I just use last 2 lines).

Since Merlin has this on his wiki - LINK - and that can be achieved trough GUI now (script is obsolete), my reasoning was that he ALREADY implemented that script and just made GUI for defining VPN clients in "Routing policy".

 

[Martineau]

Maybe I didn't explain it in a good way.
I know port forwarding will not work to VPN clients without whole script (if I just use last 2 lines).

Since Merlin has this on his wiki - LINK - and that can be achieved trough GUI now (script is obsolete), my reasoning was that he ALREADY implemented that script and just made GUI for defining VPN clients in "Routing policy".

Given that ARM routers are known to have the -t mangle PREROUTING chain randomly trashed, RMerlin does not advocate/recommend the use of FWMARK tagging, but since RPDB Policy routing does not support specific ports, then 'advanced' users must reluctantly take our chances with old-school FWMARK tagging.

see script /usr/sbin/vpnrouting.sh to see which custom RPDB tables are created by RMerlin.

So your two script lines should work if you also include the two additional rules:

ip   rule    add   fwmark   1   table   xxx
ip   route   flush   cache

where xxx is 111 or 112 (or 113,114 or 115 for firmware 378.56) for the VPN Client rather than assume table 100 already exists!

However I also have the following in /jffs/scripts/init-start

# Tables 111/112 reserved by RMerlin RPDB Selective Policy routing
# Tables 100/200 reserved by ASUS Dual WAN aka Primary and Secondary WAN
if [ ! -d /etc/iproute2/ ]; then
    # Tag the VPN RPDB tables by name!!!
    /usr/bin/logger -s -t "($(basename $0))" $$ "Creating RPDB name table /etc/iproute2/rt_tables"
    mkdir /etc/iproute2
    echo 111 hma >  /etc/iproute2/rt_tables
    echo 112 vpn2 >> /etc/iproute2/rt_tables
    echo 100 talktalk >>  /etc/iproute2/rt_tables
    echo 200 three >>  /etc/iproute2/rt_tables
    /usr/bin/logger -s -t "($(basename $0))" $$ "         " `cat /etc/iproute2/rt_tables`
    /usr/bin/logger -s -t "($(basename $0))" $$ "Created RPDB name table /etc/iproute2/rt_tables"
fi

so I can use rules such as

ip   rule    add   fwmark   1   table   hma
ip   rule    add   fwmark  33   table   talktalk
ip   route   flush   cache

which makes the ip rules more human-friendly as I can see which intended VPN Client selective routing I meant to use!

 

[Mikeyy]

Thank you for all answers.

Thread starter got what he wanted and I learned little more.

 

[mcb03]

Yep. The script worked great! Thanks for everyone's help.


Sent from my iPhone using Tapatalk

 

[Wasim Soultan]

Router: ASUS DSL-AC86U

First of all I'm not a tech savvy. I am using Airvpn Client on my router and I'm trying to setup iptables to port forward remote port 15576 to 192.168.1.100:4033 and i have tried every thing i can find on this website and others, i can see the results in system log but when i check the port 15576 at canyouseeme.org the result is "Connection refused". i have another asus router RT-AC86U with marlin firmware and i get the same results.

those are the rules i tried for both protocols :

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 4033 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p udp --dport 15576 -j DNAT --to-destination 192.168.1.100:4033

iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 4033 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 15576 -j DNAT --to-destination 192.168.1.100:4033

 

[Mikeyy]

If you want to port forward trough vpn, then use iptables from second post in this thread.

For this to work you also need to port forward on airvpn page.

If you want to port forward regular wan to client which is using vpn then use script I posted.

EDIT:

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 4033 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 4033 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 4033 -j DNAT --to-destination 192.168.1.100
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 4033 -j DNAT --to-destination 192.168.1.100

On AirVPN web page, add port forwarding from 15576 to local port 4033.

 

[Wasim Soultan]

If you want to port forward trough vpn, then use iptables from second post in this thread.

For this to work you also need to port forward on airvpn page.

If you want to port forward regular wan to client which is using vpn then use script I posted.

EDIT:

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 4033 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 4033 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 4033 -j DNAT --to-destination 192.168.1.100
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 4033 -j DNAT --to-destination 192.168.1.100

On AirVPN web page, add port forwarding from 15576 to local port 4033.

Thanks Mikeyy, it worked but i had to change the local port to match the remote port. is there any way to make it work without changing the local port.

 

[Mikeyy]

Remote port doesn't have to match local port for it to work, you only have to have local port in script above.

Did you also port forward same port in router GUI? That wouldn't be good.

Poslano sa mog SM-G925F koristeći Tapatalk

 

[Wasim Soultan]

Remote port doesn't have to match local port for it to work, you only have to have local port in script above.

Did you also port forward same port in router GUI? That wouldn't be good.

Poslano sa mog SM-G925F koristeći Tapatalk

I should have said that i wanted to port forward trough VPN so i used the the iptables in the second post in the thread as you mentioned before and don't know where the local port fit in these rules.