OpenVPN Client Security Enhancement

Discussion in 'Tomato Firmware' started by eibgrad, Apr 16, 2019.

  1. eibgrad

    eibgrad Network Guru Member

    I'd like to request the following security enhancement (fix frankly) in FreshTomato. By default, the OpenVPN client adds the following firewall rules.

    Code:
    iptables -I INPUT -i tun11 -j ACCEPT
    iptables -I FORWARD -i tun11 -j ACCEPT
    For unidirectional tunnels (typical seen w/ a commercial OpenVPN provider), this is unnecessary. By default, all local networks (br0, br1, etc.) are allowed to initiate outbound connections to the internet, whatever the network interface (vlan2 (wan), tun11, etc.). And all the replies are handled by the ESTABLISHED/RELATED rules on both chains. The only thing necessary is a rule to NAT the tunnel.

    In fact, for a unidirectional tunnel, the router should be BLOCKING attempts to gain access to the local network by remote clients on the OpenVPN server side of the tunnel!

    Code:
    iptables -I INPUT -i tun11 -m state --state NEW -j DROP
    But as things stand, the router configures all OpenVPN clients as if they were bidirectional (aka, site-to-site). And that creates a vulnerability. The same one I described in detail over at the dd-wrt forum regarding PureVPN.

    https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=307445

    So the only protection the user has against remote access via the OpenVPN tunnel is if the VPN provider has established a firewall on his side of the tunnel. And we have at least one example where this isn't the case. And even if there were no known examples, I wouldn't want to bet the farm on it. And you're still leaving your router open to rogue elements at the VPN provider (or VPS if you choose to roll your own server), or perhaps a misconfigured OpenVPN server that allows some other customer to gain access.

    Regardless, I find the current situation a bit too risky. I understand why it was done this way; it makes it easy to support, since both unidirectional and bidirectional tunnels work. But this isn't 10-15 years ago when you could let stuff like this slide. I'm so paranoid these days, I don't run any services on the WAN unless and until I'm ready to leave the house! And even then, I only open the SSH server on some obscure port. And if I need the OpenVPN server, I start it from the shell, and stop it when I'm finished.

    What I'd like to see is a switch on the GUI called Site-to-Site, with Yes/No options, and No being the default. When set to No, the following rules get added to the firewall.

    Code:
    iptables -I INPUT -i tun11 -m state --state NEW -j DROP
    iptables -I FORWARD -i tun11 -m state --state NEW -j DROP
    When set to Yes, change those rules to the following.

    Code:
    iptables -I INPUT -i tun11 -m state --state NEW -j ACCEPT
    iptables -I FORWARD -i tun11 -m state --state NEW -j ACCEPT
    Again, the ESTABLISHED/RELATED rules handle the replies.

    Or perhaps a drop-down box w/ options like unidirectional/bidirectional(site-to-site), w/ unidirectional the default. However you choose to offer the option in the GUI isn't as important as just making sure to NOT create bidirectional tunnels unless the user specifically asks for it. Perhaps even a warning about the implications of enabling bidirectional/site-to-site access.

    Frankly, the same complaint could be made for *any* VPN, even PPTP, or what I suspect will soon be coming, Wireguard. Most of the implementations I've seen default to bidirectional access. Not good.

    Thanks for your serious consideration.
     
    Last edited: Apr 17, 2019
    Bird333, Justio, rs232 and 1 other person like this.
  2. Bird333

    Bird333 Network Guru Member

    Where in the chains should we add these rules until they are fixed by default?
     
  3. eibgrad

    eibgrad Network Guru Member

    You'll need to create your own custom firewall rules to replace those automatically generated by the router.

    Under the Basic tab of the OpenVPN client, select "Custom" for the Firewall option.

    And in the firewall script, add the following firewall rules.

    Code:
    # allow only outbound connections to the VPN (no inbound)
    iptables -I INPUT -i tun11 -m state --state NEW -j DROP
    iptables -I FORWARD -i tun11 -m state --state NEW -j DROP
    iptables -t nat -I POSTROUTING -o tun11 -j MASQUERADE
    Of course, you'd have to repeat this for every active OpenVPN client (tun12, tun13). Or else you can use the iptables wildcard (+) to fixup all the OpenVPN clients in one fell swoop.

    Code:
    # allow only outbound connections to the VPN (no inbound)
    iptables -I INPUT -i tun1+ -m state --state NEW -j DROP
    iptables -I FORWARD -i tun1+ -m state --state NEW -j DROP
    iptables -t nat -I POSTROUTING -o tun1+ -j MASQUERADE
    In the process of verifying all the above works, I believe I've found yet another bug.

    I noticed, at least w/ FreshTomato (2018.5), that the router adds a NAT rule for all possible tunnels (tun11, tun12, and tun13) to the firewall automatically, even if there are no active OpenVPN clients. It seems someone added them to the default firewall rules. And I think this is something relatively new. Doesn't seem long ago those NAT rules were only added as-needed. So technically, you could eliminate the POSTROUTING rule above in the case of FreshTomato (it ends up being redundant). But I left it in the recommended rules anyway, just in case someone is using another tomato variant, or older Shibby build.

    But this apparent change to how NAT rules are handled is NOT a good idea. NAT'ing the tunnel isn't necessary, or even desirable, in the case of a bidirectional tunnel. In fact, it's an obstacle, because now devices on the remote network can't see the source IP of clients on the local network behind the OpenVPN client, but only the IP assigned to the OpenVPN client. That means those remote devices can't filter, reroute, log, etc., clients based on their actual source IP.

    Doesn't matter whether you choose Custom for the Firewall option, or Automatic and choose to NOT NAT the tunnel, it *always* NATs the tunnel regardless. And that's a bug.

    I'll probably post this bug separately, just to make sure it gets noticed.

    P.S. With the above rules in place, it might be interesting to periodically check on the number of hits (if any) those rules receive (particularly the INPUT chain), suggesting something/someone *is* trying to initiate a connection into your network.
     
    Last edited: Apr 20, 2019 at 4:34 AM
  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