Does NPt make my internal network more secure?
-
"So am I missing something obvious here?"
Yeah.. Just because your IP is public or global doesn't mean anyone from internet can get to it. That is the whole point of the firewall.
if your app is only going allow specific prefixes to talk to you, you would use the prefixes you use internally, etc.. You wouldn't allow all of ipv6 space to get access.
"2001:2000:9000:3000::/64 can access it, someone from my ISP could just use one of the addresses to access my internal service from outside my lan. Right?"
No - how exactly would they do that??
-
You can use Unique Local Addresses, the IPv6 equivalent of IPv4 RFC 1918 addresses. You can create a prefix in that range, which those servers can use. You can then have both global and local addresses on the computers that have to access both those servers and the Internet. Contrary to what some here will say, that is an entirely valid configuration and supported by IPv6 design. Of course, there's no reason why you couldn't add a 2nd LAN interface and let pfSense route accordingly.
-
And completely pointless… Zero reason to run ULA if your going to run global..
-
"So am I missing something obvious here?"
Yeah.. Just because your IP is public or global doesn't mean anyone from internet can get to it. That is the whole point of the firewall.
if your app is only going allow specific prefixes to talk to you, you would use the prefixes you use internally, etc.. You wouldn't allow all of ipv6 space to get access.
"2001:2000:9000:3000::/64 can access it, someone from my ISP could just use one of the addresses to access my internal service from outside my lan. Right?"
No - how exactly would they do that??
Let me make a practical example:
My lan is 2001:2000:9000:3000::/64
I have an apache webserver that has multiple vhosts.Here I control my lights, and this should be accessible only from my LOCAL network:
<virtualhost *:80="">ServerName lights.myhome.com <location>Require ip 127.0.0.1 Require ip 192.168.1.0/16 Require ip 2001:2000:9000:3000::/64</location></virtualhost>This is my website, and it should be accessible from EVERYWHERE:
<virtualhost *:80="">ServerName myhome.com DocumentRoot /var/www</virtualhost>This server has IP 2001:2000:9000:3000::1. This server is on the internet, because he serves my homepage on myhome.com.
Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555 and sends an HTTP request for lights.myhome.com, he gets access to the interface. I could trust my ISP not to abuse the IPs he assigned to me, but I don't want to. With ULA addresses this problem does not exist, because I can change the Vhost configuration to something like
<virtualhost *:80="">ServerName lights.myhome.com <location>Require ip 127.0.0.1 Require ip 192.168.1.0/16 Require ip fdf5:2222:3333:4444::/64</location></virtualhost>Obviously I am missing something here. But what?
-
"Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555"
And how exactly are they going to do that? That /64 has been assigned to you.. They can not use it..
Lets say they could do it - which they can't… Why would you firewall allow this in from the internet?
-
And completely pointless… Zero reason to run ULA if your going to run global..
The IETF seems to think otherwise:
From https://tools.ietf.org/html/rfc4193.html section 4.6
- Nodes that can communicate with other nodes inside of the site
and outside of the site: These nodes should autoconfigure global
addresses via [ADDAUTO] or receive global address via [DHCP6].
They may also obtain Local IPv6 addresses via the same
mechanisms.
They must have thought there were valid reasons for having both. PfSense certainly has no problem providing both on an interface.
- Nodes that can communicate with other nodes inside of the site
-
Where do you read that? That does not say anything of the sort…
I can put rfc1918 and public on a box as well - doesn't mean you should...
You seem to think its ok to run multiple layer 3 on the same layer 2, which is exactly what that is.. Which is not the case, be it you can do it or not..
Who says those are the same interface? It could be a back lan, or a storage network..
If he wants to run ULA on a vlan interface, and Global on another vlan - sure ok... Pretty pointless but yeah you can do it..
I could for sure see it as storage network say.. This should be a different L2..
-
"Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555"
And how exactly are they going to do that? That /64 has been assigned to you.. They can not use it..
Lets say they could do it - which they can't… Why would you firewall allow this in from the internet?
Well it's "their" IPs, no? Why should they not be able to ip -6 addr add 2001:2000:9000:3000::5555/64 dev eth0 and be ready to go?
And I am allowing it from the internet because
"This server has IP 2001:2000:9000:3000::1. This server is on the internet, because he serves my homepage on myhome.com."
If I don't allow it from the internet myhome.com is down. -
"Well it's "their" IPs, no?"
No once the prefix has been assigned to you.. It is routed to you - they can not just use it..
If your allowing the whole internet into it.. The doesn't matter what IP they use they would be able to get to it… I think you think that a /64 is shared between all the users of the ISP or something. a prefix wold be assigned to your connection. Other users would not get that same prefix until your lease on it had expired. Same way they give you 1 IPv4, nobody else can use it - but it is theirs, etc.
-
If your allowing the whole internet into it.. The doesn't matter what IP they use they would be able to get to it…
You don't understand. I allow the whole internet onto it ON HE FIREWALL, BUT the web server has access control on the IPs that access it.
-
You don't understand that is not secure!!!
But if that is what you want…What your worried about is spoofing the source IP. Which works on UDP.. But not really a viable 2 way communication method in TCP.
But if you have /64 assigned to you - nobody else is going to be able to use it.
What do you open to the public internet for any reason to access your iot stuff - no reason to do that.. Internet does not need access to this sort of stuff. If your out and about and you want access then vpn into your network to access.
-
You don't understand that is not secure!!!
Sure johnpoz, then tell me how it's done :)
I opened this thread to ask just that. -
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
-
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
-
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
-
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
-
@pox:
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
Then you have misconfigured your webserver to allow access to those sites from the internet.
-
@kpa:
@pox:
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
Then you have misconfigured your webserver to allow access to those sites from the internet.
Maybe. Do you think you have the skills to tell me how to do it in a secure fashion, instead of answering with snarky one-liners that don't help anyone?
-
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
This is one of the problems with NAT. People are so convinced it provides security, they forget how firewalls actually work. There is nothing NAT can do that a properly configured firewall can't.
-
Maybe. Do you think you have the skills to tell me how to do it in a secure fashion, instead of answering with snarky one-liners that don't help anyone?
It does not matter if you are passing traffic to the post-NAT address or a public (IPv6 or IPv4) address.
NAT adds no security. It only adds complexity.
The problem is that you are passing the traffic. So don't do that.
the webserver hosts lights.myhome.com and myhome.com.
Do these resolve to the same address? If so there is no way for the firewall to know what to pass and what not to pass and the decision to serve or not has to be done in the web server (unless you get into something like HAproxy). If not, then block one and pass the other.
