Access device over WAN that is bound to VPN

[Paul Cardamone]

Hey everyone,

I am trying to get this working on firmware 384.19. I did have it working but it's stopped. I only want this for ssh to a specific IP.

Any help would be great!

my openvpn-event script looks like:

#!/bin/sh

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 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p udp --sport 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p udp --dport 22 -j MARK --set-mark 1

 

[eibgrad]

The title of this thread is confusing given you've indicated a desire to port forward over the VPN, but your script is for the purposes of accessing a device over the WAN, presumably because the target of the port forward is bound to the VPN.

So either the title is wrong, or your script is wrong.

If you're trying to port forward from the OpenVPN server of your OpenVPN provider, and over your local OpenVPN client, and the target of the port forwarding is bound to the OpenVPN client, there's no need for PBR (policy based routing), which is what you have defined in that script. You just need port forwarding rules, similar to those used over the WAN, except of course they need to reference the VPN.

 

[Paul Cardamone]

Apologies.....you are correct. The title is wrong. I wasn't quite sure what to call it. I am indeed trying to access a device over the WAN which is bound to the VPN.

 

[Paul Cardamone]

I have changed the title.

 

[eibgrad]

I did have it working but it's stopped.

Had it working where? On this same 384.19 firmware, or some prior Merlin firmware? Using the same event (openvpn-event)? Because if it was working at some point, then presumably there's nothing wrong w/ the script. And that would suggest a conflict was introduced when you changed firmware versions. But I first need to know if in fact it was a change in the firmware that led to it not working.

Like any such changes, you probably need to dump the relevant data structures to a) confirm they got applied and b) haven't come in conflict w/ other changes by the firmware.

ip route
ip route show table 100
ip rule show
iptables -t mangle -vnL PREROUTING

 

[Martineau]

Hey everyone,

I am trying to get this working on firmware 384.19. I did have it working but it's stopped. I only want this for ssh to a specific IP.

Any help would be great!

my openvpn-event script looks like:

#!/bin/sh

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 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p udp --sport 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -p udp --dport 22 -j MARK --set-mark 1

As indicated in the Wiki here, the legacy script method you have used is flawed in many ways.

I suggest you simply follow the Wiki example 2 for remote RDP access (via the WAN) substituting the SSH port as desired.

 

[Paul Cardamone]

Had it working where? On this same 384.19 firmware, or some prior Merlin firmware? Using the same event (openvpn-event)? Because if it was working at some point, then presumably there's nothing wrong w/ the script. And that would suggest a conflict was introduced when you changed firmware versions. But I first need to know if in fact it was a change in the firmware that led to it not working.

Like any such changes, you probably need to dump the relevant data structures to a) confirm they got applied and b) haven't come in conflict w/ other changes by the firmware.

ip route
ip route show table 100
ip rule show
iptables -t mangle -vnL PREROUTING

Thanks for your reply. Nothing had changed. There is an update though....it has started working again this morning....not sure why / how....

 

[Paul Cardamone]

As indicated in the Wiki here, the legacy script method you have used is flawed in many ways.

I suggest you simply follow the Wiki example 2 for remote RDP access (via the WAN) substituting the SSH port as desired.

Great thanks. I will implement example 2 tonight. Appreciate the assistance.