RVS4000; Port Forwards bypass IP ACL; How to filter

Unanswered Question
Jan 19th, 2010

I am using a RVS4000.  I am forwarding several ports to a specific host on the LAN.  Nonetheless, I wish the IP ACL in the firewall to block incoming traffic from the WAN unless the IP ACL allows.  However, it seems that any port which is forwarded happens prior to and bypasses the ACL rules.  How do I block traffic from "bad" addresses when the destination port is in the forwarding table?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Te-Kai Liu Tue, 01/26/2010 - 00:40

We did some testing and found the following scenario work fine.

Configure a FTP Port Forwarding Rule.

Create an ACL Rule as in attachment 1.

Enable the ACL Rule as in attachment 2.

The specific WAN IP will be blocked from accessing the FTP service.

michaelrach Wed, 01/27/2010 - 12:35

Interesting.  I was attempting to block at the subnet level and the RVS4000 happily forwarded the packets.

I have the same problem. I replaced a Netgear Pro Safe VPN router with the Cisco RVS4000.

I have 1 LAN PC where I want to connect to RDB only from 1 single internet IP.

If PORT forwarding is set in the RVS4000 it forwards any source IP no matter what is configured in the IP ACL.

@Cisco Support: Either make ACL work before Port is forwarded or add the option to define a Source IP in the Port Forwarding section.

Thanks

Andy

michaelrach Thu, 02/04/2010 - 06:20

I agree an ACL which does not control access makes for a pretty poor firewall.  The ACL's should be read before port forwarding.  I find myself in the position of having to configure multiple firewalls, one after the RVS4000 to actually block the forwarded ports.  In my opinion this is a security flaw and a major one.

Te-Kai Liu Sat, 02/06/2010 - 00:05

If you define 2 ACL rules and give the "Allow" rule higher priority than the "Deny" rule, as shown in the attached screenshot, the router will only let the allowed source ip to access the forwarded service. In the example, only the IP address 172.21.211.124 can access the FTP service. Others can't access it.

Attachment: 

The router is still allowing any internet IP to connecto to my RDB port.

See screen shots.

I also tried to reboot the RVS4000 but I still can connecto to RDB even from an other IP than allowed!!

It looks like this is a major problem on the RVS4000 that it is not doeing anything with ACL´s.. My firmware is 1.3.1.0 (new device)

Attachment: 
Te-Kai Liu Sat, 02/06/2010 - 08:29

What's your internet connection type, PPPoE, DHCP, or Static IP?

It will be easier for the developer to see the problem if you call Small Business Support Center to provide your router's configuration file.

pastorbadger2 Tue, 02/15/2011 - 23:48

By George, I think I've got it!  (Well, I've narrowed it down anyway.)  So, I've got an RVS4000 with firmware version V2.0.0.3 and I've been trying to do a similar thing:  I have a NAS sitting on my local LAN with a horribly insecure FTP server on it.  I would like my mainframe to send files to that server.  But I don't want the rest of the friggin Internet beating on it.

So, I set up a Single Port Forward and two ACL rules, as described by tekliu above.  Alas, just like michaelrach above, every address in the Internet was able to get through the firewall on port 21.

I read all the posts, asked all the experts, swore a lot, wailed and gnashed my teeth.  Then I set up a test and banged away for a while.

First, I took Tekliu exactly at his word and try adding (#2) a Deny for everybody and (#1) an Allow for the single IP address I want in.  That worked!  The right host can get in and the wrong host can't.  I'm ready to turn out the lights and go home. 

But I wanted to figure out why my initial attempt (and those of the others who posted here) didn't work and this one did.  After much guessing, I discovered that if you specify an Allow range of x.y.4.2 thru x.y.4.254, it works correctly.

If you specify an Allow range of x.y.1.1 thru x.(y+1).1.1 it lets everybody through.

x.y.4.2 thru x.y.128.254 works correctly.

x.y.4.2 thru x.y.200.254 lets evrybody through.

It's the binary difference between the start and end address!  I didn't feel like narrowing it down farther.  But to someone who understand this stuff, this has to be a real good clue as to why it's failing.

Actions

This Discussion