Pwnat – Autonomous Nat Traversal (2010)
1–10 of 42 posts
Re: Pwnat – Autonomous Nat Traversal (2010)
#2The 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.
Re: Pwnat – Autonomous Nat Traversal (2010)
#3> This will work behind many NATs and firewalls, but not all.
While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices[1], which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings.
[1] These devices assign a different port for each destination address, and this ICMP method doesn't help predict the port that will be assigned.
Re: Pwnat – Autonomous Nat Traversal (2010)
#4> This will work behind many NATs and firewalls, but not all. While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices[1], which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings. [1] These devic…
As long as only one side of the connection is behind a corporate NAT you could simply try all 65535 ports until you find the one that works. The side behind the NAT would receive the packet and then be able to respond.
Re: Pwnat – Autonomous Nat Traversal (2010)
#5> This will work behind many NATs and firewalls, but not all. While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices[1], which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings. [1] These devic…
As long as only one side of the connection is behind a corporate NAT you could simply try all 65535 ports until you find the one that works. The side behind the NAT would receive the packet and then be able to respond.
And then you're blacklisted by the corporate firewall for doing what looks like port scanning.
Re: Pwnat – Autonomous Nat Traversal (2010)
#6I had a quick test, not working for me
many previous comments about this script
https://hn.algolia.com/?q=pwnat
Re: Pwnat – Autonomous Nat Traversal (2010)
#7I had a quick test, not working for me many previous comments about this script https://hn.algolia.com/?q=pwnat
ah, I've got it, it's a pretty old code :)
Re: Pwnat – Autonomous Nat Traversal (2010)
#8Earlier quoted context omitted.
As long as only one side of the connection is behind a corporate NAT you could simply try all 65535 ports until you find the one that works. The side behind the NAT would receive the packet and then be able to respond.
And then you're blacklisted by the corporate firewall for doing what looks like port scanning.
All 3 corporate firewalls I have been behind have been HTTP only. No actual internet connection. (Except for DNS, which worked.)
Re: Pwnat – Autonomous Nat Traversal (2010)
#9Earlier quoted context omitted.
And then you're blacklisted by the corporate firewall for doing what looks like port scanning.
All 3 corporate firewalls I have been behind have been HTTP only. No actual internet connection. (Except for DNS, which worked.)
DNS working in a corporate IT environment is a surprise. Often, clients are issued an internal DNS server via DHCP, and outbound DNS to arbitrary servers is blocked. This helps mitigate DNS hijacking and also allows some additional outbound domain filtering and logging.
Re: Pwnat – Autonomous Nat Traversal (2010)
#10Earlier quoted context omitted.
All 3 corporate firewalls I have been behind have been HTTP only. No actual internet connection. (Except for DNS, which worked.)
DNS working in a corporate IT environment is a surprise. Often, clients are issued an internal DNS server via DHCP, and outbound DNS to arbitrary servers is blocked. This helps mitigate DNS hijacking and also allows some additional outbound domain filtering and logging.
Oh, yes, DNS is an internal DNS. You can't change it. I meant, it's the only way to "trickle leak" data without it going through the filtering proxy. But who knows, maybe the DNS requests are logged too, but they don't seem to be filtered.
Edit: they are filtered. Suspicious names go to 127.0.0.1