Do not hide LAN client IP when connected to OpenVPN?

Discussion in 'Tomato Firmware' started by Nazgulled, Mar 7, 2019.

  1. Nazgulled

    Nazgulled Serious Server Member

    Ok, the topic question is a bit stupid (couldn't find a better one) and my post itself is probably stupider. I have a feeling I already know the answer to my question but I have to ask it and be sure...

    Anyway, I have an OpenVPN client configured on my router to connect to an OpenVPN server I've setup myself on a Google Could Platform VM I own. I have Pi-Hole configured on that VM and my router and the whole network can access Pi-Hole's IP (and DNS Server) because the router is connected to the VPN. This way I have a private DNS Server on Google Cloud Platform that only I can connect to. So far so good.

    The problem, you might have guessed by now, is that Pi-Hole can only identify a single client accessing it's DNS Server, my router. Is there any way to configure my OpenVPN client/server to be transparent about my home LAN's IPs so that Pi-Hole can identify individual clients like my PC, my phone, my NAS, my TV, etc... or is this not possible at all given that I'm using a VPN to access Pi-Hole's DNS server?
     
  2. Sean B.

    Sean B. Network Guru Member

    Under VPN Tunneling->OpenVPN Client basic tab, un-check the option for "Create NAT on tunnel". Note that internet access via the VPN will not function when this option is disabled, however from your description it does not sound as if you use the VPN connection as your route for internet bound ( destinations that are not within the networks directly connected by the VPN ) traffic.
     
    Last edited: Mar 8, 2019
    Nazgulled likes this.
  3. Nazgulled

    Nazgulled Serious Server Member

    Nope, the only purpose for this VPN is to access Pi-Hole on Google Cloud Platform without having to expose the DNS Server to the outside (which is never a good a idea).

    I'm surprised that this is actually possible, but that's the reason I posted this despite thinking it was stupid. Since it's not a topic I know that much about, there was a high probability of being wrong :D

    Will test this tonight or tomorrow. Thank you again.

    Sent from my HTC 10 using Tapatalk
     
  4. Nazgulled

    Nazgulled Serious Server Member

    Tried this but stopped being able to access my Google Cloud Platform VM. Pinging the internal VM IP address returns in packet loss and accessing http://<INTERNAL_VM_IP>/admin gives nothing. With the "Create NAT on tunnel" checked, I can ping the VM and access Pi-Hole's admin page.

    Maybe I'm missing some server configuration to allow the clients to see/access the VM internal IP or something?
     
  5. Sean B.

    Sean B. Network Guru Member

    Sorry, forgot to mention you need to set static routes. What IP does your tun interface receive on the Tomato router side? And what is the IP block used on the server side? If concerned about privacy, you can PM me the info.
     
    Nazgulled likes this.
  6. Nazgulled

    Nazgulled Serious Server Member

    All the IPs are internal, I guess it's OK to post them here?
     
  7. Sean B.

    Sean B. Network Guru Member

    Using an example IP for the Pi-Hole of 10.50.5.4, In the OpenVPN server configuration put:

    Code:
    push "route 10.50.5.0 255.255.255.0"
    While I don't know how google's cloud based openvpn service operates, I assume the OpenVPN server is also the gateway for the Pi-hole. If so, that should be all that's needed. If it doesn't work, we can set the router manually on the Tomato side.
     
  8. Nazgulled

    Nazgulled Serious Server Member

    No, I'm not using the external IP, only the internal one, that's why I need the VPN, otherwise I'd just connect directly. If I understand what you're asking correctly, my OpenVPN server is configured with 10.9.0.0/24, the tun11 interface on my Tomato router is 10.9.0.1 and Pi-Hole's VM internal IP is 10.132.0.8.

    Not sure if it's relevant but this is my OpenVPN server.conf:

    Code:
    dev tun
    proto udp
    port 9999
    ca /etc/openvpn/easy-rsa/pki/ca.crt
    cert /etc/openvpn/easy-rsa/pki/issued/server_TgeGO2sfMX3c131k.crt
    key /etc/openvpn/easy-rsa/pki/private/server_TgeGO2sfMX3c131k.key
    dh none
    topology subnet
    server 10.9.0.0 255.255.255.0
    push "route 10.132.0.8 255.255.255.255"
    push "dhcp-option DNS 10.132.0.8"
    keepalive 1800 3600
    remote-cert-tls client
    tls-version-min 1.2
    tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
    cipher AES-128-GCM
    auth SHA256
    user nobody
    group nogroup
    persist-key
    persist-tun
    crl-verify /etc/openvpn/crl.pem
    status /var/log/openvpn-status.log 20
    status-version 3
    syslog
    verb 3
    fast-io
    compress lz4-v2
    push "compress lz4-v2"
     
  9. Sean B.

    Sean B. Network Guru Member

    Why not assign the Pi-Hole IP address into the same subnet as the dhcp block configured on the server? This would make routing a non-issue.
     
  10. Nazgulled

    Nazgulled Serious Server Member

    What do you mean with "server IP"? Which server?
     
  11. Sean B.

    Sean B. Network Guru Member

    Ok we're leapfrogging each other with posts.
     
  12. Sean B.

    Sean B. Network Guru Member

    Add these lines to the OpenVPN server config file:

    Code:
    iroute 192.168.1.0/24 255.255.255.0
    route 192.168.1.0/24 255.255.255.0
    This assumes that:

    A: The Tomato router LAN is 192.168.1.0/24 - Change as required.

    B: The OpenVPN server is running on the gateway used by the Pi-Hole.

    C: The only client that connects to the OpenVPN server will be the Tomato router.

    If B or C are incorrect, let me know and I'll provide additional configuration.

    That should make it functional. However, VPN push routes are not always reliable. So if that alone does not get it working:

    On the Tomato router under VPN Tunneling->OpenVPN Client->Routing policy tab check the box for "Redirect through VPN". A new config line will appear, check the box for "Enable", from the drop down box select "To destination IP", then for value put 10.132.0.0/24 .
     
    Last edited: Mar 10, 2019
    Nazgulled likes this.
  13. Sean B.

    Sean B. Network Guru Member

    Note that I changed the configuration provided in the above post from its previous state, as I made some additional assumptions about your use case.
     
  14. Nazgulled

    Nazgulled Serious Server Member

    Looks pretty straightforward, I'll test this soon. Thank you very much!

    A) I actually have 2 LANs, one on 192.168.0.0/24 and other on 172.16.0.0/24 (guest WiFi network). I guess I should add both lines for that network too?
    B) That's correct.
    C) Yes, it's the only one. That's what made you move the "iroute" line to the OpenVPN server configuration instead of the "ccd" file?
     
  15. Sean B.

    Sean B. Network Guru Member

    Correct

    Exactly. No need to bother creating client specific configurations if the Tomato router will be the only client. I believe OpenVPN will accept the line in its main configuration file, but if it spits an error then revert to using the ccd configuration.
     
  16. Sean B.

    Sean B. Network Guru Member

    As we discussed in another thread an issue with the router intercepting your DNS traffc destined for this VPN:

    If you would like to ensure DNS requests from LAN clients do not circumvent your Pi-hole you can implement the same interception as "Intercept DNS" does in the GUI but rather have it redirect to the Pi-hole directly rather than to the router. You'd simply add:

    Code:
    iptables -t nat -I PREROUTING 1 -p udp --dport 53 -d ! 10.132.0.8 -j DNAT --to-destination 10.132.0.8
    iptables -t nat -I PREROUTING 2 -p tcp --dport 53 -d ! 10.132.0.8 -j DNAT --to-destination 10.132.0.8
    To Administration->Scripts firewall tab.
     
    Nazgulled likes this.
  17. Nazgulled

    Nazgulled Serious Server Member

    With this configuration there's no need for custom dnsmasq configuration (to push Pi-Hole's DNS server) for each one of my LANs, correct?
     
  18. Sean B.

    Sean B. Network Guru Member

    It would be better to leave the dhcp-option in place, that way clients are configured correctly and the iptables rules are just used to catch programs trying to use their own coded servers. But yes, it would effectively do the same thing. Were you able to test the changes to the OpenVPN config? Also, have you considered any fail over in case the VPN connection is lost? Currently, if that happens you will lose DNS.
     
  19. Nazgulled

    Nazgulled Serious Server Member

    Ok, that makes sense :)

    Yes, I've tested a few minutes ago but had to leave in a hurry and couldn't come here and post my results. I'm on my phone and can't provide much details but it didn't work, Pi-Hole's IP was inaccessible. I'll provide more details later. Sorry.

    And no, I have not yet considered a fall back. What's the best way to configure that?

    Sent from my HTC 10 using Tapatalk
     
  20. Sean B.

    Sean B. Network Guru Member

    I was going to line out some tests to run, but realized we're missing an IP somewhere. The tun interface on VPN server side, what IP does it have? By default the server will take the first IP in the segment you configure for the VPN, but you stated above that the client ( tomato ) side has been set as 10.9.0.1 . IE:

    Tomato LAN 192.168.0.0/24 <-> VPN Client interface 10.9.0.1 <-----> VPN server interface ??? <-> Pi-hole 10.132.0.8

    Maybe I've overlooked where you stated it?

    After reading things again, are you using 10.9.0.0 as the server IP? If so, that isn't a valid address in a /24 , .0 and .255 are reserved. Change the server to be 10.9.0.1 and the Tomato side to be 10.9.0.2.

    After we get the routing functional without NAT, I can code a script that you can put into the scheduler to keep an eye on the VPN status and redirect DNS queries if the Pi-hole becomes unreachable.
     
    Last edited: Mar 11, 2019
  21. Nazgulled

    Nazgulled Serious Server Member

    My mistake, you're a correct, of course.

    The TUN interface on the VPN server side has 10.9.0.1 for IP and the TUN interface on the VPN client side 10.9.0.2.

    I just did some debugging and the "iroute" lines are actually prevent the OpenVPN service from starting. Doing "sudo ifconfig" gives me no TUN interface, but as soon as I comment out the "iroute" lines and restart the service, I get a TUN interface. Maybe I really need to place a file under "ccd"? I'm just not sure about the name because I used PiVPN to configure the server and generate the certificates and the CN for all of themby default is "ChangeMe". Though I can't find PiVPN's documentation on how to change these on per-certificate basis with PiVPN, it shouldn't matter because this is the only certificate/client I'll be using.
     
  22. Sean B.

    Sean B. Network Guru Member

    Just for giggles, leave out the iroute line but leave in the route line and test. If that fails ( it likey will ), then follow the procedure I outlined for the ccd method. As far as the common name, as long as the file name matches it doesn't matter what it actually is nor does it matter if it's unique as you won't have any other clients connecting. So naming the file "ChangeMe" will work just fine providing that matches the cert.
     
    Last edited: Mar 11, 2019
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice