Access device over WAN that is bound to VPN

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Paul Cardamone

New Around Here
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:


Code:
#!/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

Very Senior Member
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

New Around Here
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.
 

eibgrad

Very Senior Member
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.

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

Martineau

Part of the Furniture
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:


Code:
#!/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

New Around Here
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.

Code:
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....
 

Similar threads

Sign Up For SNBForums Daily Digest

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