Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How does Linux NAT a ping?

devnonsense.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: How does Linux NAT a ping?

#41

Post by mindslight »

zackmorris wrote: post #23

I wonder if ping could be abused to send short messages for p2p networking over UDP without a central server to handle NAT busting. Looks like someone figured the message part out: https://stackoverflow.com/questions/31857419/how-to-send-a-m... Unfortunately ping is handled by the OS so apps on the peer IPs wouldn't be able to read the messages. I wonder if it's time to provide hooks to some of these services in user…

Interesting idea. It would seem that 'id' is effectively equivalent of (sport, dport), but 16 bits is a much smaller space than 32.

But isn't the main problem with NAT punching that it requires activity on both ends to create a connection? Thus it always requires a coordination server to let node T (target) that node S (source) is trying to talk to it.

You've got me thinking though. I wonder if there is a way to do this with ICMP routing messages - unreachable, TTL expired, etc. You can traceroute to some IP address, and get back packets from other arbitrary IP addresses, and this generally works through NAT. I'm envisioning a host T that wanted incoming connections to pick a random "dummy" IP address , publish (router IP, dummy IP) as its identity, and periodically send packets to the dummy IP address. Now a host S that wants to talk to T might be able to send an ICMP TTL-expired to T's router, pertaining to the dummy address. The router should see this and forward the packet to T.

Of course this is contingent upon if IP addresses in ICMP fields are ingress policed the way the addresses in the IP header have become.

(edit: hah. There is now a top-level comment pointing to an implementation of this idea)

Re: How does Linux NAT a ping?

#42

Post by mindslight »

jandrese wrote: post #40
mindslight wrote: post #17

Earlier quoted context omitted.

Is there a better way to not unnecessarily leak addressing metadata to adversarial remote nodes and middle boxes? IPv6 with assigning end users a whole /64 and end-devices continually churning through privacy addresses is a start. But even then some form of NAT is still required to nimbly use source prefixes from different horizon providers - eg to avoid spilling your geographic location or opening yourself up to low…

Why not just use a VPN in both cases? That’s more or less what your NAT solution is doing, except without the encryption to the data center.

It is a wireguard tunnel to the data center, but my comment was focused on the addressing.

Re: How does Linux NAT a ping?

#43

Post by qhwudbebd »

noinsight wrote: post #29
midasuni wrote: post #11

Earlier quoted context omitted.

I have a few devices on my home internet, on a handful of 192.168 subnets The other week I moved my ISP. The AS my house belonged to obviously changed to the new ISP, and I got a new v4 IP All I had to do was update my Wan router to forward trafffic from the new Ip. Instead with ipv6 I would have to change every node on my network, update my internal DNS. Now in theory I could have my own /48 which I take with me. Th…

You could be using IPv6 ULA addresses internally on your home network to have static addressing. The real solution is moving to DNS names though with your router maintaining them based on DHCP leases or just using multicast DNS (Zeroconf). In the future you can probably go "IPv6-mostly" with a CLAT engine to ditch dual-stack: https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-acce...

> In the future you can probably go "IPv6-mostly" with a CLAT engine

...although there still isn't any kernel support for the necessary SIIT v4v6 translation, so to implement CLAT you end up using unmaintained (and unmergeably bad) out-of-tree kernel modules or unmaintained (and slow) userspace daemons hanging off a tuntap interface.

Re: How does Linux NAT a ping?

#44

Post by devman0 »

starfallg wrote: post #35
baq wrote: post #22

Earlier quoted context omitted.

Taking this thought just a tiny bit further, this is changing a stateless protocol to a stateful one.

Any NAT that is not statically mapping IP addresses or ports 1-to-1 will require connections to be tracked and hence makes it stateful on the side after the translation (usually outside). Hence you do need state syncing between firewalls in order for NAT connections to failover correctly, unless it's a statically mapped, one-on-one, one range onto another range, for example.

This isn't really specific to NAT either, connection tracking is required for most firewalls as well even if NAT isn't in play just to implement the most basic ALLOW related,estabalished rule even, and especially, what would normally be connectionless protocols.

Re: How does Linux NAT a ping?

#45

Post by littlecranky67 »

jjoonathan wrote: post #2

NAT is such a trashy abstraction. IPv4 needs to die.

Not sure IPv6 will fix this. Technically, yes it does. But major providers only assigning a /64 to a home user (and charging hefty fees for "buisness use" /48) already leads to IPv6 NAT or segmenting the /64 further - which shoulnt be done.

Re: How does Linux NAT a ping?

#46

Post by zinekeller »

jandrese wrote: post #37
freedomben wrote: post #31

Earlier quoted context omitted.

Minor technical correction, but ping is ICMP rather than UDP. But I have seen data exfiltration strategies and other communication that uses ping! Nowadays I think it would be nearly impossible for p2p because most firewall default configs will silently drop all ICMP, including pings.

Note that blanket dropping of ICMP will break Path MTU Discovery (PMTUD) so you had better not be tunneling or encapsulating TCP traffic.

Actually, ICMP-based PMTUD is almost dead in IPv4 due to this exact problem (since ICMP isn't a "protected" protocol which is required for IPv4 connectivity), most actual services tend to do the MTU discovery purely using UDP or even using TCP (https://datatracker.ietf.org/doc/html/rfc4821)

Re: How does Linux NAT a ping?

#47

Post by growse »

kazinator wrote: post #20
growse wrote: post #15

Earlier quoted context omitted.

> Many ISPs suck. That’s not controversial. > We have to deal with the world we live in, not the world we’d like. No we don't. Some choose to just put up with shittiness, others enact change.

OP here. Your "ISP" is a sysadmin at work who gives you one address to your cube. You otherwise like the work and the team, and the compensation is fine. Now what?

> Now what?

You advocate for change. You make the case.

You might not win the battle, but you're by no means forced to accept the status quo. The more who fight the battle, the more win. The more win, the faster progress, which benefits us all.

Re: How does Linux NAT a ping?

#48

Post by growse »

toast0 wrote: post #32
growse wrote: post #15

Earlier quoted context omitted.

> Many ISPs suck. That’s not controversial. > We have to deal with the world we live in, not the world we’d like. No we don't. Some choose to just put up with shittiness, others enact change.

Priorities. I don't have to put up with PPPoE in 2023, but it's a hell of a lot less expensive than pulling munifiber to my garage (and the monthly fees for munifiber are higher too, so there's no point in time where it makes economic sense), and consistency and stable addressing is currently winning over the promise of 5g/leo satellite.

Sure, but you're choosing that prioritisation. It's not being forced on you.

Re: How does Linux NAT a ping?

#49

Post by paulddraper »

kazinator wrote: post #5
jjoonathan wrote: post #2

NAT is such a trashy abstraction. IPv4 needs to die.

You need NAT (or something else that is worse in some respects, like port forwarding) in any situation in which your subnet is given only one address upstream, even if it is an IPv6 address.

Yeah, but there's no reason to do that with IPv6
Post reply on HN