On 2/16/24 5:05 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too. Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address. For both you can have the default as "reject" or "accept" -- that's just a default and depends on how you want to manage your network. NAT is not without its own set of problems, so if this boils down to a subnet management issue there are obviously ways to deal with that to avoid NAT's problems. Both DHCP and firewall configs don't have to be the ultimate source of truth about any of this. And that's likely a Good Thing since you want them to be pretty much as fungible and replaceable as possible. If you're exposed to fat fingers for either, you're probably already in trouble. Something in the management plain is far more likely to care about this kind of thing than hardware vendors who see that as a cost center with predictably shitty implementations. Mike