Solved

Using the firewall on RV042

Posted on 2014-09-18
14
307 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
  • 7
  • 7
14 Comments
 
LVL 25

Expert Comment

by:Fred Marshall
Comment Utility
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
Comment Utility
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 25

Expert Comment

by:Fred Marshall
Comment Utility
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
 

Author Comment

by:Talds_Alouds
Comment Utility
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 25

Expert Comment

by:Fred Marshall
Comment Utility
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
Comment Utility
I also wonder whether virtual servers/port forwarding messes with this? Because we're using port forwarding.
0
 
LVL 25

Expert Comment

by:Fred Marshall
Comment Utility
Is the port forwarding involving port 3391?
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:Talds_Alouds
Comment Utility
Yes.
0
 
LVL 25

Expert Comment

by:Fred Marshall
Comment Utility
Perhaps we should review the full picture...
0
 

Author Comment

by:Talds_Alouds
Comment Utility
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 25

Expert Comment

by:Fred Marshall
Comment Utility
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
Comment Utility
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 25

Accepted Solution

by:
Fred Marshall earned 500 total points
Comment Utility
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
Comment Utility
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

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

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…
Network traffic routing plays key role in your network, if you have single site with heavy browsing or multiple sites, replicating important application data from your Primary Default Gateway ,you have to route your other network traffic from your p…
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…
You have products, that come in variants and want to set different prices for them? Watch this micro tutorial that describes how to configure prices for Magento super attributes. Assigning simple products to configurable: We assigned simple products…

743 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

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now