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.
I am trying to set up a WNR1500 to allow VPN connections.
I need to OPEN ports, 443, 500, etc. to the entire LAN subnet.
It appears that all of the settings for Blocking Services, UPNP, DMZ are either the wrong idea or are set for specific LAN IPs and not a range of LAN IPs.
You are talking about the port forwarding feature in a NAT router. All unsolicited inbound traffic will have the same destination IP address. How does router know which local IP address to forward those packets to? Short answer: it can't.
If there were no NAT and the clients all had public addresses it would be different. Then you'd have a firewall edge router, and you could set up rules like the ones you have in mind.
If the goal is to set up a VPN client connection to the local network, you either need a router that has that built in, or a VPN server. If you have a server, then then ports are forwarded to that server. In the other direction, VPN connections from the local network outbound should just work.
It seems that the answers I'm getting aren't quite about what I was asking.
First, I wasn't talking about port forwarding. Admittedly it's similar but it's not the same thing. Nor is this about VPN-capable routers (as an end point).
The question was about firewall rules.
Inbound traffic would surely have the same public IP addresses or they wouldn't be "inbound". So that much is obvious.
However, the same inbound traffic will have multiple port addresses.
One port address is used to translate in the NAT into an internal IP address AND port - so that's how the router knows.
Consider instantiating two browsers on the same computer. Each one will have its own source port which is what would be used for responses. Each one will have a destination port which will be the same (e.g. port 80).
But these details aren't the issue. I don't care how incoming packets were formed. I only care how they will be handled.
Let's start with 192.168.1.99 source port 5555 and destination IP 123.234.123.234 and destination port 6666.
Assume the router has a public IP of 234.234.234.234.
Assume that the outgoing firewall rules are ALLOW ANY
The NAT will assign a new port number for 192.168.1.99:5555 that is 234.234.234.234.234:xxxx with the destination IP and port unchanged.
The response from 123.234.123.234 will be perhaps source IP 123.234.123.234:6666 and destination 234.234.234.234:xxxx
IF the incoming firewall rules allow,The Nat will forward this packet to 192.168.1.99:5555.
There is no EXPLICIT port forwarding setup here. It's automatic.
And, I suppose one might add: If there is stateful packet inspection then there has to be a match with information taken from the outgoing packet.
And, stateful packet inspection would be part of the incoming firewall rules.
Perhaps it will be clearer if I note:
Port forwarding (whether with translation or not) is intended to forward incoming packets to a designated internal IP address. Right?
And, firewall rules, are intended to pass packets or block them but not direct them as in port forwarding. Right?
My concern is the functionality of explicit firewall rules. That is, rules that are set by an administrator.
So, I note that:
1) some routers have traditionally allowed firewall rules that pertain to (i.e. ALLOW or BLOCK) destination port numbers and apply to a RANGE of internal IP addresses).
and
2) More recently, I see that some routers DO NOT ALLOW a RANGE of internal IP addresses in the firewall rules. (Of course, usually the rules are ALLOW because otherwise the default is usually BLOCK).
What this means is that the latter can only ALLOW traffic with a particular destination port to go to a single internal IP address.
[AND NOT to ANY internal IP address as in (1) above].
Perhaps this is why there's confusion with port forwarding....
The question is: Why (2) instead of (1)??? What's the rationale?
My concern is the functionality of explicit firewall rules. That is, rules that are set by an administrator.
Thanks, this explanation clarifies your question. The settings do vary by router model, and I'm not seeing much beyond port forwarding in the manual for your WNR1500 either.
My r8500 does let me create services with destination port ranges and IP address ranges, and to block those services on a schedule. I'm not sure if these are outbound rules or bidirectional (overriding forwarding for example) - the documentation doesn't say (and it's not a feature I'm using). I haven't ever seen configurable firewall rules that specify inbound/outbound on a Netgear home router.
As far as I am aware, the built-in rules permit outbound traffic to any destination port, and inbound return traffic on that connection is automatically forwarded back to the local sending device as you describe. Though I haven't tested the return path lately with UDP. Unless I'm misunderstanding, that would mean all ports are OPEN to the full subnet by default (going back to your original post).
Let's examine a reasonable objective and see what we think:
We have a site which is set up for official guests using its own public ip address and router. It's an entirely separate network.
The guests will be using either:
1) VPN client software to "phone home" from each of their multiple computers.
2) VPN device/router(s) to "phone home" as a VPN end point.
1. If there are a number of VPN software clients running on site then each one has to be able to connect to "home". Let's assume that they are using Netgear Prosafe VPN client pro. Under normal circumstances would this situation require that ANY firewall rules be set up at our site to assure their success?
I should think that such an arrangement would work with no firewall tweaking because they have to work in coffee shops, no?
2. If there is a VPN device brought into our faciltiy's guest network (for site-to-site VPN) then, since our firewall intercedes upstream of it, are there requirements on our router firewall rules that will allow this to work?
In this case it's more understandable that ports in our firewall have to be opened such as from
"To make IPSec work through your firewalls, you should open UDP port 500 and permit IP protocol numbers 50 and 51 on both inbound and outbound firewall filters. UDP Port 500 should be opened to allow Internet Security Association and Key Management Protocol (ISAKMP) traffic to be forwarded through your firewalls. IP protocol ID 50 should be set to allow IPSec Encapsulating Security Protocol (ESP) traffic to be forwarded. Finally, IP protocol ID 51 should be set to allow Authentication Header (AH) traffic to be forwarded."
But, in this case, there *would be* a single IP address; the internal IP address of their VPN router. Well, unless there's more than one VPN device brought in - which is much less likely.
2. If there is a VPN device brought into our faciltiy's guest network (for site-to-site VPN) then, since our firewall intercedes upstream of it, are there requirements on our router firewall rules that will allow this to work?
I guess this depends on the nature of the device. The VPN site-to-site device in my home office (Aruba) would work fine. It makes an outbound connection to the corporate infrastucture, and client devices using it need to connect to the Aruba over wifi or ethernet. More than one of these gadgets should work fine in your hypothetical.
If the device has to accept an inbound connection from the far end, then of course your reasoning is perfectly correct.
Well, when the VPN device is also the network gateway then it's easy. But when the VPN device is behind a firewall then I've always had to open ports. I've never thought about which end point is "sending" as they appear to be symmetrical.
Well, when the VPN device is also the network gateway then it's easy. But when the VPN device is behind a firewall then I've always had to open ports. I've never thought about which end point is "sending" as they appear to be symmetrical.
The only hardware VPN device I have experience with is the Aruba, which doesn't need any ports opened.
OpenVPN is enabled on my R8500 (which is behind my ISP router), and of course I do need to open ports in the ISP router for it.
