4 ms·

The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.

hot_gril 3y ago
NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.
- bigstrat2003 3y ago
  > NAT is a more desirable form of security than a firewall for most users... I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding). NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
  - hot_gril 3y ago
    It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults. My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Speed/IPv6-firewall-on-Fios-router-is-allowing-inbound-connections/td-p/1573464 https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
    - snuxoll 3y ago
      > My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network. NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
      - hot_gril 3y ago
        NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident. > IPv6 just exposes such poor configurations more readily. Yes, that's the exact dealbreaker for me and many corp environments.
        snuxoll 3y ago
        > If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 1.1.1.1 1 DAc 1.1.1.0/24 wan1 0 DAc 192.168.0.0/24 lan1 0 Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule. > Yes, that's the exact dealbreaker for me and many corp environments. My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.

hot_gril 3y ago

NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.

bigstrat2003 3y ago
> NAT is a more desirable form of security than a firewall for most users... I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding). NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
- hot_gril 3y ago
  It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults. My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Speed/IPv6-firewall-on-Fios-router-is-allowing-inbound-connections/td-p/1573464 https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
  - snuxoll 3y ago
    > My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network. NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
    - hot_gril 3y ago
      NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident. > IPv6 just exposes such poor configurations more readily. Yes, that's the exact dealbreaker for me and many corp environments.
      - snuxoll 3y ago
        > If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 1.1.1.1 1 DAc 1.1.1.0/24 wan1 0 DAc 192.168.0.0/24 lan1 0 Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule. > Yes, that's the exact dealbreaker for me and many corp environments. My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.