What's new

VPN Director - FQDN route

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

mkaand

Occasional Visitor
Hello,

I just newly explored VPN Director feature. First I couldn't start VPN Director because I should choose VPN Director on VPN Client settings page. Now I can redirect my internet traffics to VPN connection for specific IPs. But I cannot make this route with FQDN (domain name). I used to use following config file for OpenVPN client:

route-gateway 10.10.3.1
keepalive 10 60
ping-timer-rem
allow-pull-fqdn
route snbforums.com 255.255.255.255 vpn_gateway
route smallnetbuilder.com 255.255.255.255 vpn_gateway
route pastebin.com 255.255.255.255 vpn_gateway
route tunein.com 255.255.255.255 vpn_gateway

You can see allow-pull-fqdn let me indicate routes via domain name instead of IPs. Currently If I try to visit pastebin.com chrome shows not found. But If I refresh page I can access to pastebin.com. VPN Director is good for fixed ip<>domain routes. But if domain is behind Cloudflare or has more than one ip (load balancing on name server) VPN Director is not working properly. Maybe they can FQDN feature into VPN Director. Is should be great.
 
I'm a bit confused about your situation.

When I use the VPN Director and add routes based on domain names, it works just fine. In fact, I tried the following specifically...

Code:
route pastebin.com 255.255.255.255 vpn_gateway

... and I got the following added to the ovpnc1 routing table.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
104.23.99.190 via 10.114.0.13 dev tun11
104.23.98.190 via 10.114.0.13 dev tun11
...

Both those IPs are resolved from pastebin.com.

Regarding route-gateway, normally that would be push'd by the server, NOT set by the client. And certainly NOT when using a commerical OpenVPN provider, since you wouldn't know what the gateway is. So all I can assume is this is your own OpenVPN server.

Also, I don't see the need to use the allow-pull-fqdn directive since these routes are NOT being pulled from the server, but specified on the client.

On a minor note, since 255.255.255.255 vpn_gateway is the default, you can simplify the route to just ...

Code:
route pastebin.com

So if you have some other expectation about how route directives based on fqdn should work, you need to clarify what that is.
 
Last edited:
Hi,

Seems like my previous config doesn't work anymore If I choose VPN Director at config page. I used to choose NOT redirect all traffic to VPN Gateway. I want to pick only selected domains to redirect vpn gateway with above config file. So what is my expectation from VPN Director:

I should able to define example.com as Remote IP field. I should also able to use wildcard for that. Like *.example.com

VPN Director is good feature but needs some improvement. Now I add a rule 192.168.50.50 Local IP will use VPN gateway. I use NetSetMan (freeware Network Profile Manager). If I choose VPN profile. My laptop's IP automatically changed to 192.168.50.50 and I use VPN gateway. This is perfect solution.

For allow-pull-fqdn probably you're right.
 
Seems like my previous config doesn't work anymore If I choose VPN Director at config page. I used to choose NOT redirect all traffic to VPN Gateway. I want to pick only selected domains to redirect vpn gateway with above config file. So what is my expectation from VPN Director:

I should able to define example.com as Remote IP field. I should also able to use wildcard for that. Like *.example.com

Ok, but it's NOT as if the prior implementation (i.e., before the VPN Director) worked any differently. Routing policy has never supported domain names. You would have to use route directives if you wanted to use domain names.

The way you describe it (or at least the way I understood it), it sounds as if you think the use of VPN Director introduced a regression, as if it broke something from the prior implementation. It hasn't. Not as far as I can see. But if you're just suggesting the VPN Director should be enhanced to accept domain names, even less than fqdn, well I suppose that's a valid request.
 
My prior implementation was working with policy based redirection. Even after VPN Director it was working. But I should choose:

Redirect Internet traffic through tunnel : NO

I do not use only above config I also use some ipset scripts. My setup a little bit complicated. I use some custom files like dnsmasq.postconf:

#!/bin/sh
VAR1="ipset=/"

for DOMAIN in `cat /jffs/scripts/ipset.txt`
do
VAR1="$VAR1${DOMAIN}/"
done

echo "${VAR1}ipset_V4">> /etc/dnsmasq.conf

VAR2="ipset=/"

for DOMAIN in `cat /jffs/scripts/scaleway.txt`
do
VAR2="$VAR2${DOMAIN}/"
done

echo "${VAR2}scaleway_V5">> /etc/dnsmasq.conf


I pull domain names from txt files. I use two VPN servers. One for USA one for Amsterdam. selected domains goes thru USA or Amsterdam. I do not redirect my whole traffic to VPN Servers. Only selected domains. But as I said my setup is complicated. ip-route.sh file below:

#!/bin/sh
ipset create ipset_V4 hash:net family inet hashsize 1024 maxelem 65536

#create ipset.conf to look like
#ipset=/privateinternetaccess.com/whatismyip.org/tun12_V4,tun12_V6
touch "ipset_"$dev.conf
echo "ipset=/"> "ipset_"$dev.conf
for DOMAIN in `cat /jffs/scripts/ipset.txt`
do
echo -n $DOMAIN >> "ipset_"$dev.conf
echo -n "/" >> "ipset_"$dev.conf
done
echo -n ipset_V4 >> "ipset_"$dev.conf

#restart dnsmasq
service restart_dnsmasq

# Do nslookup for all lines in ipset_tun12.txt
for LINE in `cat /jffs/scripts/ipset.txt`
do
nslookup $LINE
done

touch /tmp/000ip-router

#USA VPN IPSET RULE
iptables -D PREROUTING -t mangle -m set --match-set ipset_V4 dst -j MARK --set-mark 10012
iptables -I PREROUTING -t mangle -m set --match-set ipset_V4 dst -j MARK --set-mark 10012
ip rule add prio 100 fwmark 10012 lookup 100
ip route add table 100 default via 192.168.50.2

So basically I create ip set rules for specific domains. I pull domain names from txt file. As I remember I use this for USA VPN. I use policy based redirect for Amsterdam (Scaleway) my own VPN server. Currently I do not have any issue with VPN Director. But I guess my policy based rules doesn't work anymore. Because I choose Director on setup page.
 
Updates: Some tests with VPN Director:

1. Test:
OpenVPN Client Settings:
route-no.jpg

And config:
route-gateway 10.10.3.1
keepalive 10 60
ping-timer-rem
allow-pull-fqdn
route snbforums.com 255.255.255.255 vpn_gateway
route smallnetbuilder.com 255.255.255.255 vpn_gateway

1. Test Result (tracert)

tracert-test1.jpg

snbforums.com policy based route working

2. Test VPN Director activated:

vpndirector.jpg

I didn't change OpenVPN config. Route policy rules still exist and result:

2. Test Result (tracert)

tracert-test2.jpg

I didn't add any IP related snbforums.com into VPN director. I just tracert same IP that I get Test 1. Result different. Policy based still working If you do not choose VPN Director.
 
Updates: Some tests with VPN Director:

1. Test:
OpenVPN Client Settings:
View attachment 35882

And config:
route-gateway 10.10.3.1
keepalive 10 60
ping-timer-rem
allow-pull-fqdn
route snbforums.com 255.255.255.255 vpn_gateway
route smallnetbuilder.com 255.255.255.255 vpn_gateway

1. Test Result (tracert)

View attachment 35883

snbforums.com policy based route working

2. Test VPN Director activated:

View attachment 35884

I didn't change OpenVPN config. Route policy rules still exist and result:

2. Test Result (tracert)

View attachment 35885

I didn't add any IP related snbforums.com into VPN director. I just tracert same IP that I get Test 1. Result different. Policy based still working If you do not choose VPN Director.

IIRC, prior to the introduction of the VPN Director, if you specified No for "Redirect internet traffic through tunnel", any route directives in the OpenVPN config and directed at the VPN, did indeed get routed over the VPN, for any and all clients. However, if you specified one of the "Routing Policy" options, the router would *ignore* all such route directives. I know this for a fact since I've had a disagreement w/ Merlin in the past about this particular behavior. His view was that the user should either use routing policy or route directives, not both. I disagreed. Your only option was to manually add those destination IPs as routing policy rules (no source IP), which of course was not very user-friendly since you couldn't specify domain names.

With the introduction of the VPN Director, if you specify No for "Redirect internet traffic through tunnel", things remain the same. Any routes directives in the OpenVPN config and directed at the VPN still get routed over the VPN, for any and all clients. But if you now specify VPN Director for "Redirect internet traffic through tunnel", those routes will be honored (!), *but* only for those clients being directed over the VPN in the VPN Director.

In short, Merlin has now made it possible to combine policy based routing rules *and* route directives in the config file that point to the VPN, at the same time. This was NOT the case before!

What I can't tell from your test #2 is whether that specific client doing the tracert is being forced over the VPN due to any rules in the VPN Director. That's a requirement for your route directives bound to the VPN to work. All I can assume is that particular client is NOT bound to the VPN.

Admittedly, all this stuff is rather confusing, and not necessarily intuitive. If you examine the underlying data structures with the various OpenVPN configuration options, it starts to make more sense. But if you're just changing options and assuming certain behaviors, you're probably going to remain confused. That's what I had to do to figure it all out for myself, using the following commands while the OpenVPN client was active.

Code:
ip route
ip route show table ovpnc1
ip rule

It's one of the unfortunate aspects of all these options. It get *VERY* confusing! And now you're adding your own dynamic routing w/ ipset on top of all this as well! It just becomes next to impossible for someone else in the forum to explain all the various specific behaviors you may be observing given so many variables, esp. when we don't have the FULL, TOTAL, IN DETAIL configuration, nuts to bolts. All we have are the bits and pieces you choose to provide, leaving us to make assumptions to fill in the gaps.
 

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