3 ms·

How interesting. So tell me, how do you craft an inbound connection to an arbitrary port on an arbitrary device that is behind NAT?

Dagger2 6y ago
`telnet <IP of destination device> <port>` will do the job.
- sjwright 6y ago
  Okay then, the IP is 10.1.5.12 and the port is 80. Go for it. Do you even know what NAT is?
  - Dagger2 6y ago
    That's an RFC1918 IP. I'm not going to be able to reach it from here. So long as you aren't also running a firewall, your ISP or anyone on your immediate upstream network could reach it just fine though. If you get me access to that network then I'd be happy to demonstrate. Yes, I know what NAT is.
    - sjwright 6y ago
      You think my ISP can reach my local network “just fine”? Yeah, that’s completely wrong and absurd. I’m pretty sure you don’t know what NAT means.
      - Dagger2 6y ago
        It means the rewriting of the apparent source address of outbound connections, yes? On Linux, you would do it with `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. Is that an accurate enough description to convince you that I know what NAT means? "Rewriting the apparent source address of outbound connections" means that it's an operation you apply to outbound connections. Inbound connections are completely unaffected. This is made even more obvious by the `iptables` command above: it explicitly says "-o wan0", which restricts the rule to applying only to connections going out of wan0, not to ones coming in from it. So yes, your ISP (or rather, anyone on the immediate upstream network, which is typically the ISP) can connect to your 10.1.5.12 -- that's just basic routing -- and NAT won't stop them because NAT doesn't do anything to inbound connections.
        sjwright 6y ago
        Ah, you seem to be under the misapprehension that consumer NAT devices act as BGP routers. No, in all normal configurations the “WAN” port listens on one IP only. Any traffic bound for a private/bogon range—even if it matches your internal range is discarded, not routed or forwarded. This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first. But even if that were true, it would be a mere technicality that doesn’t refute the point made ten or so posts ago. NAT does remain an imperfect yet semi-functional pseudo-firewall for stray inbound connections from the Internet at large.
        Dagger2 6y ago
        I don't think they act as BGP routers. They do act as regular routers though, and will accept and forward traffic for any range unless they have a firewall rejecting it. > This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first. I've done this test before, as I mentioned. But okay, since I can be wrong and you seem confidant that I am, I'll do it again. I just plugged a NAT router into my internal network, and attached my laptop behind it. The router got 172.16.1.130/24 as its WAN address, and is using 192.168.3.1/24 on the LAN side. My laptop got 192.168.3.158. I disabled the firewall on the router, since we both know that a firewall definitely will drop an inbound connection. On my desktop, connected to the main network, I ran `ip route add 192.168.3.0/24 via 172.16.1.130` to get the routing to work, and then I did this: # telnet 192.168.3.158 22 Trying 192.168.3.158... Connected to 192.168.3.158. Escape character is '^]'. SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 I verified with `tcpdump` on my desktop that outbound connections from the laptop are being NATed to appear to come from 172.16.1.130, and yet I can still telnet into the laptop from the desktop. This appears to contradict your assertion that this traffic will be discarded, and it exactly matches my own assertion that someone on your immediate upstream network can connect inwards over NAT. This is the same result I got the last time I tested this. So... can you explain what's going on? Because your trivial test seems to back me up here. If NAT was an imperfect yet semi-functional pseudo-firewall, why isn't it doing something here?

Dagger2 6y ago

`telnet <IP of destination device> <port>` will do the job.

sjwright 6y ago
Okay then, the IP is 10.1.5.12 and the port is 80. Go for it. Do you even know what NAT is?
- Dagger2 6y ago
  That's an RFC1918 IP. I'm not going to be able to reach it from here. So long as you aren't also running a firewall, your ISP or anyone on your immediate upstream network could reach it just fine though. If you get me access to that network then I'd be happy to demonstrate. Yes, I know what NAT is.
  - sjwright 6y ago
    You think my ISP can reach my local network “just fine”? Yeah, that’s completely wrong and absurd. I’m pretty sure you don’t know what NAT means.
    - Dagger2 6y ago
      It means the rewriting of the apparent source address of outbound connections, yes? On Linux, you would do it with `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. Is that an accurate enough description to convince you that I know what NAT means? "Rewriting the apparent source address of outbound connections" means that it's an operation you apply to outbound connections. Inbound connections are completely unaffected. This is made even more obvious by the `iptables` command above: it explicitly says "-o wan0", which restricts the rule to applying only to connections going out of wan0, not to ones coming in from it. So yes, your ISP (or rather, anyone on the immediate upstream network, which is typically the ISP) can connect to your 10.1.5.12 -- that's just basic routing -- and NAT won't stop them because NAT doesn't do anything to inbound connections.
      - sjwright 6y ago
        Ah, you seem to be under the misapprehension that consumer NAT devices act as BGP routers. No, in all normal configurations the “WAN” port listens on one IP only. Any traffic bound for a private/bogon range—even if it matches your internal range is discarded, not routed or forwarded. This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first. But even if that were true, it would be a mere technicality that doesn’t refute the point made ten or so posts ago. NAT does remain an imperfect yet semi-functional pseudo-firewall for stray inbound connections from the Internet at large.
        Dagger2 6y ago
        I don't think they act as BGP routers. They do act as regular routers though, and will accept and forward traffic for any range unless they have a firewall rejecting it. > This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first. I've done this test before, as I mentioned. But okay, since I can be wrong and you seem confidant that I am, I'll do it again. I just plugged a NAT router into my internal network, and attached my laptop behind it. The router got 172.16.1.130/24 as its WAN address, and is using 192.168.3.1/24 on the LAN side. My laptop got 192.168.3.158. I disabled the firewall on the router, since we both know that a firewall definitely will drop an inbound connection. On my desktop, connected to the main network, I ran `ip route add 192.168.3.0/24 via 172.16.1.130` to get the routing to work, and then I did this: # telnet 192.168.3.158 22 Trying 192.168.3.158... Connected to 192.168.3.158. Escape character is '^]'. SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 I verified with `tcpdump` on my desktop that outbound connections from the laptop are being NATed to appear to come from 172.16.1.130, and yet I can still telnet into the laptop from the desktop. This appears to contradict your assertion that this traffic will be discarded, and it exactly matches my own assertion that someone on your immediate upstream network can connect inwards over NAT. This is the same result I got the last time I tested this. So... can you explain what's going on? Because your trivial test seems to back me up here. If NAT was an imperfect yet semi-functional pseudo-firewall, why isn't it doing something here?