6 ms·

Let's suppose the following network configuration: Host A Address1 "Global:Address:A" Address2 "Local:Address:A" Host B Address1 "Global:Address:B"

by yesco 3y ago

Let's suppose the following network configuration: Host A Address1 "Global:Address:A" Address2 "Local:Address:A" Host B Address1 "Global:Address:B" Address2 "Local:Address:B" If you are Host A and want to connect to Host B, while simultaneously ensuring that your connection to host B is done over your local network; Then you would initiate this connection using "Local:Address:B"; and since it's prefix ("Local") matches the prefix of one of your addresses:"Local:Address:A", then your OS would automatically use that as it's source address. Now if Host A connected to Host B via it's global address "Global:Address:B", then it would also work, but then Host A's connection would look like any other Internet address (and would still technically be routed over the internal network since it's the shortest path). The router/firewall, which would sit in front of these two hosts, would still see this all as local traffic though, and in the vast majority of cases be configured by default to block all incoming traffic from outside the network. This means unless the firewall is configured to allow some kind of external connection into Host B, and Host B does not initiate the connection itself, then it would never actually see any global addresses from anything other than Host A. > And how portable is this mechanism across different systems? It's all about what address you use, so I could say portability would be limited to IPv6 support, but broadly speaking everything I've described here also applies to NAT-less IPv4 too, which is how most cloud VM networks are usually configured. Having both Local and Global addresses can be convenient in cases where you have multiple environments (ie: dev,stage,prod), since you can reuse most configurations referenceing internal system IP addresses.

LegionMammal978 3y ago
> Then you would initiate this connection using "Local:Address:B"; and since it's prefix ("Local") matches the prefix of one of your addresses:"Local:Address:A", then your OS would automatically use that as it's source address. This is the step that I'm particularly concerned about. Suppose that I have a Host B on my network, and I want to totally ensure that it has nothing to do with the global Internet, so I assign it only a local address and no global address. Then, I set up a local DNS service in my network, so that any host can ask for "Host.B" and get "Local:Address:B" back. The problem is, will every kind of Host A, no matter what kind of embedded or IoT or corporate nonsense it's running, be able to properly manage both its local and global source addresses, and select its local address when it wants to connect to "Host.B"? This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections.
- yesco 3y ago
  With even just IPv4 you can have multiple IP addresses assigned to one NIC, the one used will be determined based on your destination. This is a part of the protocol, having a local address and a global address was expected from the very begining with IPv4 (well more like having multiple IP addresses was expected), NAT was made as a bandaid to fix the fact that there weren't enough addresses to support this. Pretty much any VM you make in the cloud will actually follow this traditional model by default with each VM having it's own local and global IPv4 addresses at the same time. It's nothing special, you can expect every NIC to support this, this is basic stuff, you can expect it to work on everything every time. Fundamentally all NAT does is simulate this kind of traditional network. It's an attempt to replicate this behavior by having all hosts "share" a global IP address that the router would then dynamically redirect back and forth based on which local host initiated the connection. However the packets must physically pass through your firewall to get into your network. The IP addresses are simply an identifier to put onto the envelope, a firewall does not give a fuck about what the envelope says if a remote host attempts to initiate an inbound connection and this is forbidden (which it always is by default). Before a packet from the Internet even gets an opportunity to even get to the NAT part it is trashed. The firewall is the security guard at the door checking your badge, after that you go to the reception who "routes" you to the correct host. If an address isn't routable, which may be the case in a NAT network, then it's no big deal since you can just threaten the receptionist to tell you where to go All NAT routers with Internet access will have both a local address and a global address natively, that's how it is even capable of sharing it's Global addresses in the first place, the firewall is what protects it, not NAT. If something can magically get past your firewall then that implies they have full control of your router now and can route packets wherever they like, remember this is hypothetical because breaking past a firewall is already a complete system failure, the boat has already sunk. At the end of the day it's all the same firmware, why would you trust the NAT part more than the Firewall part? It's literally just semantics. > This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections. I'm reiterating here but everything I've described so far is in relation to IPv4, all IPv6 introduces to the equation is: more addresses so you don't need NAT, a clever way to do dhcp on a local host without router intervention: SLAAC (routers can still advertise what to use as prefixes to these addresses). It also fuses together some of IPv4's extensions into one cohesive protocol that's simpler to understand. It's not nearly as radical as you may believe, it simply brings things back to how they were when IPv4 addresses were abundant and simplifies your firewall since you can easily configure which traffic can go to which host without involving weird port forwarding shenanigans. Attachment to NAT for security is fundamentally a misunderstanding of what role it is serving, an assumption that it has more responsibilities than it actually does. It is not DHCP, it is not a Firewall. If you want to expose a local host to the Internet with NAT you configure the firewall to "forward the port" so inbound connections get redirected to your designated local host. If you want to expose a NAT-less local host to the Internet, you go to the firewall configure it to allow inbound connections with destinations set to your local host's global IP address and it's port. FYI if you want you can have a static global address only used for inbound connections in addition to randomized globals for outbound connections. Though generally if you are setting up a server anonymous outbound connections are kinda pointless imo.

by yesco 3y ago

LegionMammal978 3y ago

> Then you would initiate this connection using "Local:Address:B"; and since it's prefix ("Local") matches the prefix of one of your addresses:"Local:Address:A", then your OS would automatically use that as it's source address. This is the step that I'm particularly concerned about. Suppose that I have a Host B on my network, and I want to totally ensure that it has nothing to do with the global Internet, so I assign it only a local address and no global address. Then, I set up a local DNS service in my network, so that any host can ask for "Host.B" and get "Local:Address:B" back. The problem is, will every kind of Host A, no matter what kind of embedded or IoT or corporate nonsense it's running, be able to properly manage both its local and global source addresses, and select its local address when it wants to connect to "Host.B"? This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections.

yesco 3y ago
With even just IPv4 you can have multiple IP addresses assigned to one NIC, the one used will be determined based on your destination. This is a part of the protocol, having a local address and a global address was expected from the very begining with IPv4 (well more like having multiple IP addresses was expected), NAT was made as a bandaid to fix the fact that there weren't enough addresses to support this. Pretty much any VM you make in the cloud will actually follow this traditional model by default with each VM having it's own local and global IPv4 addresses at the same time. It's nothing special, you can expect every NIC to support this, this is basic stuff, you can expect it to work on everything every time. Fundamentally all NAT does is simulate this kind of traditional network. It's an attempt to replicate this behavior by having all hosts "share" a global IP address that the router would then dynamically redirect back and forth based on which local host initiated the connection. However the packets must physically pass through your firewall to get into your network. The IP addresses are simply an identifier to put onto the envelope, a firewall does not give a fuck about what the envelope says if a remote host attempts to initiate an inbound connection and this is forbidden (which it always is by default). Before a packet from the Internet even gets an opportunity to even get to the NAT part it is trashed. The firewall is the security guard at the door checking your badge, after that you go to the reception who "routes" you to the correct host. If an address isn't routable, which may be the case in a NAT network, then it's no big deal since you can just threaten the receptionist to tell you where to go All NAT routers with Internet access will have both a local address and a global address natively, that's how it is even capable of sharing it's Global addresses in the first place, the firewall is what protects it, not NAT. If something can magically get past your firewall then that implies they have full control of your router now and can route packets wherever they like, remember this is hypothetical because breaking past a firewall is already a complete system failure, the boat has already sunk. At the end of the day it's all the same firmware, why would you trust the NAT part more than the Firewall part? It's literally just semantics. > This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections. I'm reiterating here but everything I've described so far is in relation to IPv4, all IPv6 introduces to the equation is: more addresses so you don't need NAT, a clever way to do dhcp on a local host without router intervention: SLAAC (routers can still advertise what to use as prefixes to these addresses). It also fuses together some of IPv4's extensions into one cohesive protocol that's simpler to understand. It's not nearly as radical as you may believe, it simply brings things back to how they were when IPv4 addresses were abundant and simplifies your firewall since you can easily configure which traffic can go to which host without involving weird port forwarding shenanigans. Attachment to NAT for security is fundamentally a misunderstanding of what role it is serving, an assumption that it has more responsibilities than it actually does. It is not DHCP, it is not a Firewall. If you want to expose a local host to the Internet with NAT you configure the firewall to "forward the port" so inbound connections get redirected to your designated local host. If you want to expose a NAT-less local host to the Internet, you go to the firewall configure it to allow inbound connections with destinations set to your local host's global IP address and it's port. FYI if you want you can have a static global address only used for inbound connections in addition to randomized globals for outbound connections. Though generally if you are setting up a server anonymous outbound connections are kinda pointless imo.