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.