Proper setup of OpenVPN client on TomatoUSB

Discussion in 'Tomato Firmware' started by emmteedee, Mar 2, 2018.

  1. emmteedee

    emmteedee New Member Member

    Hi. I'm a privacy enthusiast, and my goal is to setup OpenVPN client on a TomatoUSB router... "properly". I know how to do most things listed here, but I'm wondering if there are better/easier ways to do all these. So what I'm looking for are suggestions and cosmic discussions.

    Here's what I want:
    - After the router boots, perhaps after an optware partition is mounted, an OpenVPN client is started on the router.
    - Kids, partners, guests running around with hacked devices shall not know the WAN IP.
    - No LAN traffic (including DNS) shall ever go out on WAN, except what is minimally needed or explicilty allowed.
    - Kill switch.
    - The VPN client shall try to reconnect automatically following a network hiccup with minimal need for intervention.
    - Incoming SSH on WAN.

    Putting 2 and 2 together, WAN traffic should be limited to:
    - encrypted VPN traffic, obviously
    - traffic to preselected IPs, e.g VoIP, work VPN
    - traffic started by incoming SSH on WAN
    - DNS traffic exclusively related to VPN operation

    I don't think this set of goals is too uncommon, but I'm a bit surprised at how much networking is needed to implement all this. There are several things in the TomatoUSB interface I don't understand, perhaps there are easier ways to achieve some of these things. Here is what I have in mind:

    - In Administration, firewall script: `iptables -A wanout -j REJECT`. This takes care of all LAN traffic never leaving on WAN, with the notable exception of DNS, which leaves the router as local, so it must be dealt with separately.
    - In /opt/etc/config wanup, also called from /opt/mount.autorun: Create novpn routing table by removing all references to tun devices. Also `ip rule add fwmark 1 table novpn`.
    - In /opt/etc/config fire: extensive iptables stuff, mostly mangle prerouting but others as well, setting marks on traffic that should go on WAN.
    - Dnsmasq. This is getting messy. Existing 'strict' is useless and misleading IMHO because of leaks. Existing 'exclusive' is better, with the notable exception that to survive a network hiccup, I have to resolve myvpnprovidercom some other way, otherwise the client hangs/exits and manual restart is needed. Right now I'm leaking. What I'm thinking of is: custom config `server=/myvpnprovidercom/10.8.8.8`, plus disable WAN DNS to prevent leaks when VPN is down, plus packet marks and DNAT to 8.8.8.8, so that only those queries go out to Google on WAN.

    Questions:
    1) Any suggestions how to do some things better/easier? Are there any features in the TomatoUSB GUI that could help? I'm putting some of the scripts in /opt because nvram is pretty low.
    2) Is there any reference to properly dealing with this dnsmasq issue? I hacked my solution together by reading manuals and such, but it seems other people with more network knoledge should have solved it before.
    3) Don't you find 'strict' totally misleading, given that dnsmasq provides only a query ordering guarantee?
    4) In TomatoUSB, how do the VPN DNS servers make their way from /etc/openvpn/dns/client1.resolv into /etc/resolv.dnsmasq? I see the openvpn script wirting the former, and dnsmasq reading the latter.
    5) Why doesn't the kernel/iptables return packets belonging to a certain connection (incoming SSH on WAN) back to where they came from by default, so that all this marks nonsense is needed for those?
    6) Why does this have to be so compilcated? People, enthusiasts, work on these setups. I know it's not immediate but still, I would expect that there is progress. The dnsmasq and openvpn interaction seems so very obscure.
     
  2. Sean B.

    Sean B. LI Guru Member

    VPN's are not my area of expertise, @eibgrad may be able to give you more in-depth assistance. But I'll chime in on the specific part of DNS still getting out through the WAN in spite of the wanout reject.

    If you take a look at the filter rules that are set in iptables, only the FORWARD chain shows a line that jumps to wanout. This means only traffic that is routed through the router will hit the wanout chain, not traffic that originated from the router itself. And as dnsmasq is a process running on the router, it's DNS queries are from the router and bypass the wanout rules. Adding a line to the filter tables OUTPUT chain will catch those queries. Something like:

    Code:
    iptables -t filter -I OUTPUT -p udp --dport 53 -o vlan2 -j DROP 
    Will block anything UDP trying to leave out the vlan2 interface with a destination port of 53. You can add exceptions to this if you want. For instance:

    Code:
    iptables -t filter -I OUTPUT -p udp -d ! 8.8.8.8 --dport 53 -o vlan2 -j DROP 
    Block all UDP DNS queries going out the WAN unless it's to googles server. May also add identical lines using the tcp flag a long side, to prevent any tcp DNS queries as well, though not very common yet I don't think.
     
  3. Pess0g

    Pess0g Serious Server Member

    I don't know how your server side works. Most public providers like PIA,HMA,etc,would push options to your client. You'd better put all "hacked" devices into another bridge( ex, br1) and vlan to keep them from your clean devices(br0). "Redirect-gateway" maybe was suggested to set and turn ipv6 off on the bridge the hacked devices connects.

    Don't set too much on WebUI. And I don't understood clearly what you really want to realize with dnsmasq.
    For example,only dns query out wan for vpn server ip,the others into vpn.
    in WebUI,
    Code:
    conf-file=/jffs/dnsmasq.conf
    in dnsmasq.conf
    Code:
    no-resolv
    #Is it really useful?
    server=/openvpn.server/8.8.8.8
    #ask google for vpn server side
    server=10.8.8.8
    
    vpn up script
    Code:
    #!/bin/sh
    iptables -t nat -I PREROUTING -p udp --dport 53 -d 10.8.8.8 -j DNAT --to-destination 8.8.8.8:53
    iptables -t nat -I PREROUTING -p tcp --dport 53 -d 10.8.8.8 -j DNAT --to-destination 8.8.8.8:53
    #forward all dns queries into vpn tunnel. Google gets those from your vpn server and would give suitable IPs for vpn traffic.
    iptables -i FORWARD -o `nvram get wan_iface` -j DROP
    #block traffic forwarded out wan.You can move this into firewall scripts if hacked devices are always blocked from wan.
    ip route flush table novpn
    #ssh from wan goes back through wan
    ip rule add fwmark 22 table novpn
    ip route add default dev `nvram get wan_iface` table novpn
    #don't forget to add other routings to local subnet
     
    firewall script
    Code:
    iptables -t mangle -I OUTPUT -p tcp --sport `nvram get sshd_port` -j MARK --set-mark 22
    #ssh from wan goes back through wan
    
     
  4. emmteedee

    emmteedee New Member Member

    Thanks for your reply. I understand the distiction between FORWARD and OUTPUT, that's why I said DNS has to be treated differently.

    My concern is not to leak DNS queries ever, regardless of the status of the VPN connection (not started/started/dead/restarting). I'm looking for the peace of mind (a "set it and forget it" type of a configuration) that when I connect to the wifi, I don't need to think of the VPN status before I type in an address.

    The setup you are suggesting would leak DNS queries if the VPN is down.
     
  5. Sean B.

    Sean B. LI Guru Member

    No, the iptables rules I suggested would prevent DNS queries from going out on the WAN interface at any point, regardless of VPN status, unless you included an exception such as the Google example I gave. Providing your network is configured with the router as the DNS server included in the dhcp exchange and the "intercept port 53" option has been selected.
     
  6. emmteedee

    emmteedee New Member Member

    I am indeed using PIA, but my concern is not about their settings, it's about the router setup.

    Perhaps I didn't properly isolate my concern with DNS leaking in the OP. Let's forget the more esoteric things (incoming ssh over WAN while VPN is up, selective routing over WAN). Let's concentrate on:
    • run VPN client on the router
    • send all traffic over VPN
    • kill switch
    • no DNS leaks
    The only esoteric thing here is the first point. My guess is most users would run VPN on a laptop, where you have an icon in the system tray showing you the status, perhaps a third party program/script implementing a kill switch, and you don't much care to reconnect without user interaction.

    To elaborate on "no DNS leaks": I want to implement a configuration is which no DNS queries ever leak out on WAN except what is minimally needed, regardless of the status of the VPN client. In my experience, the status of openvpn client is one of:
    • "down": client not started or dead; tun doesn't exist; VPN routes don't exist.
    • "up": client running; tun exists; VPN routes exist.
    • "stale": client running; tun exists; VPN routes exist; but traffic cannot get through.
    The "stale" status is another thing which doesn't necessarily show up when running VPN on a laptop. You only see it when the router tries to keep it up 24/7. For me with PIA, this happens occasionally (1-2 times a week) and I believe it has to do with server changes or some other network hiccups. When it happens, the client continuously tries to resolve PIA server names, but because the tunnel is stale, those do not resolve when using only VPN DNS servers (e.g. in "exclusive" mode). Perhaps this could be fixed by tweaking the restart conditions to bring down tun and recreate it.

    To come back, I want a configuration where, the moment I connect to my wifi, I can type whatever I want in an address box, and I don't have to worry about the DNS query leaking depending on the status of the VPN client on the router. I also want the router to come back from stale status by itself, without me restarting it manually.

    So, dnsmasq on the router must have these properties:
    • resolve VPN provider names (in my case PIA) through WAN, regardless of VPN status
    • (same for ntp for router time, and maybe ddns, but let's ignore those for now)
    • not resolve anything else though WAN, regardless of VPN status
    My frustration is that this not-so-esoteric desire (IMO) seems very difficult to achieve.
     
  7. emmteedee

    emmteedee New Member Member

    Oh I see, so 8.8.8.8 would not be the default DNS server, right? I'd only add `server=/PIA/8.8.8.8` in dnsmasq conf, then use "exclusive" in openvpn conf. To deal with VPN being down, I'd also have to disable the ISP DNS by hand (e.g. set it to manual and enter 10.10.10.10).The problem now is that to recover from "stale" (see my earlier post) I'd have to manually route 8.8.8.8 from the router over WAN (to resolve during stale status), and 8.8.8.8 from LAN over TUN (to prevent unknowing users who manually use 8.8.8.8 from leaking).
     
  8. Pess0g

    Pess0g Serious Server Member

    I wonder what is "Stale".

    "persist-tun" keeps device tun from disappearing and the default gateway is still the server side. As long as you don't change anything in the table main,all the traffic still go into the tunnel.

    Openvpn has two options named "ping-restart" and "up-restart". These two should solve the problem that PIA server changes and gives no response.

    Another way is to set "server=/pia.server/8.8.4.4" and "iptables -t mangle -I OUTPUT -p tcp --dport 53 -d 8.8.4.4 -j MARK --set-mark 22" to redirect dns queries for vpn server IPs to WAN port even after VPN is on.
     
    Last edited: Mar 15, 2018
  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