use VPN for specific traffic only?

[Chenks]

i've got an RT-AX88U running merlin.
Synology NAS running various docker containers.

this is what i am trying to achieve but unsure if it's possible.
i have a surfshark VPN account (possibly changing that over to PIA) and can set it up on the router no problems, however i only want to route very specific traffic thru it, and not all my WAN traffic.

the specific stuff i want to route thru the VPN would be a few select docker containers, and essentially nothing else.
is this possible at all? all the docker containers have the same LAN IP address but run on different ports.

to add a potential spanner in the works (or maybe not), one of the docker containers is pihole which is the DNS server for the LAN (set via DHCP)

192.168.50.1 (router)
192.168.50.2 (NAS running the dockers)
192.168.50.x (all other clients, some with reserved DHCP IPs, others just pick up any from DHCP pool)

 

[eibgrad]

Depends on whether we're talking about OEM vs. Merlin here.

For OEM, if the ASUS router supports VPN Fusion, you should be able to use selective routing. For Merlin, you use the VPN Director.

 

[Chenks]

Depends on whether we're talking about OEM vs. Merlin here.

For OEM, if the ASUS router supports VPN Fusion, you should be able to use selective routing. For Merlin, you use the VPN Director.

yes I’m running Merlin (mentioned that in the first line of my post)

vpn director only works using lan ip addresses though? And as I mentioned the docker containers don’t have their own ip addresses

 

[eibgrad]

vpn director only works using lan ip addresses though? And as I mentioned the docker containers don’t have their own ip addresses

I had assumed you wanted ALL of the containers to use the VPN, so if they share the same IP, that would work.

If you're telling me you want to distinguish them based on additional criteria, such as their source ports, the VPN Director doesn't support it. You'd have to implement your own PBR (policy based routing), which the Merlin wiki does provide some suggestions.

Policy based routing (manual method)

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

NOTE: The wiki reports the above information in that link as deprecated.

Or else you'll have to consider some method so the containers *do* have their own uniquely assigned IPs.

 

[Chenks]

If you're telling me you want to distinguish them based on additional criteria

well yes, that’s what I said in the opening post…..

so as it stands it seems like a no go

 

[eibgrad]

well yes, that’s what I said in the opening post…..

so as it stands it seems like a no go

It's source IP and/or destination IP w/ the VPN Director. No other options.

 

[Chenks]

Can it be a destination URL as opposed to destination IP ?

 

[eibgrad]

Can it be a destination URL as opposed to destination IP ?

Not sure if you literally mean URL here, or perhaps (more likely) domain name. Regardless, it's explicit source/destination IP/network only (e.g., 199.199.199.199 or 199.199.199.0/24).

The VPN Director is intentionally built to be simplistic. Therefore, it will NOT serve the needs of all users, just the vast majority. Once you step outside these boundaries, you're on your own.

 

[Chenks]

looks like the easiest way will be to try and get my docker containers to have their own LAN IP address (most likely using macvlan or similar).
then i can vpn director to route their traffic thru the VPN.

 

[Chenks]

i've changed the plan and now just going to route all traffic from the NAS thru the VPN.
i've set up the VPN client and it connects OK (and set it to only VPN director policy rules only)
i've set up VPN director and added the local IP of the NAS and enabled it.

checking what the WAN ip address is inside one of the docker containers, it reports the WAN IP of the VPN, so that appears to be working fine.

however, i also have a website (and some sub-domains) hosted on the NAS, and when the VPN is enabled for the NAS i can no longer access the sites.
have i missed a crucial setting in the VPN client settings? or is this going to be a problem that can't be resolved?

 

[eibgrad]

If by NOT being able to access the website or other sub-domains, you mean over the WAN, this is expected behavior.

The router implements RPF (reverse-path filtering) which requires all packets of a given connection to use the *same* network interface whether entering or leaving the network. When you use the VPN Director to bind a source IP to the VPN, that binding is in effect whether that source IP is initiating a connection outbound to the internet, OR replying to remote access over the WAN. It's the latter that creates the problem; RPF just won't allow it. In short, you have to pick one or the other, WAN or VPN, for your internet access (at least for anything that relies on the router's default gateway) for any given source IP.

All that said, there are several ways to get around the issue.

1) Remotely access the source IP over the VPN rather than the WAN, provided your VPN provider supports port forwarding over his end of the tunnel (some do, most do NOT).

2) Remotely access the source IP using the OpenVPN server. This works because the remote access, both inbound and outbound, is over the same network interface of the tunnel (tun21 or tun22). So it never conflicts w/ the requirements of RPF.

3) If you know w/ certainty what public IPs will be used to access the source IP over the WAN (e.g., workplace, friend or relative w/ static or otherwise predicatable IP, favorite wifi cafe, etc.), statically bind that public IP to the WAN using the VPN Director (i.e., create a rule that includes that public IP in the remote-IP field). This works because your internet routing is no longer dependent on the default gateway of the router for that public IP. Of course, for situations of true roaming, where the public IP can't be anticipated w/ any degree of reliability, this is NOT going to work well. Still, it may be viable in certain situations.

4) Implement your own PBR (policy based routing) that supports other criteria than just the source and/or destination IP, such as ports. In your case, you'd use that PBR to exclude that source IP *and* the source ports of 80 and 443 (if those are indeed the ports these services are listening on) from the VPN.

In short, the VPN Director works just fine as long as you only have a need to route a given source IP over the WAN or the VPN, but NOT both. Once you have a requirement for both, now you have to deal w/ the solutions above to get around the limitation.

 

[Chenks]

i can't access the websites either on LAN or WAN when the VPN and director policy is active (so www.blah.com fails to load anywhwere).
options 1, 2 and 3 won't work as this is a website (along with sub-domains) that could be accessed by anyone anywhere. VPN is PIA.

and yes, it would be port 80 and 443 (i have 2 other ports open to allow plex and emby to connect remotely (32440 and 8096))

 

[eibgrad]

It's NOT obvious to me why the VPN Director would have an impact on accessing those websites on the LAN *unless* perhaps you're doing so using NAT loopback (i.e., referencing your public IP from inside the LAN). It's only in this latter situation you would be forcing a routing decision w/ the router and become subject to the VPN Director's rules. But LAN to LAN (bridged) traffic completely bypasses the VPN Director.

Regardless, to solve the problem of remote access over the WAN, seems to me you're going to have to implement your own PBR. The AsusWRT-Merlin wiki provides an example, although it also describes it as deprecated. But one way or another, that would appear the only option.

FWIW, I have written such scripts myself for DD-WRT and FreshTomato and posted them on PasteBin.

ddwrt-ovpn-split-advanced.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

tomato-ovpn-split-advanced.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Of course, they can't be directly applied to AsusWRT-Merlin given the complexity and the unique requirements of each firmware.

I've had them for YEARS and they are downloaded quite regularly by users w/ similar issues. I just never bothered to create the same for AsusWRT-Merlin since so many users are satisfied w/ the current implementation available in the GUI. But more than that, this sort of thing typically requires marking packets, and there's always the risk of creating conflicts w/ other parts of the router that are also marking packets. That's why each scripts details certain limitations, often solely to avoid such conflicts. These scripts also include other features that are NOT strictly PBR. It should be possible to create something much smaller and focused to your own needs, similar to what's in the AsusWRT-Merlin wiki.

There is one other possibility here perhaps worth considering. I just don't know how feasible it is from the perspective of the NAS.

If you can multihome both the router and the website to a *secondary* IP network (that's certainly possible w/ the router), then you could differentiate the website from the rest of the NAS and bind that secondary IP network to the WAN. IOW, force the split tunneling on the NAS itself at the source IP level so you remain compatible w/ the VPN Director. But if everything from the NAS remains bound to a single source IP, I don't see any other option than creating your own PBR.

Of course, I suppose another option is to NOT host your own webserver for public consumption! That comes w/ it own risks. In fact, many ISP won't allow it unless you have a business account w/ them. Personally, I would just prefer to use something like DigitalOcean and avoid self-hosting. But perhaps your website is tightly bound to the NAS as a data source/store.

 

[Chenks]

this looks like it well above my skills level in terms of scripting.

 

[eibgrad]

this looks like it well above my skills level in terms of scripting.

I understand. GUIs are great in their ability to hide complexity and make things *appear* simple. But when you've reached the limits of the GUI, that's when you're faced w/ tough decisions. And where your skill level will determine what's feasible. That's why I try to offer as many options as possible to avoid needing such skills. But sometimes it's just unavoidable.

 

[Chenks]

i read the WIKI you referred to (the deprected on), but from what it appears it doesn't do anything that the VPN director currnently does, it doesn't mention anything about allowing certain ports to bypass the VPN etc.

Policy based routing (manual method)

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

of course, i could easily put most of the services on to a rapsberry pi and route that via the VPN, but trying to get one is virtually impossible (at non scalpers price).

 

[eibgrad]

Admittedly, I hadn't looked at that script in ages. Perhaps I was thinking of another script when it came to ports.

Regardless, while as written it doesn't do anything more than the VPN Director, it's a simple matter to include the source port in similar rules.

iptables -t mangle -A PREROUTING -p tcp -i br0 -s 192.168.1.100 --sport 80 -j MARK --set-mark 0
iptables -t mangle -A PREROUTING -p tcp -i br0 -s 192.168.1.100 --sport 443 -j MARK --set-mark 0

Everything is marked initially w/ 1, causing it to be routed over the VPN (this assumes the router has changed the default gateway to the VPN, which is what happens w/ virtually any commercial OpenVPN provider, as long as you also specify All for the routing policy on the OpenVPN client GUI). Then it checks for exceptions based on various criteria, which can include source IP, ports, protocol (UDP vs. TCP), etc. Basically, any criteria that iptables will allow in the mangle table. Those get marked w/ 0 and routed via the WAN.

But notice is also warns about conflicts w/ marking packets, as I described earlier. This is where you need to be careful, and why I tend to avoid this type of script unless I have no other choice. Good script writing requires having the experience to know when you *might* create conflicts w/ the rest of the system, which doesn't have a CLUE what you may be attempting to do behind its back.

 

[Chenks]

whilst i'm playing about with this, as a workaround to not being able to route using domain, i did an nslookup and got the 2 IP addresses currently associated with the domain (they might change, they might not), and added 2 rules in the VPN director to route all traffic from any device that goes to that destination IP.

is this set up correctly?

 

[eibgrad]

I thought your domain and sub-domains were hosted on the router's LAN (i.e., the NAS) and needed remote access via the WAN, or are we talking about something completely different here?

If it's the latter, then yes, you have to manually resolve domain names in order to use them w/ the VPN Director.

 

[Chenks]

Not talking about my own domain, just a service I connect to that I wanted to route thru the vpn, but I connect to it using a domain name rather than IP

Did I set up the director correctly so that any device on my lan that tried to connect to the service using got domain name would get directed thru the vpn?