7 ms·

No, it doesn't. NAT does not prevent inbound connections, only a stateful firewall does, and if you do have that, then NAT does not add anything.

samoa42 7y ago
nat ist stateful. if there is no state for the connection, it's probably denied.
- zAy0LfpBZLC8mAC 7y ago
  No, it isn't, on both counts. First, NAT is not necessarily stateful, just the common home router PAT or the telco CGNAT varieties of NAT are. Second, NAT does not filter, that is what a firewall does. NAT only rewrites addresses. If there is no state for a connection in a stateful NAT, it looks up whether there are any rules for how to rewrite that connection, then adds a NAT state entry that specifies how to rewrite that connection (including, potentially, not at all), and in any case the (potentially rewritten) then gets forwarded--unless a firewall drops it.
jfindley 7y ago
So how are you, with your publically routed IP of (for example) 56.10.10.100 planning to connect to the GP, who has (for example) a public egress IP of 73.100.100.10, but is in fact using NAT, and his desktop's real IP is 192.168.1.20? I feel like you might be trying to point out that NAT devices can be configured to forward all traffic to some backend device - while true this is disingenous because they are basically always not configured like this. I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely. I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine.
- zAy0LfpBZLC8mAC 7y ago
  > So how are you, with your publically routed IP of (for example) 56.10.10.100 planning to connect to the GP, who has (for example) a public egress IP of 73.100.100.10, but is in fact using NAT, and his desktop's real IP is 192.168.1.20? By sending a packet to them that has the destination address 192.168.1.20? You seem to be making the assumption that the only way to send a packet to the WAN interface of a NAT router is through the public internet. While being able to do that widens the attack surface, it absolutely is not the only way, and your threat model is broken if you assume that it is. > I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely. No, that belief is one of the big myths that keeps people configuring insecure networks. > I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine. That's true and it's not. Of course, you can block all connections with a stateless firewall, and thus obviously also block all inbound connections. But a stateless firewall is very limited in selectively blocking specifically inbound connections across random protocols, and especially so if it doesn't know detailed information about your network and services to infer what constitutes a packet establishing a connection, while with a stateful firewall you can essentially just say "drop inbound connections" without any further details about your networks, and it'll do a good job at it. Plus, you could argue about whether, for example, dropping TCP SYNs but forwarding all other TCP packets actually counts as "blocking inbound connections", given that tons of potential "inbound packets" will be forwarded to your internal systems and you really rely on your internal systems not accepting any of them as "establishing a connection" or possibly just being vulnerable to those "inbound but not establishing a connection" sort of packets.
  - jfindley 7y ago
    Perhaps you could expand on the threat model you're talking about where you, as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent to the WAN port of your intended victims home router. It's perhaps worth pointing out that this discussion is very much in the context of a home network, so well-actually arguments about "maybe I have a GRE tunnel set up to this random users home router" or "maybe I'm their ISP and want to break into the router I supplied them with" won't really carry much weight - you mentioned the concept of a broken threat-model, but a threat model needs to be grounded in reality, and the reality is that unless you go far out of your way to do silly things NAT is a reasonable and practical protection for home users against accidentally exposing services on their network to the internet at large.
- oarsinsync 7y ago
  It's less of a 'networking purist', and more of a 'order of events' thing. If I send a packet from SRCIP1:SRCPORT1 to DESTIP1:DESTPORT1, and his real desktop IP is DESTIP2, the first event to occur is the stateful firewall checks if there's a session that exists between SRCIP1:SRCPORT1 and DESTIP1:DESTPORT1. If the session does not exist, the firewall drops the connection. If the session does exist, the next step is to hit the NAT table, to look up what to translate, for session SRCIP1,SRCPORT1,DESTIP1,DESTPORT1 into SRCIP2,SRCPORT2,DESTIP2,DESTPORT2. Note that it's possible that source ip, source port, destination port may not change in this scenario, where there's an RFC1918 DESTIP2. It depends on the NAT configuration. So again, strictly speaking, NAT does not prevent the connection. The stateful firewall does. NAT does not protect you, the firewall does. "Old fashioned stateless firewalls" are also not widely deployed on consumer grade CPEs.
  - jfindley 7y ago
    That only allows you to send replies along an existing TCP stream. In order to exploit this to compromise some home desktop, you first must persaude them to connect to you. Except... Oops! You now aren't bypassing NAT at all, you're just yet another malicious host that you tricked the user into connecting to. Every argument I've heard against NAT being an effective practical mitigation for home users runs smack into the problem of being a oh-well-actually scenario that's fantastically contrived and doesn't represent a realistic threat model for the average home user.
    - oarsinsync 7y ago
      I'm not talking about threat models or exploits, I'm talking about the order of events, how most consumer grade CPEs actually work. For an inbound connection again, there is a packet filter first, that will permit inbound connections based on whatever filter parameters are defined (usually matching established sessions, or new sessions filtered by just protocol and dport), and if that clears, the second step is NAT. In both cases, the filter happens before the translation.
    - 411111111111111 7y ago
      Its just basically impossible to get a consumer grade nat without an inbuilt stateful firewall. He's correct that the NAT doesn't stop the connection, but the stateful firewall is another service on the same device so you will never really notice the difference With the theoretical situation of a NAT without a firewall a connection is technically possible, as long as you are able to inspect any previously sent TCP packets and use the sender bits to route your new packets

samoa42 7y ago

nat ist stateful. if there is no state for the connection, it's probably denied.

zAy0LfpBZLC8mAC 7y ago
No, it isn't, on both counts. First, NAT is not necessarily stateful, just the common home router PAT or the telco CGNAT varieties of NAT are. Second, NAT does not filter, that is what a firewall does. NAT only rewrites addresses. If there is no state for a connection in a stateful NAT, it looks up whether there are any rules for how to rewrite that connection, then adds a NAT state entry that specifies how to rewrite that connection (including, potentially, not at all), and in any case the (potentially rewritten) then gets forwarded--unless a firewall drops it.

jfindley 7y ago

So how are you, with your publically routed IP of (for example) 56.10.10.100 planning to connect to the GP, who has (for example) a public egress IP of 73.100.100.10, but is in fact using NAT, and his desktop's real IP is 192.168.1.20? I feel like you might be trying to point out that NAT devices can be configured to forward all traffic to some backend device - while true this is disingenous because they are basically always not configured like this. I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely. I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine.

zAy0LfpBZLC8mAC 7y ago
> So how are you, with your publically routed IP of (for example) 56.10.10.100 planning to connect to the GP, who has (for example) a public egress IP of 73.100.100.10, but is in fact using NAT, and his desktop's real IP is 192.168.1.20? By sending a packet to them that has the destination address 192.168.1.20? You seem to be making the assumption that the only way to send a packet to the WAN interface of a NAT router is through the public internet. While being able to do that widens the attack surface, it absolutely is not the only way, and your threat model is broken if you assume that it is. > I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely. No, that belief is one of the big myths that keeps people configuring insecure networks. > I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine. That's true and it's not. Of course, you can block all connections with a stateless firewall, and thus obviously also block all inbound connections. But a stateless firewall is very limited in selectively blocking specifically inbound connections across random protocols, and especially so if it doesn't know detailed information about your network and services to infer what constitutes a packet establishing a connection, while with a stateful firewall you can essentially just say "drop inbound connections" without any further details about your networks, and it'll do a good job at it. Plus, you could argue about whether, for example, dropping TCP SYNs but forwarding all other TCP packets actually counts as "blocking inbound connections", given that tons of potential "inbound packets" will be forwarded to your internal systems and you really rely on your internal systems not accepting any of them as "establishing a connection" or possibly just being vulnerable to those "inbound but not establishing a connection" sort of packets.
- jfindley 7y ago
  Perhaps you could expand on the threat model you're talking about where you, as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent to the WAN port of your intended victims home router. It's perhaps worth pointing out that this discussion is very much in the context of a home network, so well-actually arguments about "maybe I have a GRE tunnel set up to this random users home router" or "maybe I'm their ISP and want to break into the router I supplied them with" won't really carry much weight - you mentioned the concept of a broken threat-model, but a threat model needs to be grounded in reality, and the reality is that unless you go far out of your way to do silly things NAT is a reasonable and practical protection for home users against accidentally exposing services on their network to the internet at large.
oarsinsync 7y ago
It's less of a 'networking purist', and more of a 'order of events' thing. If I send a packet from SRCIP1:SRCPORT1 to DESTIP1:DESTPORT1, and his real desktop IP is DESTIP2, the first event to occur is the stateful firewall checks if there's a session that exists between SRCIP1:SRCPORT1 and DESTIP1:DESTPORT1. If the session does not exist, the firewall drops the connection. If the session does exist, the next step is to hit the NAT table, to look up what to translate, for session SRCIP1,SRCPORT1,DESTIP1,DESTPORT1 into SRCIP2,SRCPORT2,DESTIP2,DESTPORT2. Note that it's possible that source ip, source port, destination port may not change in this scenario, where there's an RFC1918 DESTIP2. It depends on the NAT configuration. So again, strictly speaking, NAT does not prevent the connection. The stateful firewall does. NAT does not protect you, the firewall does. "Old fashioned stateless firewalls" are also not widely deployed on consumer grade CPEs.
- jfindley 7y ago
  That only allows you to send replies along an existing TCP stream. In order to exploit this to compromise some home desktop, you first must persaude them to connect to you. Except... Oops! You now aren't bypassing NAT at all, you're just yet another malicious host that you tricked the user into connecting to. Every argument I've heard against NAT being an effective practical mitigation for home users runs smack into the problem of being a oh-well-actually scenario that's fantastically contrived and doesn't represent a realistic threat model for the average home user.
  - oarsinsync 7y ago
    I'm not talking about threat models or exploits, I'm talking about the order of events, how most consumer grade CPEs actually work. For an inbound connection again, there is a packet filter first, that will permit inbound connections based on whatever filter parameters are defined (usually matching established sessions, or new sessions filtered by just protocol and dport), and if that clears, the second step is NAT. In both cases, the filter happens before the translation.
  - 411111111111111 7y ago
    Its just basically impossible to get a consumer grade nat without an inbuilt stateful firewall. He's correct that the NAT doesn't stop the connection, but the stateful firewall is another service on the same device so you will never really notice the difference With the theoretical situation of a NAT without a firewall a connection is technically possible, as long as you are able to inspect any previously sent TCP packets and use the sender bits to route your new packets