Posted: Sat Aug 29, 2020 0:15 Post subject: Firewall needed if VPN on Netgear R6400 configured as WAP?
I am in the process of setting (enabling) the DD-WRT VPN server on a Netgear R6400 (flashed with firmware r41986). I want the R6400 functioning as a wireless AP (WAP) behind an Arris' BGM210 AT&T gateway. I have done the WAP configuration on the R6400 and it seems to be working fine. While configuring the Netgear R6400, I disabled the SPI firewall according to the instructions here - https://wiki.dd-wrt.com/wiki/index.php/Wireless_Access_Point. Now a question I have is do I need to enable the SPI firewall for VPN? Thanks.
I have a couple DD-WRT routers setup as WAPs which both also have openVPN servers
Ain't really no need to worry about SPI firewall
If your ovpn server is all good and you have the correct port opened on main gateway router to it you should be good.
'bout all you would need is --- on the DD-WRT WAP ovpn server unit -- on webif page ../Diagnostics.asp
mrjcd is correct. When using a "traditional" WAP configuration (and I'll get to why I qualified that in just a moment), the firewall is irrelevant since routing is NOT taking place. All the traffic is bridged. And I agree about using the nat rule he suggests as well.
Alternatively, instead of the nat rule, you could add a static route for the tunnel's IP network to the primary router that points to the WAP's LAN ip as the gateway for that network. But many times OEM firmware doesn't support static routes.
A static route has the advantage of NOT masking the OpenVPN client's IP on the tunnel from target devices on the LAN. That may or may not be an issue. Just depends on the situation. But it's at least good to know all the options. I'd say most ppl should just use the nat rule as suggested by mrjcd unless they have a specific need to filter access based on the OpenVPN client's IP on the tunnel.
Thanks to eibgrad and mrjcd. Your replies sent me into intensive internet search trying to understand iptables/nat rules and the functions provided by the (SPI) fireware. Here is what I think.
All the devices, wired or wireless, connected to the DD-WRT'ed R6400 WAP are in the same local subnet (through bridging as eibgrad pointed out) as those connected to the primary gateway Arris BGM210 are protected by BGM210's firewall. So illegal traffic (not responses to requests initiated from within the local subnet) is dropped and the WAP's SPI firewall isn't needed. The one exception is the traffic destined for OpenVPN. It goes through the BGM210's firewall hole, punched by port forwarding, unchecked. However OpenVPN has its own firewall and with the nat rule that mrjcd mentioned the hole is filled. So the WAP's firewall seems to be redundant from this respect too.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Sat Aug 29, 2020 8:34 Post subject:
I must admit to just leave it enabled (as I keep the gateway mode enabled) when setting up a WAP.
As you disable the WAN the firewall rules are not implemented even if you keep SPI enabled.
As I sometimes switch my setups it is easier and does no harm to keep it enabled
The VPN's have their own rules so that will work anyway.
For the VPN client you can tick "Inbound firewall on Tun"
The NAT rule is the easiest to get a WAP working for unbridged interfaces (VAP, TUN, Wireguard etc) for reasons explained by @eibgrad.
But I personally am a fan of the static route method as it gives me the ability to track my OVPN clients connecting to the server.
For setting up a OVPN server on a WAP see the paragraph about that in the OVPN server setup guide, link in my signature at the bottom of this post
One addition to the static route method, if you want your OVPN clients connected to the OVPN server to have internet access you also have to make a NAT rule on the primary router to NAT the traffic of the OVPN subnet out onto the internet, DDWRT NAT's only its own subnet out by default (most stock firmware NAT's all traffic). _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
How could I have missed the setup guide you published, egc? I have been visiting the forum on and off since 2009 and only joined the forum early this year because I wanted to download the guide to setup a VPN server. . At that time I followed the basic instructions to configure the R6400 and didn't notice that the guide covered WAP until last night when I looked into the advanced section.
So from what I have read so far, the SPI firewall is really irrelevant in the case of WAP. Now that I already had it disabled, I will keep it that way.
So from what I have read so far, the SPI firewall is really irrelevant in the case of WAP. Now that I already had it disabled, I will keep it that way.
The firewall is irrelevant on a WAP *assuming* the WAP is only engaged in bridged operations, which is the norm. As I said, in the case of OpenVPN, you've actually converted that WAP back into a router (technically) and simply replaced the WAN's network interface w/ the VPN's network interface.
Why and when might this distinction matter?
Imagine you've given access to your OpenVPN server to a friend (and they've been assigned a specific IP on the tunnel by the OpenVPN server to uniquely identify them). And quite naturally you want to limit that access to perhaps only the internet, or internet and a few specific devices, even down to the port. Now the firewall becomes relevant. That requires changes to the FORWARD chain of the filter table. Or maybe you want to limit yourself (!), just in case your laptop or mobile device ends up in the wrong hands and they gain access to your network. Or maybe even due to an unknown OpenVPN vulnerability that someone is actively exploiting. By filtering access, you limit the potential damage.
Granted, none of these scenarios may apply in this particular case, and they're all a bit contrived. But I'm only trying to make the point that this WAP, w/ its active OpenVPN connection and tunnel, has the *potential* to make use of the firewall given the right conditions and intent. That potential has NOT been taken into consideration in the WAP wiki when it tells you to disable the firewall. Like most instructions, it assumes the WAP is only for bridged communications, which by definition makes the IP firewall irrelevant. But in the case of a VPN, that's not true anymore. That WAP isn't really a WAP anymore. It's just a plain ol' router once again, acting as a gateway between different networks. And like any router, the potential need to filter traffic between those networks.
That's why statements like "it's a WAP, it doesn't need a firewall" are only true to the extent it really is only a WAP. Users often create complex configurations that change the context assumed in the wikis. And why the recommendations of those wikis has always got to be read/interpreted with that in mind.
Again, these scenarios may all be irrelevant to the current situation, but we only have a *keyhole* view and understanding of your (or anyone else's) intent. So I want to be sure the above is understood just in case it happens to apply.
That's why statements like "it's a WAP, it doesn't need a firewall" are only true to the extent it really is only a WAP. Users often create complex configurations that change the context assumed in the wikis. And why the recommendations of those wikis has always got to be read/interpreted with that in mind.
That is the exact reason for the post. The VPN setup will be used when I am travelling. So its application falls into the category of "ok with WAP". You do make me thinking that maybe I need password protected certificate. I have another setup for the occasion - RDP to a home computer through an SSH tunnel - and I actually have the certificate for SSH password protected. Anyway thanks for bringing up the concerns that may associate with the WAP + OpenVPN.
