Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Using the firewall on RV042

Posted on 2014-09-18
Medium Priority
Last Modified: 2014-09-30

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.

Question by:Talds_Alouds
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 7
LVL 26

Expert Comment

by:Fred Marshall
ID: 40331720
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.

Author Comment

ID: 40331749
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?
LVL 26

Expert Comment

by:Fred Marshall
ID: 40332006
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.
Are You Ready for GDPR?

With the GDPR deadline set for May 25, 2018, many organizations are ill-prepared due to uncertainty about the criteria for compliance. According to a recent WatchGuard survey, a staggering 37% of respondents don't even know if their organization needs to comply with GDPR. Do you?


Author Comment

ID: 40335914
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?
LVL 26

Expert Comment

by:Fred Marshall
ID: 40335973
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

Author Comment

ID: 40338283
I also wonder whether virtual servers/port forwarding messes with this? Because we're using port forwarding.
LVL 26

Expert Comment

by:Fred Marshall
ID: 40338325
Is the port forwarding involving port 3391?

Author Comment

ID: 40338326
LVL 26

Expert Comment

by:Fred Marshall
ID: 40338343
Perhaps we should review the full picture...

Author Comment

ID: 40338387

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

Does that help?
LVL 26

Expert Comment

by:Fred Marshall
ID: 40339761
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....

Author Comment

ID: 40340386

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?
LVL 26

Accepted Solution

Fred Marshall earned 1500 total points
ID: 40340540
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.

Author Comment

ID: 40353356
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.

Featured Post

Introducing the WatchGuard 420 Access Point

WatchGuard's newest access point includes an 802.11ac Wave 2 chipset, providing the fastest speeds for VoIP, video and music streaming, and large data file transfers. Additionally, enjoy the benefits of strong security as the 3rd radio delivers dedicated WIPS protection!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I recently had the displeasure of buying a new firewall at one of the buildings I play Sys Admin at. I had to get a better firewall than the cheap one that I had there since I was reconnecting the main office to the satellite office via point-to-poi…
In this article, WatchGuard's Director of Security Strategy and Research Teri Radichel, takes a look at insider threats, the risk they can pose to your organization, and the best ways to defend against them.
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…
In response to a need for security and privacy, and to continue fostering an environment members can turn to for support, solutions, and education, Experts Exchange has created anonymous question capabilities. This new feature is available to our Pr…
Suggested Courses

722 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question