Joined: 14 Oct 2016 Posts: 109 Location: United States
Posted: Sat Jul 04, 2020 21:33 Post subject: VPN LAN client to client communication with CVE-2019-14899?
Hello,
So I looked into CVE-2019-14899 and just realized how it impacts the ability to have a VPN client interact with a client on the network.
They added a button to disable that mitigation patch but I also saw some Iptable commands that could be used. I was going through the OpenVPN server guide (by egc) on page 7 and saw that the one of the following Iptable commands could be used.
One is
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j
MASQUERADE
while the other is
iptables -t raw -I PREROUTING -i br0 -d $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j
ACCEPT
I am currently trying to understand if the first iptable command is no different than simply disabling the mitigation checkbox method in the Web GUI?
And my other question is what would be the difference between the two Iptable commands?
For the second one, I'm not sure if I applied it correctly but I tried applying it via web administration console after VPN is already started and it appears nothing is happening. It seems like this 2nd Iptable command might be better (in terms of security?) but I'm not too sure.
Joined: 14 Oct 2016 Posts: 109 Location: United States
Posted: Sat Mar 13, 2021 6:38 Post subject:
Sorry for bumping this (figured I bump this one instead of making a new topic so there aren't duplicate forum threads) but I still am unsure here and I am curious if anyone knows. _________________ DD-WRT Router Arsenal:
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sat Mar 13, 2021 17:28 Post subject:
In addition to Per Yngve's answer, the following is from the OpenVPN server setup guide:
Quote:
Builds from 41786 onwards stop access to the local LAN clients because of a patch which should solve a recent vulnerability, CVE-2019-14899 (see: https://svn.dd-wrt.com/ticket/6928)
This can be mitigated with the following firewall rule (Administration/Commands, Save as Firewall):
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE
This rule SNAT's all traffic out of br0 so you cannot distinguish which is the source, this also has security and logging concerns.
From build 41812 and higher you can disable the patch so you do not have to use the above rule, in the OpenVPN GUI: disable CVE-2019-14899 Mitigation.
Whether you should disable the patch or use the above rule is open to debate and in my opinion you have to factor in your threat level versus how much trouble you will get from SNATting all traffic.
If you are a high level government target I would enable the patch.
There is another solution instead of the SNAT rule and that is adding the following to the firewall but you have to do it after the VPN is up so you need a script checking for that .
The problem is that the firewall rules from the VPN are separate from the rest of the firewall rules and this rule has to be executed later than the VPN, and if the VPN restarts the rule has to be applied.
Furthermore this rule can expose your LAN side to the CVE attack, if you have your IOT things separated and tight control over your LAN you should be good, if your LAN is hacked you have got bigger problems:
iptables -t raw -I PREROUTING -i br0 -d $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j ACCEPT
To clarify the first rule will leave the CVE mitigation intact but you cannot discern traffic coming from your VPN from other traffic, so you cannot log or otherwise set access restrictions.
Not being able to log is for me also a security risk.
I have VPN users who I do not want to have access to my NAS, when using this rule it is impossible to do that as all traffic comes from the router itself.
The second rule disables the CVE mitigation patch on the LAN side so the WAN is still protected but not the LAN, but if your LAN side is already compromised I think you have bigger problems.
So I have it just disabled in the GUI, but I live in a free country and am not a high level governement target.
Besides the attacker must be directly connected to your WAN (so it is not possible to attack from the "internet") and only the traffic flow can be seen not the actual traffic that is encrypted.
