Solved

Using the firewall on RV042

Posted on 2014-09-18
14
347 Views
Last Modified: 2014-09-30
Hi,

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.

Thanks
rv042.png
0
Comment
Question by:Talds_Alouds
[X]
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
14 Comments
 
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.
0
 

Author Comment

by:Talds_Alouds
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 1.3.13.02-tm 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?
0
 
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.

Example:

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
or
- list them as source in separate policies.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 

Author Comment

by:Talds_Alouds
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?
0
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 40335973
That seems correct.  I misunderstood
The source is our (IT provider's) external IP (single).
and
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
0
 

Author Comment

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

Expert Comment

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

Author Comment

by:Talds_Alouds
ID: 40338326
Yes.
0
 
LVL 26

Expert Comment

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

Author Comment

by:Talds_Alouds
ID: 40338387
Ok,

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

Does that help?
UPNP.JPG
0
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 40339761
OK.
My first thought is that you put 192.168.6.13 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:
https://supportforums.cisco.com/discussion/10738586/port-forwarding-port-translation-rv042-rv016-rv082

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

Author Comment

by:Talds_Alouds
ID: 40340386
Ok,

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 192.168.6.13 IP.

I think we can just put this down to a lack of feature?
0
 
LVL 26

Accepted Solution

by:
Fred Marshall earned 500 total points
ID: 40340540
Yes, lack of feature or perhaps by intent?
You might see http://www.experts-exchange.com/Hardware/Networking_Hardware/Routers/A_6533-Using-Cisco-Linksys-RV042-RV0XX-Routers-in-Router-Mode.html 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.
From: http://www.ciscopress.com/articles/article.asp?p=598649&seqNum=5
0
 

Author Comment

by:Talds_Alouds
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.
0

Featured Post

What, When and Where - Security Threats from Q1

Join Corey Nachreiner, CTO, and Marc Laliberte, Information Security Threat Analyst, on July 26th as they explore their key findings from the first quarter of 2017.

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…
Occasionally, we encounter connectivity issues that appear to be isolated to cable internet service.  The issues we typically encountered were reset errors within Internet Explorer when accessing web sites or continually dropped or failing VPN conne…
There's a multitude of different network monitoring solutions out there, and you're probably wondering what makes NetCrunch so special. It's completely agentless, but does let you create an agent, if you desire. It offers powerful scalability …
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…
Suggested Courses

630 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