Does NPt make my internal network more secure?
-
"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.
-
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.
At the moment they resolve to the same address. 192.168.0.1, or 2001:2000:9000:3000::1. So if the firewall can't take the decision, and the webserver can't take the decision, who does?
-
The web server does. Use access lists there.
-
The web server does. Use access lists there.
How? And here I come back to my original question: say my ISP gave me 2001:2000:9000::/48. Clients on my lan who should be able to access 2001:2000:9000:3000::1 (the web server) are in 2001:2000:9000:1::/64.
I can tell the webserver that he should accept connections for lights.myhome.com only from addresses that are in 2001:2000:9000:1::/64.
What is preventing someone working at my ISP doing
ip -6 addr add 2001:2000:9000:1::5555/64 dev eth0
and getting access to my lights? -
What the actual fuck, dude. Source addresses mean nothing. You either pass the traffic into WAN from any or you don't.
If you do not want traffic ingressing into your network from addresses that should only originate from inside then block them. Pretty sure there are already anti-spoofing rules that do that but if it makes you feel better, then explicitly block the traffic.
You are not making a whole lot of sense.
Clients on your LAN and clients out on WAN are two completely different things. Governed by Layer 2 in the first case and firewall rules on WAN in the second case.
