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

Pwnat – Autonomous Nat Traversal (2010)

samy.pl

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Pwnat – Autonomous Nat Traversal (2010)

#31

Post by AnIdiotOnTheNet »

api wrote: post #30
AnIdiotOnTheNet wrote: post #29

Earlier quoted context omitted.

I'm not sure that wouldn't have happened anyway, just with firewalls. ISPs were not above port blocking regardless.

It's much easier to deal with port opening or changing than it is to deal with a fragmented address space. NAT reminds me of the networking analog of segmented addressing on 16 bit 8086 processors, but worse as it is not systematic.

Opening a port through NAT on your own setup is pretty much the same process as doing it on any firewall. I'm not sure how the address space being fragmented changes anything in this case, the user must poke a hole somewhere somehow.

Re: Pwnat – Autonomous Nat Traversal (2010)

#32

Post by toast0 »

mempko wrote: post #15
jgeralnik wrote: post #2

The really cool part about this is that the server does not need to know the client's ip address. Instead a new original form of ICMP hole punching is used to allow any client to punch the NAT so that the server can dynamically learn the client ip, and then regular UDP hole punching is used.

I'm sad that P2P never took off in the messaging world and now we are stuck with servers storing data even if it's E2E encrypted. I use NAT traversal for Firestr ( http://firestr.com ) back in 2013 though this is still cool because of the ICMP hole punching. I'll have to see if I can incorporate that.

P2P messaging is a hard sell, in my opinion for a couple of reasons:

P2P requires knowledge of the peer's IP, which can be unwelcome depending on the messaging partner (and it's hard to make a config for do you trust this person enough to see your IP: yes, no, only if I'm on network X, not if I'm on network Y, etc)

P2P requires both nodes to be online simultaneously, so it's difficult to make work well for asynchronous messaging with smart phones or mobile laptops or desktops that are regularly turned off. Maybe you remember how Skype used to be?

So, I think you definitely want a server based store and forward messaging path to ensure delivery and for (optional) privacy from peers, and adding an optional P2P path is additional work, without a lot of gain; at least if it's text. When you start sending media, the bandwidth/storage savings from going P2P make it worth exploring.

Re: Pwnat – Autonomous Nat Traversal (2010)

#33

Post by adev_ »

AnIdiotOnTheNet wrote: post #26
api wrote: post #23

Earlier quoted context omitted.

NAT is an ugly hack to extend IPv4 address space that breaks the internet. There are numerous ugly hacks for NAT traversal to fix what NAT breaks, all of which kind of seem like exploits, and some of which are effectively standardized in RFCs and used heavily for things like VoIP. The whole thing is a hideous mess that IPv6 will hopefully eventually kill.

> NAT is an ugly hack to extend IPv4 address space that breaks the internet Or to phrase it more generously, NAT is an ugly but simple hack that allowed the internet grow despite limited address space and without a gigantic investment in hardware to support an over-engineered replacement protocol.

> without a gigantic investment in hardware to support an over-engineered replacement protocol.

Bullshit.

Almost every piece of hardware sold since 15 years is compatible IPv6. There is no need of any "expensive hardware".

The main reason that IPV6 never lift off is the lack of interest, lazyness and no will for configuration.

Re: Pwnat – Autonomous Nat Traversal (2010)

#34

Post by api »

AnIdiotOnTheNet wrote: post #31
api wrote: post #30

Earlier quoted context omitted.

It's much easier to deal with port opening or changing than it is to deal with a fragmented address space. NAT reminds me of the networking analog of segmented addressing on 16 bit 8086 processors, but worse as it is not systematic.

Opening a port through NAT on your own setup is pretty much the same process as doing it on any firewall. I'm not sure how the address space being fragmented changes anything in this case, the user must poke a hole somewhere somehow.

Try writing P2P software and you'll see it. NAT is like 16-bit segmented addressing. Go find some old 16-bit C programs and see what a "near" vs "far" pointer is and that whole mess. IPv6 is like the arrival of 32-bit real mode addressing with the 80386.

Re: Pwnat – Autonomous Nat Traversal (2010)

#35

Post by testvox »

armitron wrote: post #24

This is old technique from early 2000 and flawed as others have described. Outgoing ICMP is blocked in every corporate environment I have ever been to and never makes it to the Internet facing gateway.

I'm on a large corporate network right now and I get responses back from `ping www.google.com`.

But also this technique doesn't depend on ICMP that is just what the example happens to use. Pwnat itself uses only UDP for outgoing requests.

Re: Pwnat – Autonomous Nat Traversal (2010)

#36

Post by big_chungus »

jlg23 wrote: post #25
big_chungus wrote: post #18

Earlier quoted context omitted.

And of course, with the advent of DNS over HTTPS, this is no longer as effective. I can still access blocked sites and get around logging, I just have to set up a tunnel to cloudflare.

Which, from a security point of view, would be grounds for immediate termination and quite some companies I worked for would try to sue you to pay for impact assessment. (connecting a usb-modem is much safer, I'd have to actually spot the device which would require getting out of my chair... ;)

The point is not really for me to circumvent restrictions, it's more that a bad actor could. This can largely defeat the purpose; though malware using this is not common, it's started to crop up.

Re: Pwnat – Autonomous Nat Traversal (2010)

#37

Post by AnIdiotOnTheNet »

api wrote: post #34
AnIdiotOnTheNet wrote: post #31

Earlier quoted context omitted.

Opening a port through NAT on your own setup is pretty much the same process as doing it on any firewall. I'm not sure how the address space being fragmented changes anything in this case, the user must poke a hole somewhere somehow.

Try writing P2P software and you'll see it. NAT is like 16-bit segmented addressing. Go find some old 16-bit C programs and see what a "near" vs "far" pointer is and that whole mess. IPv6 is like the arrival of 32-bit real mode addressing with the 80386.

P2P software wouldn't work too well without fiddling with the firewall anyway, is what I'm saying. I don't think circumstances would have changed much if we'd adopted IPv6 instead of NAT. P2P largely failed to take off outside of piracy circles because centralization is more reliable and efficient, that's all.

And yeah, I've dealt with segmented memory models, in C and ASM. I don't think the situation is very comparable at all, nor are segments as bad as people say, but that's neither here nor there. I mean, FFS, all modern systems use an MMU that remaps memory addresses between processes anyway.

Re: Pwnat – Autonomous Nat Traversal (2010)

#38

Post by AnIdiotOnTheNet »

adev_ wrote: post #33
AnIdiotOnTheNet wrote: post #26

Earlier quoted context omitted.

> NAT is an ugly hack to extend IPv4 address space that breaks the internet Or to phrase it more generously, NAT is an ugly but simple hack that allowed the internet grow despite limited address space and without a gigantic investment in hardware to support an over-engineered replacement protocol.

> without a gigantic investment in hardware to support an over-engineered replacement protocol. Bullshit. Almost every piece of hardware sold since 15 years is compatible IPv6. There is no need of any "expensive hardware". The main reason that IPV6 never lift off is the lack of interest, lazyness and no will for configuration.

NAT is older than 15 years though. And

> lack of interest, lazyness and no will for configuration

Is a symptom of v6 being over-engineered.

Re: Pwnat – Autonomous Nat Traversal (2010)

#39

Post by armitron »

testvox wrote: post #35
armitron wrote: post #24

This is old technique from early 2000 and flawed as others have described. Outgoing ICMP is blocked in every corporate environment I have ever been to and never makes it to the Internet facing gateway.

I'm on a large corporate network right now and I get responses back from `ping www.google.com`. But also this technique doesn't depend on ICMP that is just what the example happens to use. Pwnat itself uses only UDP for outgoing requests.

ICMP is used by the server in order to find out the IP of the client. Then they switch to UDP. This method does not work without ICMP. Now, of course you can use outgoing UDP in probe fashion instead of ICMP, but that's again most probably blocked.

Re: Pwnat – Autonomous Nat Traversal (2010)

#40

Post by ronsor »

AnIdiotOnTheNet wrote: post #38
adev_ wrote: post #33

Earlier quoted context omitted.

> without a gigantic investment in hardware to support an over-engineered replacement protocol. Bullshit. Almost every piece of hardware sold since 15 years is compatible IPv6. There is no need of any "expensive hardware". The main reason that IPV6 never lift off is the lack of interest, lazyness and no will for configuration.

NAT is older than 15 years though. And > lack of interest, lazyness and no will for configuration Is a symptom of v6 being over-engineered.

NAT is more over-engineered than IPv6. IPv6 is literally the same as IPv4 in most aspects. People are just lazy because NAT makes things "work" (if you can call it that).
Post reply on HN