OpenVPN Client Security Enhancement

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

eibgrad

Very Senior Member
I've made this same argument over at the dd-wrt and tomato forums. Merlin, dd-wrt, and tomato all have this same OpenVPN client vulnerability. There's no need to rehash the details here, since you can read all about it directly from the tomato forums.

https://www.linksysinfo.org/index.php?threads/openvpn-client-security-enhancement.74549/

Only difference w/ Merlin is that he creates a user-defined chain called OVPN to which he inserts the same bidirectional firewall rules, then jumps to that chain from the INPUT and FORWARD chains of the filter table. But the net effects and behavior are identical to dd-wrt and tomato.

Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 850K   58M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   76  5391 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
35765 1995K PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0  
    6  3240 PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0  
    6  3240 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
 4976  308K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
30789 1687K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    3  1053 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
28576 1486K ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          ctstate DNAT tcp dpt:8443
   11  4992 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0  
 2182  182K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0  

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.1.100        tcp dpt:1002
    0     0 ACCEPT     udp  --  tun11  *       0.0.0.0/0            192.168.1.100        udp dpt:1001
    0     0 ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.1.100        tcp dpt:1000
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 other2wan  all  --  !br0   vlan2   0.0.0.0/0            0.0.0.0/0  
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0  
    0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0  
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0  

Chain OVPN (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun11  *       0.0.0.0/0            0.0.0.0/0  
    0     0 ACCEPT     all  --  tun11  *       0.0.0.0/0            0.0.0.0/0

And it's not just routers that have this vulnerability. I see all kinds of devices, including NAS!
 
Last edited:

RMerlin

Asuswrt-Merlin dev
Personally, I think the real problem is the fact these commercial VPN services exist at all. A VPN is supposed to allow you to connect two trusted network (i.e. your home with your office) over an untrusted network (i.e. the Internet). In this case, people are connecting to another untrusted network (the service provider)... So, they are misusing the VPN technology for something it was never intended to.

But also keep in mind that the remote provider should be taking care of this for you if they properly configured their own end. That's why some of them optionally let you forward ports to your endpoint, meaning by default they do block all inbound traffic. So I suspect that the issue is not as widespread as you might fear.

I guess handling of inbound traffic could be made configurable, but this might lead to a *lot* of support requests, as already existing legitimate tunnels would break (if defaulting to blocking), or it would bring no security improvement for the majority who never adjust these settings if kept disabled by default...
 

eibgrad

Very Senior Member
That's always the debate. Do we keep going the way we're currently going (no one likes change) because we've gotten no complaints so far, or do we see the problem and address it.

Frankly, I don't know if most ppl would even know they're vulnerable, or have been attacked. I have a script that runs through about 2200 PureVPN servers and searches for this vulnerability. On any given day, I can find a least a few OpenVPN clients (3, 4, maybe 5, occasionally a few more) exposed to the internet. As a percentage, it's not much. But if it happens to be *your* system, those statistics aren't comforting. Esp. when the problem was known and not addressed.

As I said, this affects many other devices besides routers. And in some cases I can clearly tell the user doesn't realize the OpenVPN client is exposed to the internet, since the device exposes passwords, licenses, and other secret information. And it doesn't mean I had to login (which I wouldn't do anyway). Sometimes the system is just completely open. If I had evil intent, I could wreak havoc on a least a few ppl every day.

I just think that placing convenience above security (regardless who is to blame for the lack of it) is 2005 type of thinking. Back then, security was just an afterthought. An add-on. An annoyance. Ease of use and keeping ppl in their comfort zone was more important. But that's the kind of thinking that gets ppl in trouble these days. Users need to be protected from themselves sometimes. Even if it adds some inconvenience. I bet most users just *assume* the router is protecting them over the OpenVPN, just like it does w/ the WAN. But as we now know, that's NOT the case here. At the very least, every user should be put on notice of this potential hazard, however unlikely it may that they become a victim.

When it comes to this change, I suspect 98% of users will never know the difference. Most ppl are just in need of a unidirectional tunnel from a commercial OpenVPN provider. Thoughts of configuring a site-to-site tunnel, port forwarding, etc., are NOT in the cards. Anyone affected by these changes is likely to be an advanced user, and will have bigger issues to deal w/ than this.

Case and point ...

https://www.snbforums.com/threads/iptables-command-needed-with-openvpn-client.56312/

That becomes the opportunity to explain the need to enable bidirectional access.

JMTC
 

RMerlin

Asuswrt-Merlin dev
The problem is breaking already existing configurations is generally bad, even if site-to-site users are the minority. Such changes must be properly evaluated before implementation. I would certainly need to think about it more in depth before making any decision. For instance, you can't just blindly block ALL inbound traffic - some users actually need inbound access, for instance for a torrent, or an ftp session in Port mode.

Sent from my P027 using Tapatalk
 

RMerlin

Asuswrt-Merlin dev
I just tested with two different VPN services, and neither of them allowed me to reach back to my router. Which is actually expected, since they both involve NAT done on their server. When trying to connect on port 80 of both of these providers's public IP, I get an answer coming from a web server running on their server, nothing makes it to my router.

A provider would have to actually forward a port to you for public traffic to make it through the tunnel.
 

eibgrad

Very Senior Member
I'm not surprised. I would certainly hope and expect *most* VPN providers to protect me. It's never been my contention this is being commonly exploited. Just that it's a known vulnerability.

I don't think anyone knows the full extent of this threat, myself included. And that's part of the problem. You're trusting your security to a third-party. You don't do that w/ the WAN, why would you do that w/ the VPN?

And it's not just the internet side of the VPN that concerns me. The VPN provider's internal network is a threat as well. What if some rogue employee decides to do some snooping? What if a virus or malware manages to get on his network and starts probing for vulnerable OpenVPN clients? What if the firewall isn't a secure as you assume it to be? What about all the freebie VPNs ppl use just to save a few bucks? For all I know, some of these are just scammers looking for a vulnerable OpenVPN client. Yes, I know, users shouldn't be so careless. But they are, and sometimes just out of ignorance.

I'm not saying these are likely, but in 2019, it makes no sense to me to not plug this known vulnerability. Esp. since no one knows the extent of it. It flies under the radar screen, mostly out of ignorance. I'm not a hacker by any stretch, but even I found it trivial to scan the PureVPN servers to find vulnerable systems. The only reason those users haven't been hacked is because I'm one of the good guys. :)

Just doesn't make sense to me to have a third-party acting as my only line of defense. And one I have no way to examine or audit. I appreciate the fact the the public gate in my local community is locked each night (at least I assume it is). But I still lock my front door, just in case.

As always, it's your call. My attitude back in 2005'ish was to let these things slide. But not anymore. Even if the firmware refuses to protect me, I make it a point to add my own firewall rules when dealing w/ any VPN, just as a precautionary measure. I just wish the firmware would do this for me.
 

ColinTaylor

Part of the Furniture
II'm not a hacker by any stretch, but even I found it trivial to scan the PureVPN servers to find vulnerable systems.
As far as I can tell from PureVPN's support site the only way this would work is if you a) pay an additional monthly fee for their "port forwarding" add-on, and b) go into the VPN account settings and deliberately enable the forwarding of specific ports.

It appears that this is not something that is "on by default" or can be done accidentally. One could argue that it's "more secure" than the router's built-in port forwarding menu because not only do you have to make a conscious decision to do it but you also have to pay for the privilege.

No doubt there will be some people that have misconfigured their PureVPN settings leaving them vulnerable. But I suspect these are the same people than even without a VPN would be forwarding every port under the sun, turning off firewalls, etc.
 

eibgrad

Very Senior Member
That's not the way it used to be @ PureVPN. Originally they left their end of the tunnel wide open and sold security as an add-on, in the form of a NAT firewall product. That only changed subsequent to me making a stink about it @ dd-wrt. They eventually reversed course and decided to firewall their end of the tunnel and sell port forwarding instead. The old product page still exists, w/ an updated message indicating the product has been changed to a port forwarding service.

https://www.purevpn.com/blog/ensure-optimal-security-with-purevpns-add-on-nat-firewall/

That's what can happen when you place your security in the hands of a third party.

As I keep saying, you have no clue what the situation is between you and that remote firewall (assuming there is a remote firewall). I doubt most users even bother to check. Most are completely obsessed w/ performance, but give little if any thought to the security aspects of creating a tunnel to a third-party. I believe they *assume* they're protected by their own router, just like the WAN, when that's NOT the case.

To me, the current situation is akin to declaring the network you connect to at the local wifi cafe as private rather than public on your Windows laptop. At one time Windows *did* leave you open and vulnerable, but that changed back around Vista (iirc) w/ this notion of public and private networks. Makes no difference if you subsequently connect to a VPN. You still want/need local protection because you can't and shouldn't trust the local network. But that's exactly what we're doing w/ the OpenVPN client by default. We're declaring the local network over the VPN to be private, when it should be declared public.

It's one thing for the user to be careless and stupid. We obviously can't do much about that. But it doesn't make sense for the router to be just as careless. The router should protect me, even if I'm careless. The default on the router should be a firewall (i.e., a unidirectional tunnel), just like the WAN. If I subsequently decide to create a bidirectional tunnel (the equivalent of enabling port forwarding on the router), at least I'm on notice about the potential risk and the router is off the hook in terms of its own responsibility to protect me.

I know there's a lot of resistance here. It's very hard to overcome the preference of convenience over security mentality that has a grip on technology, even after all these years. That mindset seems to paralyze ppl when it comes to taking action. No one wants to disable the APs by default either. It will eventually require someone to take the first step, then others will follow. But everyone is waiting for the other to go first.
 
Last edited:

eibgrad

Very Senior Member
At this point, I'm willing to accept a compromise. At least give the user the option to select a unidirectional vs. bidirectional tunnel, and make the default bidirectional. Hence nothing has changed for current users (no harm, no foul). Eventually ppl will start asking what that option is for and learn about the issue (perhaps include a help bubble). Then perhaps warn ppl that the default will be changed to unidirectional in an upcoming firmware release (e.g., 384.15). IOW, give ppl time to adjust.

At least this gives the user the option to secure the tunnel. As of right now, unless you have the skills to be aware of the problem and how to fix it yourself, like I do, you're stuck.
 

RMerlin

Asuswrt-Merlin dev
why would you do that w/ the VPN?

Because a VPN *is* a security feature, provided by a security company. It's like saying you don't trust antivirus software because they require to run with administrator privileges.

At this point, I'm willing to accept a compromise.

I'm considering it, however I want to do a more thorough evaluation of the situation before going blindly in and adding a setting that might potentially serve no goal, and will only create confusion among users (leading to an increase of support questions). I tried hard a few releases ago to reduce the amount of OpenVPN settings because they were horribly confusing to all users (including myself, heck, some of these I didn't even know what they were for!). The first analysis simply revealed that it is not a major issue right now, therefore a more in-depth analysis can be done before taking any decision.
 

ColinTaylor

Part of the Furniture
Thinking aloud here - I can't see the necessity to create an iptables rule that drops traffic in the FORWARD chain as any unsolicited incoming traffic would never reach there. So it would only seem necessary to protect services running on the router itself (INPUT) that were listening on "all" interfaces.
 

eibgrad

Very Senior Member
Thinking aloud here - I can't see the necessity to create an iptables rule that drops traffic in the FORWARD chain as any unsolicited incoming traffic would never reach there. So it would only seem necessary to protect services running on the router itself (INPUT) that were listening on "all" interfaces.

You can't just protect the router based on the INPUT chain. You must include the FORWARD chain as well.

You're assuming that remote access over the VPN will only be a threat from the public side of the VPN provider. But what about that rogue element *inside* the VPN provider's network? What about malware on his system finding its way into your network? What about a misconfiguration of the OpenVPN server that allows some other customer to gain access to your network? If that happens, *all* your devices are accessible (putting aside personal firewalls)! Just like any OpenVPN site-to-site configuration, no port forwarding is required on the router. Port forwarding is only relevant to the VPN's *public* facing network interface, since you can't route from the public space to a private space without it. But that's not an issue *inside* the local network of the VPN provider. Anyone, anything, has direct access to any resources, and by its *private* IP address. And none of us has a clue what might lie inside that network. You're taking it on faith that there's nothing to worry about. What you don't see can't hurt you. That's one of my major concerns.

I'll bet you the VPN provider doesn't trust YOU and firewalls the connection into his own local network. I don't see why we don't do the same.

I just don't want ppl to become fixated on the sole issue of the VPN's public facing network interface. It's a potential threat, but it's not the only threat.
 
Last edited:

eibgrad

Very Senior Member
P.S. Realize I'm just responding to the arguments against it. I fully appreciate this raises other non-technical issues, like making the GUI more complex. I get it. It's a valid argument. I hate the fact it's so darn complicated as much as anyone else. Heck, I'm still trying to get my head around all the idiosyncrasies of Policy Routing! Talk about complexity. I'm pretty well versed on the topic, including haven written dozens of policy based routing scripts, on multiple platforms. And even I'm having a struggle w/ it on Merlin. Don't get me wrong, I think it's quite sophisticated, esp. compared to anything else available, but it's quite a challenge for any Merlin newb. Yet, it's still part of the package.
 

eibgrad

Very Senior Member
Here's another idea.

I was thinking maybe we could avoid GUI changes and additional complexity for the user by detecting their intentions implicitly. For example, if NAT is enabled, it would be quite rare for someone to do that w/ a site-to-site config. site-to-site almost invariably involves static routing, esp. on the OpenVPN client side. OTOH, everyone connecting to a commercial VPN provider (which is the biggest vulnerability) is going to require NAT. Of course, we'd still have an edge case, where some user configures site-to-site w/ NAT, but perhaps you could make the case this is a misconfiguration.

Just thinking out loud here. I could be overlooking something.
 
Last edited:

ColinTaylor

Part of the Furniture
OTOH, everyone connecting to a commercial VPN provider (which is the biggest vulnerability) is going to require NAT.
Yes, this was my thinking in my previous post. The connection is NATed at the tunnel end point therefore unsolicited incoming traffic (regardless of its source) won't get to the FORWARD chain.

Of course, we'd still have an edge case, where some user configures site-to-site w/ NAT, but perhaps you could make the case this is a misconfiguration.
I think that's a safe assumption. To make this kind of connection work would require a deliberate effort. It's not something that you could do accidentally by just toggling a switch in the GUI.
 

eibgrad

Very Senior Member
I think that's a safe assumption. To make this kind of connection work would require a deliberate effort. It's not something that you could do accidentally by just toggling a switch in the GUI.

What I'm thinking too is that for that oddball case where someone wants to NAT the OpenVPN client on a site-to-site tunnel, we simply tell them to NOT NAT in the GUI (thus he gets the site-to-site firewall rules), but instead use openvpn-event to add and remove his own NAT rule.
 

RMerlin

Asuswrt-Merlin dev
I added an option to control the default policy for traffic coming through the tunnel. The Inbound Firewall setting can be set to either Allow or Block. For now I've set the default policy to Block, but I might change idea before the final release.
 

eibgrad

Very Senior Member
I added an option to control the default policy for traffic coming through the tunnel. The Inbound Firewall setting can be set to either Allow or Block. For now I've set the default policy to Block, but I might change idea before the final release.

Absolutely awesome! I believe this is a major improvement to security. Even if it's unblocked by default, at least having the option is a step in the right direction. Thank you!
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top