Using the firewall on RV042


I have a number of clients that have a mixture of RV042 and RV042G.

The other day I configured the RV042G to restrict access access on a number of ports so that only our external IP was allowed. Tested and it worked well.

I've now tried to replicate this on an RV042 and I just can't get it to work. See the attachment.

The Source IP is our external IP of our network. But even with this setting, I'm still able to access that RDP on 3391 from another external IP.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Fred MarshallPrincipalCommented:
Well, I can't read the source for the first entry but that would be the place to look I should think because the first policy should allow it and the second policy will block it.
But if you source IP is as you say, our external IP of our network, then in some sense that will *always* be the source so everything will pass through .. or could.
What you need in the source address field, it seems to me, is the *remote* public IP that you want to allow to pass through.

Also, you didn't say which version of the RV042.  Is it v0 or v3 and which firmware?

I like the RV042 but some things in it are quirky.

Anyway, the source and destination addresses as you likely know can each be either a single address or a range of addresses.  So you could allow a single source address or a range of them.
If you have a non-contiguous list of them then you would need individual policies - one each.
But, it appears that the RV042 will use your own WAN address as the source which, really, means *everything* I should think.
Talds_AloudsAuthor Commented:
Sorry, when we say 'our', we mean the IT provider's external IP. The RV042 is the client's device.

I blanked out the source on purpose. The source is our (IT provider's) external IP (single).
FW is which I believe is current. They haven't done an update on it for years as it's EOL. It's not V3, I know that much.

so it looks to be correct?
Fred MarshallPrincipalCommented:
No, I don't believe that can be correct because you are using a "localized" public IP address as the source.  
As long as a known public IP address in the nearby chain is what's entered then how can packets *not* be from there so to speak.  I can't guarantee how the RV042 reacts in a setup like that but it sounds wrong anyway.

You need to list the *originating* source public IP address and not one in between.


You have site A from which you want to send packets through this RV042 firewall.  You enter *its* public IP address in the policy as the source.
If you have other such sites then you would either:
- put them in an IP source RANGE
- list them as source in separate policies.
What were the top attacks of Q1 2018?

The Threat Lab team analyzes data from WatchGuard’s Firebox Feed, internal and partner threat intelligence, and a research honeynet, to provide insightful analysis about the top threats on the Internet. Check out our Q1 2018 report for smart, practical security advice today!

Talds_AloudsAuthor Commented:
Hi FMarshall,

But isn't that what we've done?

Consider this:

Site A (client's office).
Site B (our office).

We create firewall rules in Site A's firewall as shown in the original picture.
the source IP address to allow is the public IP of Site B.
All other public IP addresses should be blocked.

Is that wrong?
Fred MarshallPrincipalCommented:
That seems correct.  I misunderstood
The source is our (IT provider's) external IP (single).
only our external IP was allowed
and to be the local public IP.  

I wonder what happens if you set the 2nd rule to block everything up to port 3390 and set a 3rd rule to block everything from 3392 on up?  And what happens if you disable the 2nd rule?

I don't know how the RV042 policies are applied.  For example, in some machines, as soon as a policy is hit that applies then that policy applied as all other policies are skipped.  But, I can imagine a different approach that says: "As long as a packet would be allowed then the following policies are applied to it".  Perhaps that makes no sense but I've not thought about it enough to figure that out.  Anyway, if you say "pass it" on the first rule and "block it" on the second rule then might it be blocked?  It should be easy enough to experiment to see what to expect from the v0 machine.  I've not tried this experiment.
Is the firmware
Talds_AloudsAuthor Commented:
I also wonder whether virtual servers/port forwarding messes with this? Because we're using port forwarding.
Fred MarshallPrincipalCommented:
Is the port forwarding involving port 3391?
Talds_AloudsAuthor Commented:
Fred MarshallPrincipalCommented:
Perhaps we should review the full picture...
Talds_AloudsAuthor Commented:

Well we use UPNP to map external ports to different internal ports.
See the attachement showing
3391 (ext) > 3389 (int)

Does that help?
Fred MarshallPrincipalCommented:
My first thought is that you put in the Destination setting of the firewall instead of ANY.
But I see that you do have a Service defined which appears to also involve port forwarding but that's not clear as it's just in a label/name for that service.

What happens if you start with no port translation and address directly to port 3389 from start to finish?

I know there are things that the RV042 won't do (that one might think it *should* do) but have no experience with this combination of things.  So, I'd boil this down to the simplest possible things and see if you can't make it work.  Eventually you may run into something that won't work as settings would suggest.

You might look at:

One thing I notice is that UPnP need not be enabled to use the port translation....
Talds_AloudsAuthor Commented:

So I'm testing this now.
1) disabled the RDPtoVSBS UPNP rule. Now I can't RDP to the destination server at all on port 3391
2) enabled the two firewall rules in the previous screenshot. rebooted. Still can't RDP in to server.
3) enabled UPNP RDPtoVSBS rule. rebooted. Can access RDP from multiple public IPs.

I just had a look over my last configuration in a similar situation for another client and I've just realised that the this setup worked correctly in an environment where the firewall rules were not applying to UPNP rules, but merely port forwarding. I'm getting a sneaking suspicion that for some reason they just don't work for UPNP rules. Also just checked another client who has an RV042G where I've setup the same sorts of rules with UPNP....Those firewall rules too don't work.

I also amended the rules to specify traffic to to the IP.

I think we can just put this down to a lack of feature?
Fred MarshallPrincipalCommented:
Yes, lack of feature or perhaps by intent?
You might see for another example where the WAN side must point toward the internet (such as for an MPLS interface router application).

And, I found this:
On the UPnP Forwarding screen, you can configure port forwarding to UPnP-based devices. Unless you require UPnP, it is recommended to use basic port forwarding, which is more secure because it cannot be manipulated by hosts running the UPnP protocol.

On the DMZ screen, you can identify a single host that will be treated as a completely unfiltered and unprotected host by the router. Although the internal host still uses NAT for communications with external resources, the router/firewall allows all solicited and unsolicited traffic from external sources to the server specified as being in the DMZ.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Talds_AloudsAuthor Commented:
Thanks FMarshall.

Yes it's probably by design and there probably is a way to do it, but I'll just give Cisco a call.

If I get anything more, I'll see if I can add it to this thread.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.