BR500 Firewall Problems

[Re-Posting since it appears that my first attempt did not post correctly]

Bruce_G,

I have a BR500 running Firmware 5.5.0.1.  The typology in this case is :

[Local 192.168.1.170:5984] <--> [Netgear BR500] <--> [Cable Modem 65.110.137.194] <--> [Public Internet] <--> [Cloud 34.233.185.29]

Local is a Linux server running CouchDB and listening on port 5984.

Cloud is another Linux server running on AWS EC2.

My intent is to be able to open a network connecion from Cloud to Local on port 5984, but restricted to source IP 34.233.185.29.

If I login (ssh) to Cloud, I believe I should be able to telnet to port 5984 on my external IP address, e.g.:

  $ telnet 65.110.137.192 5984

and get connected to the CouchDB port on Local.  If it would connect, I could then send 'GET /' and receive server version information.  Instead, i just hangs.  And yes, of course, this would eventually be an application running on Cloud that could talk to the CouchDB database on Local, however, I am keeping it simple for this example by using telnet.

What does work is if I set up Port Forwarding as:

  Service Name: COUCHDB

  Protocol: TCP

  External Port Range: 5984

  [X] Use this same port range for internal port

  Internal IP Address: 192.168.1.170

Once I have done that, I can connect from Cloud to Local by logging into Cloud and using the command:

 $ telnet 65.110.137.192 5984

However, that would leave the connection open to all public IPs, and I need to restrict this to a single source IP (34.233.185.29).  But it does confirm that the connection works, and that there are no other firewalls, etc., getting in the way.

I have attempted to do this -- restricting by source IP -- by remving the Port Forwarding, and setting up Traffic Rules as follows:

  Name: Portal CouchDB

  Protocol: TCP

  Source Zone: WAN

  Source IP address (Only This IP Address): 34.233.185.29

  Source Port: 5984

  Destination Zone: LAN: LAN1

  Destintion IP address: 192.168.1.170

  Detination Port: 5984

  Action: ACCEPT

My expectation is that removing the Port Forwarding (above) and entering this Traffic Rule would result in the same behavior, only restrict it to the source IP (34.233.185.29).  Instead, the connection just hangs for 30+ seconds, and then eventually times out.

Here are some of my questions (which the customer service rep could not answer):

1. The BR500 appears to be using iptables (which I am very familiar with).  Usually the "standard" iptables configuration (default) permits all outgoing connections, but only permits incoming connections that are exlicitly configured.  However, I cannot see the iptables configuration through the web console on the BR500.  Is that still the case for the BR500, or once I start entering specific incoming connections, do I need to also enter explicit outgoing connections to the same IP (e.g., with an established state, or for all ports, or ???).  I have tried a few variations that I could think of going the other way, but none of worked.  I don't *think* that should be needed, but again, I have no visibility into the actual iptables configuration.

2. When I have the Port Forward in place, and I make a connection on port 5984, and I look at the BR500 log, I see the incomming connection being accepted, which is from a high port (> 2014) from Cloud's IP (34.233.185.29) to port 5984 on Local (192.168.1.170).  This confirms the correct source IP that the BR500 is seeing (34.233.185.29).  When configuring the Traffic Rule, I assume that I still want to enter port 5984, which the Cloud client is trying to open on the BR500's external IP (65.110.137.194), and not the actual outgoing port number of the client (> 1024), is that correct?  Otherwise, I would not have any way to identify the port that the client is trying to use (since local outgoing ports are typically random >1024).  I am only questioning this because I can't figure out why my Traffic Rule is not working.  I have also tried 'any' as the source port in the Traffic Rule, which did not appear to work either.

3. When I remove the Port Forward, and enter the Traffic Rule, which hangs, I do not see anything in the BR500 log.  Shouldn't I be seeing any connection rejects or errors in the log?  If I try from any random external IP to any random port -- which should not work, and does not -- I don't see anything in the BR500 log ... which I would expect to see as rejected connections, and would obviously help me to troubleshoot all of this.  So how do I get the BR500 to log rejected connections, and not just successful connections?

4. A second problem, which may or may not be related, is that I cannot connect to the external IP (65.110.137.194) from my LAN.  I can ping that IP, but my expectation would be able to connect to specific ports on that IP and have Port Forwarding work.  E.g., I have set up Port Forwarding on port 22 to (another) local Linux server.  I would expect to be able to ssh to port 22 on the external IP (65.110.137.194) from one local Linux server and have it forward to the other local Linux server.  This does, of course, work correctly from any other external (public Internet) server.  And I was able to do this on my NETGEAR FVS318Gv2 (which the BR500 is replacing).

Finally, I am connecting screen shots (in a zip file) of how I got this working years ago on an FVS318Gv2, which I had no trouble setting up.  I love the FVS318Gv2, it was easy to configure, but alas, it has thermal problems, and I need to 'Restore Factory Setting' and reload the configuration periodically, otherwise it tends to crash or hang from time to time (either during the summer when it gets warmer, or shortly after I make a configuration change).  I have gone through four (4) FVS318Gs (2x original, 2x v2, replacing each once), all of which seem to run for a year or two, and then become unreliable, which is why I am "upgrading" to a BR500 in the hopes of having something more reliable and supported (since NETGEAR has dropped the ProSafe line).

Gist is that all I want to do is get back the functionality I had with my FVS318Gv2 router.  At one point, when the customer service rep was getting frustrated, they said that the BR500 was NOT a firewall, whereas the FVS318Gv2 was, and that I could not use the BR500 as a firewall.  I then provided a screen shot of the NETGEAR web site, stating that the BR500 had firewall capability, which I am still hoping is actually the case.

Thanks,

Dave Filip