This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Anyone here have experience with the BR500 VPN Firewall / Router and getting Firewall => Traffic Rules working? I'm using the web console, and not Insight.
I have set up From an external IP (WAN) and port To an internal LAN server and port, but I cannot get the trigger to work; attempting to connect from the external IP to the internal server does NOT work with the Firewall => Traffic Rule. I previously had this working on an FVS318Gv2, and never had a routing problem with that device.
I can get the same external server and port to work with Port Forwarding, but I need to filter by IP, which is why I am trying to set this up under Traffic Rules (as Port Fowarding does not allow specifying a source IP).
An additional problem is that I can't access the external WAN address from my LAN, at least not with port forwarding. More precisely, I can ping the external WAN address from my internal network, but I cannot specify a port and get Port Forwarding to work from any of my LAN servers. I do have a number of Port Forwarding ports working correctly from servers located outside my LAN (on the public Internet), just not internally. Again, this was not a problem on the FVS318Gv2.
Ideally, I'd like to be able to use the same (external) IP address, regardless of whether I am inside or outside my local network.
Any help would be appreciated. I have opened a support ticket for the first issue (Traffic Rules not working) and after spending more than an hour on the phone, the Netgear tech could not figure it out, and is going to "test in the lab" and "look for similar cases", and interestingly, asked me to send screen shots of my FVS3`8Gv2 router configuration (which was working).
I understand that the FVS318Gv2 is no longer supported, and after several years of use, it tends to crash or hang in warmer temeratures, or sometimes just shortly after making any configuration changes, which is why I was hoping to replace it with a newer supported device. But I am having some challenges in getting the same functionality, even though most of the options appear to be available in the web console.
I was just thinking about this wrong, and now understand. On my FVS318Gv2, the once screen did both the port fowarding and the access restrictions. On the BR500, if I think of Traffic Rules as JUST iptables, and nothing else, then this makes perfect sense. Always provide the accept rules first, and then drop everything else later. Got it.
I can now move foward ... the fun will be when I start adding more rules, and need re-order the accept and drop rules ... all without a visual editor ... 😉
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.
Very appreciate the description in detail, your requirment, establish the connecion from Cloud to Local with port 5984, allow public address 34.233.185.29 to access only, I think you can achieve that with BR500.
Step1: using port forwarding under firewall, to mapping 5984, after that, Cloud can reach local on 5984 with BR500 WAN IP address
Step2: Create two traffic rules under firewall, allow the connection between Cloud and local
- rule1, From local 192.168.1.170 in LAN to 34.233.185.29 on WAN, action Accept
- rule2, From local 192.168.1.170 in LAN to any rounter IP outside on WAN, action Drop
I was just thinking about this wrong, and now understand. On my FVS318Gv2, the once screen did both the port fowarding and the access restrictions. On the BR500, if I think of Traffic Rules as JUST iptables, and nothing else, then this makes perfect sense. Always provide the accept rules first, and then drop everything else later. Got it.
I can now move foward ... the fun will be when I start adding more rules, and need re-order the accept and drop rules ... all without a visual editor ... 😉
