RV042 Group VPN & access rules

[peter]

I've setup a GroupVPN and connect to the RV042 with the Shrewsoft VPN client, works like a charm as opposed to QuickVPN ;-)

The firewall is configured with an explicit deny rule for RDP access to an internal server, also an explicit allow rule is created for certain IP numbers as source. I noticed that I need to create an explicit allow rule for the subnet the Shrewsoft client is using for the virtual adapter or I will not be able to access the internal server via RDP through the GroupVPN tunnel. 

Is this by design? I would think that setting up a tunnel defies the rules created for direct access on the WAN port.

Peter

[dondersconsulting]

if you have set your Deny rule for the internal LAN IP of the server, that is your issue.  It needs to block 3389 to the external WAN IP.   I assume you have created a custom service for RDP, TCP port 3389.  Set your deny rule to block this service for:

source interface:  WAN

source IP:     Any

Destination IP:  Single,  

This is screenshot of RV042 v1, but you can translate to v3.  If you need the v3 screenshot let me know.

[peter]

Thanks for the input, maybe I should have mentioned that we're not connecting on the original port on the outside, situation is as follows:

Under uPNP there's a custom service (8000~3389) which forwards to 192.168.100.120

I then set a deny rule in the firewall to block the custom RDP service (3389~3389)

Interface: WAN1

Source IP: ANY

Destination IP: 192.168.100.120

After this rule, allow rules are created for the source IP's I want to allow,

This works fine but as mentioned in the starting post, I have to allow the IP range assigned to the Shrewsoft virtual adapter to be able to access 192.168.100.120.

I would think that an authenticated VPN tunnel is routed internally to avoid the firewall.

I tried your suggestion to block on the WAN IP but that does not seem to block anything and I wonder if this really could work since the WAN1 interface = our external IP

Under Forwarding I've created a rule to forward the custom RDP (3389~3389) service to 192.168.100.120.

I then set a deny rule in the firewall to block the custom RDP (3389~3389) service

Interface: WAN1

Source IP: ANY

Destination IP: our external IP

After this I can still connect on our external IP on port 3389

[dondersconsulting · Accepted solution]

sorry, I got my signals crossed with my previous suggestion.  Your reply cleared up my misunderstanding.  My rule was for a different purpose, and does not work for your situation as I thought it would.

port forwarding (UPnP or Forwarding) supersedes the firewall rules but does not completely bypass them. It must bypass the default rules to work, but does not pass the custom rules.  The trick is knowing that the forwarding translation happens first, so when it is processed by the firewall, the destination is the internal IP and port.  Also, it would seem that VPN works similarly - bypasses the default firewall rules but not custom ones.

Since you want to double up your security and have a non-standard port PLUS limit access to specific IPs via firewall rules, then you are configured correctly. 

Should the VPN bypass the firewall completely?   Maybe, but then you wouldn't have the ability to filter VPN clients with custom rules (without a separate VPN firewall section).  Since you created a custom block rule, you must add an Allow rule for ANYTHING coming through the WAN port (even VPN).   I agree this is annoying, but it's just how the programming is written.

I did not test the VPN rules, but I think you can handle that - the only variable should be do you allow for the remote network public IP or the remote LAN subnet range?  I would expect the LAN subnet.

----------------------

Other thoughts - personally, I just use the non-standard port and let RDP security take care of itself.  My clients are very small businesses, so exposure and risk are pretty low.  For a higher-profile or higher-security client, I would either put everything inside a VPN connection, or configure as you have.  Of course, if security is that important, maybe you should be on a more expensive (and capable) device?

[peter]

Plausible explanation on the inner workings of the devive, thanks for that. That clarifies things for me.

Indeed for the VPN I allow for the remote LAN subnet and that works fine.

I agree that normally changing the default port for RDP should be enough but lately we've had 2 clients where the non-standard ports we're found by some script kiddies and were hacked because the administrator account had not been renamed, since the lockout mechanism didn't apply to that account they managed to guess their way in over a period if several days.

[dondersconsulting]

glad I could help - even if it was just to validate what you already had figured out.  =)

To protect the built-in Administrator account or any other accounts in the "Administrators" group, I always edit the group policy to only allow "Remote Desktop Users" group (and a custom-named domain admin) access to login remotely.  Or, the local security policy - just run gpedit.msc at that machine.  This will deny access to all accounts not expressly in that group, so it's easy to see and control who can and cannot use Remote Desktop.  Not that it's a fix, but might be a good extra layer of security for you.