cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3336
Views
26
Helpful
4
Replies

RV340 Restrict Port Forwarding To Specific IP Address

mfried40
Level 1
Level 1

I'm just bought an RV340 for our business office and while setting up port forwarding I tried to restrict access to the forwarded ports in the firewall access rules as I did in our other office with an older RV016 but when I tried to do so I found that when I'm creating a port forwarding rule the system is automatically creating a firewall rule to allow the external port from any source IP Address and when I tried to edit the rule I got the following message "Not editable because this rule is automatically generated by port forwarding".

Any help with this?

That's a ridiculous thing, should I have my RDP servers open to the whole world?

if I can't get a solution for this I'll have to get a new router

1 Accepted Solution

Accepted Solutions

Garth2079
Level 1
Level 1

I just had this problem and a search revealed this thread.

 

It's not immediately obvious, I had to guess and experiment.

In short, you leave the auto-rule in place. You then create two more rules:

Rule 1: ALLOW / RDP / Source Interface = WAN1 / Source = <client external IP> / Dest Interface = VLAN1 (or your choice of dest) / Destination = <internal IP of RDP machine> / Sched = ANY

Rule 2: DENY / RDP / Source Interface = WAN1 / Source = ANY / Dest Interface = VLAN1 (or your choice of dest) / Destination = <internal IP of RDP machine> / Sched = ANY

 

They seem to contradict, but remember the rules are applied in numerical order. So if Rule 1 is above rule 2, rule 1 is applied first.

That's also why the auto rules have an auto number of 4001+. If you place other rules before them, those rules win.

 

To be 100% clear, the logic is:

Your trusted client connects, and Rule 1 is matched (allow). Further rules are ignored.

An untrusted client connects, and Rule 2 is matched (deny). Further rules are ignored.

In either case, auto-rule 4001 is ignored because either rule 1 or rule 2 will always match incoming RDP traffic on 3389.

 

I have tested this and it works. I used 2 external machines and an RDP rule to an internal client. You can test before committing the config changes to disk.

 

Probably too late to help you, but better late than never.

View solution in original post

4 Replies 4

pieterh
VIP
VIP

check your port-forwarding rule

looks like you configured for ANY interface, not just WAN to LAN

Garth2079
Level 1
Level 1

I just had this problem and a search revealed this thread.

 

It's not immediately obvious, I had to guess and experiment.

In short, you leave the auto-rule in place. You then create two more rules:

Rule 1: ALLOW / RDP / Source Interface = WAN1 / Source = <client external IP> / Dest Interface = VLAN1 (or your choice of dest) / Destination = <internal IP of RDP machine> / Sched = ANY

Rule 2: DENY / RDP / Source Interface = WAN1 / Source = ANY / Dest Interface = VLAN1 (or your choice of dest) / Destination = <internal IP of RDP machine> / Sched = ANY

 

They seem to contradict, but remember the rules are applied in numerical order. So if Rule 1 is above rule 2, rule 1 is applied first.

That's also why the auto rules have an auto number of 4001+. If you place other rules before them, those rules win.

 

To be 100% clear, the logic is:

Your trusted client connects, and Rule 1 is matched (allow). Further rules are ignored.

An untrusted client connects, and Rule 2 is matched (deny). Further rules are ignored.

In either case, auto-rule 4001 is ignored because either rule 1 or rule 2 will always match incoming RDP traffic on 3389.

 

I have tested this and it works. I used 2 external machines and an RDP rule to an internal client. You can test before committing the config changes to disk.

 

Probably too late to help you, but better late than never.

@Garth2079 Wow! that solved it

 

I remember trying out custom firewall rules to workaround the auto rules but looks like I just tried to add the deny rule after the auto rule which just blocked everything

 

Thank you so much! 

Screenshot 2021-02-21 231519.jpg

To be fair to Cisco, this is the principle used by enterprise firewalls. It's pretty much global and hence the knowledge is very transferable.

 

To be fair to you, this isn't an enterprise firewall so Cisco could document it better without assuming end users are familiar with enterprise firewall principles.

 

Glad you got it sorted.

Review Cisco Networking for a $25 gift card