Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 366
  • Last Modified:

Using the firewall on RV042

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
Talds_Alouds
Asked:
Talds_Alouds
  • 7
  • 7
1 Solution
 
Fred MarshallCommented:
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
 
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 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
 
Fred MarshallCommented:
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
Independent Software Vendors: 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!

 
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?
0
 
Fred MarshallCommented:
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
 
Talds_AloudsAuthor Commented:
I also wonder whether virtual servers/port forwarding messes with this? Because we're using port forwarding.
0
 
Fred MarshallCommented:
Is the port forwarding involving port 3391?
0
 
Talds_AloudsAuthor Commented:
Yes.
0
 
Fred MarshallCommented:
Perhaps we should review the full picture...
0
 
Talds_AloudsAuthor Commented:
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
 
Fred MarshallCommented:
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
 
Talds_AloudsAuthor Commented:
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
 
Fred MarshallCommented:
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
 
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.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 7
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now