09-08-2020 03:47 PM
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
Solved! Go to Solution.
01-13-2021 05:57 PM
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.
09-09-2020 07:47 AM
check your port-forwarding rule
looks like you configured for ANY interface, not just WAN to LAN
01-13-2021 05:57 PM
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.
02-21-2021 08:13 PM - edited 02-21-2021 08:17 PM
@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!
02-21-2021 08:47 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide