Hi, Condointernet/WaveG/Astound user. I've used their network before, and from experience, they put you on the same L2 segment as your neighbors. There's ARP/DHCP/etc filtering in place on the switch to prevent most kinds of shenanigans, but your neighbors can still send packets with a RFC1918 dst IP to your Ethernet address.

To ping your internal hosts, I'd need to gain access to your building or one sharing the same L2 segment ("dfsea"?), then configure a static route for 10/8 / 192.168/16 / etc pointing at you. I would not need any control over the ISP.

I'm on a business line, and the L2 Ethernet segment consists of 1 device, their router.

And most of Wave users (or any broadband users in the US, for that matter) use DOCSIS, which does not have a shared L2.

That's fantastic for you, and for DOCSIS users (setting aside DOCSIS' other pain points), but your neighbors on residential Ethernet-based plans do not enjoy the supposed security benefits of NAT that you claimed upthread.

You can't do it in practice because everybody has firewalls, and also widespread use of RFC1918 in v4 makes it hard to even send the right packets to the right place. I wasn't arguing that; my point was just that NAT won't stop any inbound connection, and if your inbound connections are being stopped by something... then the something isn't NAT.

> OK. How can I ping your address? It should be easy, right? I'll even give you my IP: 208.52.76.162 , what do I need to set up to be able to ping all your internal hosts?

> Let's make that experiment.

Sure. Since I'm using RFC1918 on the inside you'll need to be on my immediate upstream segment to test this, so I set up a gre tunnel for you. If you're on Linux you can run something like this (otherwise I'll leave it up to you to map the tunnel setup to whatever you're using):

  $ ip netns add temp
  $ ip link add gretap type gretap local 208.52.76.162 remote 151.115.75.246
  $ ip link set netns temp gretap
  $ ip netns exec temp "$SHELL"
  (inside netns)$ ip link set up dev gretap
  (inside netns)$ ip addr add 203.0.113.150/24 dev gretap

That will put you on my upstream segment, outside of my NATed network, using 203.0.113.150. Then just do this:

  (inside netns)$ ip route add 192.168.0.0/24 via 203.0.113.58
  (inside netns)$ ping 192.168.0.101

> I wasn't arguing that; my point was just that NAT won't stop any inbound connection, and if your inbound connections are being stopped by something... then the something isn't NAT.

NAT _will_ stop inbound connections in practice, unless you control the ISP. So in practice NAT provides more than enough security for typical SOHO users.

> Sure. Since I'm using RFC1918 on the inside you'll need to be on my immediate upstream segment to test this

Exactly. Which means that you need (in practice) to control the ISP for this attack to work.

No, it won't. All that's needed is an inbound route to your router, and NAT can't prevent that route from existing. It doesn't matter if you have ISP control or not.

I'm not seeing any gre packets from you. Are you having trouble getting the tunnel working?

...are you going to do this experiment or not? I've got the whole setup just waiting for you.