Resolve Hostnames over OpenVPN

[Wingsfan87]

Clearly client-to-server was the required solution for me, with the client device either being a router/phone etc.

Apologies.....I did state in the original post that there were limitations!

You mentioned it might be possible with event script like the one you did for clientconnect.

Would you help me come up for one that would update each clients hosts file dynamically when they connect to the server?

 

[Wingsfan87]

You mentioned it might be possible with event script like the one you did for clientconnect.

Would you help me come up for one that would update each clients hosts file dynamically when they connect to the server?

@Martineau

I simplified the server settings (see below AsusWRT Router settings). So now I am using the gui box for Allowed clients to push and route. And then only using your script for the iroute based on commonname of the login (which was brilliant by the way!). So now I tested as was able to be partially successful. **Note this is a site to site router to router setup NOT a phone or pc client.

By IP everything works fine
client1<->client2
client1<->server
client2<->server
server<->client1
server<->client2

By Hostname only client to server works by FQDN so I can resolve any serverhostname from either client using FQDN.
client1>server
client2>server

Problem is I cant resolve hostnames client1<->client2 and the server can't resolve hostnames for neither client.

So based on your comments earlier I need a script to for each client to resolve each others hostnames and for the server to resolve the client hostnames? I did a lot of researching the forums based on @RMerlin 's post about site to site tunnel guides but no one it seems that I have found have successfully set it up for hostname resolution for server<->clients and clients<->clients. Only from client to server works.

So could you help with the script for the clients or any other ideas on what to configure on each router?

AsusWRT router settings:

Tun
Push Lan to Clients: Yes
Respond to DNS: Yes
Advertise DNS to clients: Yes

Allowed Clients (Gui entry)
commonname1 192.168.4.x 255.255.255.0 Push Yes
commonname2 192.168.3.x 255.255.255.0 Push Yes

Custom Configuration
script-security 2
client-connect /jffs/scripts/VPNClientConnect.sh

 

[Martineau]

@Martineau
I simplified the server settings (see below AsusWRT Router settings). So now I am using the gui box for Allowed clients to push and route. And then only using your script for the iroute based on commonname of the login (which was brilliant by the way!). So now I tested as was able to be partially successful. **Note this is a site to site router to router setup NOT a phone or pc client.
By IP everything works fine
client1<->client2
client1<->server
client2<->server
server<->client1
server<->client2
By Hostname only client to server works by FQDN so I can resolve any serverhostname from either client using FQDN.
client1>server
client2>server
Problem is I cant resolve hostnames client1<->client2 and the server can't resolve hostnames for neither client.
So based on your comments earlier I need a script to for each client to resolve each others hostnames and for the server to resolve the client hostnames? I did a lot of researching the forums based on @RMerlin 's post about site to site tunnel guides but no one it seems that I have found have successfully set it up for hostname resolution for server<->clients and clients<->clients. Only from client to server works.
So could you help with the script for the clients or any other ideas on what to configure on each router?

Q1. Why me? ...although I'm a sucker for flattery!
Q2. What scripting have you tried so far?

NOTE: All 'etc /hosts' references deliberately have an embedded space to prevent triggering the forum blocker

On the client-side router the necessary steps to achieve your goal is pretty simple:

1. Retrieve/Download HOSTS file.
2. Merge HOSTS file with '/etc /hosts' on the client-side router.

and can be hack scripted in two lines!

OpenVPN server router '/jffs/configs/hosts.add' must already be a 'master' hosts file containing a consolidated/amalgamated HOSTS file for ALL of your Client-Client Sites and must have been merged with '/etc /hosts'

Obviously this needs to be working to enable the server>client1 and server>client2 resolution.

I don't think we should/can have direct access to '/jffs/configs/hosts.add' but it is trivial to clone it to a USB flash drive attached to the server router.

Now enable FTP (LAN only) on the server router and create the client1/client2 IDs to have (Read only) access to the USB folder.

e.g. my flash drive is labeled 'RT-AC68U' and I cloned '/configs/hosts.add'

So this USB file can now be safely retrieved on demand by the client1 and client2 routers via their VPN tunnel from the OpenVPN server-side router.

Unsurprisingly, curl can't use the VPN tunnel from within the 'vpnclientX-route-up' script, as this script is actually still logically configuring the tunnel!

So to specifically accommodate curl, we need to use an exception three-tier asyncronous calling structure for our two line script!

      openvpn-event
                  |
                  -> vpnclientX-route-up
                                       |
                                       -> UpdateOpenVPNHosts.sh

/jffs/scripts/vpnclientX-route-up

#!/bin/sh

sh /jffs/scripts/UpdateOpenVPNHosts.sh "$dev"  &

P.S. Don't download direct to '/jffs/configs/hosts.add' if it contains critical local site entries!.

/jffs/scripts/UpdateOpenVPNHosts.sh

#!/bin/sh

curl --interface $1 -o /jffs/configs/hosts.add   ftp://xxx.xxx.xxx.xxx/RT-AC68U/configs/hosts.add -u client1:password

service restart_dnsmasq

I recommend curl as the tool of choice as it is very flexible and there are a variety of supported protocols besides FTP such as HTTP,TELNET etc. so hopefully one will suit your needs if you don't want to host the file on the server-side router!, although wget may be an alternative tool for the job.

Alternatively you may not want to (inconveniently) bounce dnsmasq on the client router (nor risk overuse of /jffs/) so you could download the HOSTS file to a USB flash drive (instead of always availaible /tmp especially if it is huge!) and simply dynamically append the retrieved file direct to ' /etc /hosts'.

#!/bin/sh

curl --interface $1 -o /mnt/sda1/Merge_hosts.add   ftp://xxx.xxx.xxx.xxx/RT-AC68U/configs/hosts.add -u client1:password

cp /mnt/sda1/Merge_hosts.add >> etc/hosts

Also this method is preferred if you don't want the muti-site HOST entries in '/etc /hosts' to be persistent across reboots until the first VPN connection.

The /jffs/scripts/UpdateOpenVPNHosts.sh script can be as complex as you like, but preferably needs to include validation such as eliminating duplicates (just in case) and possibly auto-checking the timestamp of the retrieved file to eliminate unnecessary merging (see 'curl -z' option) etc.

NOTE: Hopefully we are talking a relatively small number of HOST entries rather than say thousands!
This may influence your chosen method to collate the necessary DNS entries on the OpenVPN server.

I'm sure there are better more sophisticated methods.......but being old-skool, I prefer to limit my posts based on personal experience.

Spoiler: Syslog openvpn-event/vpnclientX-route-up/MergeOpenVPNHosts.sh

[

 RT-AC68U daemon.notice openvpn[7596]: TUN/TAP device tun14 opened
 RT-AC68U daemon.notice openvpn[7596]: TUN/TAP TX queue length set to 100
 RT-AC68U daemon.notice openvpn[7596]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
 RT-AC68U daemon.notice openvpn[7596]: /usr/sbin/ip link set dev tun14 up mtu 1500
 RT-AC68U daemon.notice openvpn[7596]: /usr/sbin/ip addr add dev tun14 10.166.0.2/24 broadcast 10.166.0.255
 RT-AC68U daemon.notice openvpn[7596]: /usr/sbin/ip route add 10.99.8.0/24 via 10.166.0.1
 RT-AC68U user.warn (vpnrouting.sh): 7601 v380.66 Patched by Martineau vpnrouting.sh
 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 4
 RT-AC68U user.warn openvpn-routing: Creating VPN routing table (mode 2)
 RT-AC68U user.warn (vpnrouting.sh): 7601 Martineau Deleting routes 0.0.0.0/1 and 128.0.0.0/1 from table main (254)
 RT-AC68U user.warn openvpn-routing: Removing route for 10.99.8.0/24 to tun14 from main routing table
 RT-AC68U user.warn openvpn-routing: Removing rule 10700 from routing policy
 RT-AC68U user.warn openvpn-routing: Removing rule 10701 from routing policy
 RT-AC68U user.warn openvpn-routing: Adding route for 0.0.0.0 to 10.99.8.0/24 through VPN client 4
 RT-AC68U user.warn (vpnrouting.sh): 7601 Martineau Adding VPN4 RPDB fwmark rule 0x4000 prio 10700
 RT-AC68U user.warn openvpn-routing: Tunnel re-established, restoring WAN access to clients
 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration for client 4
 RT-AC68U user.warn custom script: Running /jffs/scripts/openvpn-event (args: tun14 1500 1558 10.166.0.2 )
 RT-AC68U user.warn openvpn-event[7745]: User openvpn-event running
 RT-AC68U user.warn openvpn-event[7745]:      Script executing.. for event: vpnclient4-route-up
 RT-AC68U user.warn (vpnclient4-route-up): 7755 User Processing 'route-up' (tun14) via 10.166.0.2 args=[tun14 1500 1558 10.166.0.2]
 RT-AC68U user.warn (vpnclient4-route-up): 7755 User Processing Complete.
 RT-AC68U daemon.warn openvpn[7596]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
 RT-AC68U daemon.notice openvpn[7596]: Initialization Sequence Completed
 RT-AC68U user.warn (MergeOpenVPNHosts.sh): 7788 Downloading '/jffs/configs/hosts.add' from 10.99.8.1 via tun14 .....
 RT-AC68U user.warn (MergeOpenVPNHosts.sh): 7788 Merging '/jffs/configs/hosts.add' with '/etc /hosts'...restarting dnsmasq.....
 RT-AC68U kern.notice rc_service: service 7800:notify_rc restart_dnsmasq