all 63 comments

[–][deleted] ago*

sorry, this has been archived and can no longer be voted on

[deleted]

[–]thires 1 point2 points ago

sorry, this has been archived and can no longer be voted on

3.4 is more accurate in this context.

[–]sinotized 1 point2 points ago

sorry, this has been archived and can no longer be voted on

Section 3.4is the more common scenario.

[–]dhcernese 1 point2 points ago

sorry, this has been archived and can no longer be voted on

don't you mean 3.4?

[–][deleted] 1 point2 points ago

sorry, this has been archived and can no longer be voted on

Thank you kindly, I shall take a look at this later.

[–][deleted] 21 points22 points ago*

sorry, this has been archived and can no longer be voted on

UDP hole punching is actually easier to do because there aren't sequence IDs to keep track of. One of the unique things about the IP layer that most hackers know is that you can essentially "spoof" as if you are coming from a different IP address at any point. It's just that the vast majority of the time, spoofed packets are just ignored or dropped.

So basically 1.1.1.1 on port 1234 and 2.2.2.2 on port 2345 talk to 3.3.3.3 on a known relay port (say 3333). Then, the 3.3.3.3 server basically says in a UDP packet "Oh, now you can find me here -> 2.2.2.2 on port 2345" to 1.1.1.1 and "Oh, now you can find me here -> 1.1.1.1 on port 1234" to 2.2.2.2. It then spoofs a "confirm" packet from each of these address to each other to kind of "verify" to each of them that they are, in fact, talking. Then, communication takes place without 3.3.3.3 having to do any more.

Someone else might be able to give a slightly better description of what is happening, I might have gotten some of it slightly incorrect. There are actually ways to do port-scanning using this IP spoofing mechanism and what I think is called "ping bouncing" or using ICMP traffic. There are lots of fun things you can do, especially if you know how an OS builds sequences on the TCP-side, though I think after nmap added those features most of the major vendors updated to get around that, didn't they?

[–]netcrusher88 1 point2 points ago

sorry, this has been archived and can no longer be voted on

That's a pretty good description of UDP hole punching.

It's not really possible with TCP. Even if you could spoof sequence numbers TCP connection tracking is way more complex, you can't really randomly change endpoints. For TCP you just set up two connections and stick them together.

[–]w0lrah 55 points56 points ago

sorry, this has been archived and can no longer be voted on

And to think crap like this wouldn't be needed if ISPs and businesses weren't so fucking lazy about IPv6.

Sorry, I work in VoIP so I have grown to hate NAT with a passion, and anything that assists in keeping NAT "working" for longer is just prolonging the pain. I'd rather the world see more clearly how terrible it is so we could work to get rid of it.

[–]Jimbob0i0 17 points18 points ago

sorry, this has been archived and can no longer be voted on

And then twits start implementing NAT66 and unnecessarily face all the same problems again in ipv6....

[–]w0lrah 10 points11 points ago

sorry, this has been archived and can no longer be voted on

Ugh, yea, that. Why some idiot decided that even needed to exist is beyond me and anyone who implements it deserves to be beaten by their peers and users until they can't remember how to spell NAT.

NAT64 has an obvious purpose thanks to how deep we've dug the NAT hole on IPv4, but pure IPv6 should be 100% NAT-free.

[–]angrod -4 points-3 points ago

sorry, this has been archived and can no longer be voted on

Oh really ? And what about load balancer in ipv6 for example ?

[–]Jimbob0i0 19 points20 points ago

sorry, this has been archived and can no longer be voted on

Load balancer does not necessitate NAT...

Internet->LB->pool-of-systems ...

There is no need for a NAT in that place - it's just a LB device acting as a reverse proxy... completely different network layers.

[–]netcrusher88 5 points6 points ago

sorry, this has been archived and can no longer be voted on

Depends. Really blindingly fast load balancing is often almost entirely DNAT, with SNAT on return packets. Maybe modifying a little bit of L4 data, like port. And honestly, with a smart enough device doing it, if you're not messing with L7 data there's often no real benefit to sticking two connections ass-to-ass with all the overhead of handshaking and keeping sequence numbers (it adds up when you're talking millions of concurrent connections), just sling packets and track connections so you know where the next packet goes.

That's not what people mean when they trash NAT though, yeah.

[–]toebox 3 points4 points ago

sorry, this has been archived and can no longer be voted on

Surely it's better to just do MAC rewrites from the LB and let each server handle the return traffic, keeping things solely at L2 from the LBs perspective.

Like this.

[–]netcrusher88 0 points1 point ago*

sorry, this has been archived and can no longer be voted on

That's certainly possible and at least some vendors publish documents to do exactly that (it's a form of asymmetric routing, that's the 1-armed version of what F5 calls nPath), and it does have amazing throughput potential, but I don't like to recommend it. This sort of thing winds up being nightmarish to support, because a horrifying number of people who work on networks have no idea how they actually work.

ETA: "solely at L2 from the LB's perspective" doesn't really provide any benefit. I mean, in an asymmetric architecture it gives you more throughput, sure - if the sum total of the pool members' throughput is higher than the LB's (with commercial LBs not often true) - but it doesn't directly affect the LB's throughput. Once you've got the overhead of connection tracking involved, whether you're modifying just the Ethernet trailer or L3/L4 addressing (ports, for the latter) is a pretty trivial difference in work.

[–]BridgeBum 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Since your other replier talks about this from a F5 perspective, I thought I'd throw in the Cisco terms. Cisco calls this "Direct Server Return (DSR)", and it is supported. It's complex in terms of support, but it can offer the best throughput available.

However, I too would not recommend this to any of my customers in most situations. You lose the ability to do higher level functions (Layer 7 decisions) as well as having topology restrictions (L2 connection required). Some reasonable LB topologies don't have the destination servers and LB devices on the same subnets, usually to get breadth of coverage over a large access layer. NAT can easily come into play as a necessary (or at least helpful) routing tool in these types of environments.

[–]toebox 0 points1 point ago

sorry, this has been archived and can no longer be voted on

To bypass the topology restrictions, you can encapsulate the packets in an IPIP packet, and send them out. Throughput can still easily reach 80000pps on an old Pentium III w/64M memory (and a decent 1000Mbps NIC).

Of course you are missing L7 stuff (which can be handled by HAproxy, Varnish, NginX, Apache, OpenSIPS, etc..), but that's not needed for many applications, and buying a couple of crappy server and pushing 80000pps through with free, open source software is definitely (tens of thousands) cheaper than buying a redundant solution with that kind of throughput from any vendor.

[–]BridgeBum 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Sure, but at the end of the day you can say that about more or less any type of technology. There are open source routing alternatives to proprietary hardware from Cisco or Juniper, but they still sell a lot of networking gear. Likewise Checkpoint sells firewall software even after iptables/ipfilter has existed for years.

For some organizations, the skill set to build and maintain an open source solution can be a very large operational cost, much more than the CapEx cost of new hardware. Nothing wrong with going open source, but there's room for vendors too.

[–]Jimbob0i0 1 point2 points ago

sorry, this has been archived and can no longer be voted on

With a 'smart' system that maintains a persistent pool of connections to back end systems it eliminates a lot of the overhead... and having the LB as the default gateway often feels... well .... broken to me. unless I have clear requirements for doing so I generally prefer to avoid that as it simplifies network troubleshooting and routing to not have that issue...

Of course it also depends what the traffic is - if it is cacheable content then asynchronous refresh caching systems means that the L7 overhead to request data from the backend doesn't present such a latency or traffic spike when needed... depending on configuration this is how the Stingray product from Riverbed (formally Zeus Traffic manager) works.

[–]netcrusher88 0 points1 point ago

sorry, this has been archived and can no longer be voted on

It wreaks havoc on your logs though. With a little bit of L7 intelligence on your load balancer you can have it stick X-Forwarded-For on HTTP requests, but other protocols don't work so well (SMTP has no equivalent, for example). And it won't perform quite as well as packet slinging (F5 calls that FastL4).

Caching is pretty great. That's about all I have to say on that subject, I'm more of a L2-4 sort of person.

[–]Jimbob0i0 0 points1 point ago

sorry, this has been archived and can no longer be voted on

That's a pretty fair point.

As ever right tool for the job and application requirements can affect that greatly.

Personally given SMTP MTAs are smart enough to deal with multiple MX records I'd rather handle it that way than a LB setup with one to many ratio on IP to pool... even more so with the added address space of IPv6.

But there are indeed use cases where a destination node needs the true source IP and then other stuff comes into play... but technically even then depending on requirements NAT is not the only option.

[–]w0lrah 4 points5 points ago

sorry, this has been archived and can no longer be voted on

While one could make the argument that a proxy-style load balancer is performing NAT in a way, I think it's pretty clear we're talking about the pointless-under-IPv6 N machines behind N-1 or less IPs type of NAT. The one that pretty much everyone with IPv4 connectivity has to suffer under in one way or another.

Basically if you implement IPv6 in such a way that if all firewalls were open it would not be possible to create a direct connection from any machine to any other, you did it wrong. If some of your machines also happen to share an additional IP in any way for load balancing purposes that's not a problem, just don't break the end-to-end communications.

[–]festeringsore -4 points-3 points ago

sorry, this has been archived and can no longer be voted on

Address independence is an "obvious purpose" to NAT66. I can only assume your hatred of NAT has caused you to make such an inflammatory blanket statement. Don't get me wrong I agree that ISPs and businesses should be more proactive in moving to IPv6, however, just because your situation doesn't require address independence doesn't mean NAT66 isn't a valid solution to those who do.

[–]Jimbob0i0 5 points6 points ago

sorry, this has been archived and can no longer be voted on

Request IPv6 space from ARIN/RIPE/etc and BGP with your ISP if that's the level of connectivity you need... alternatively there are other options such as non globally routable IPv6 space and proxies for locking down internal->external traffic in a company.

Note that carrying out traffic via proxies at the application level is very different to behaviours at the network level...

Even then though that's not a great idea and it would still be sensible for companies etc to use globally routable IPv6 space though to guarantee non-colliding addresses between networks when merging with another or providing VPN services etc to avoid any chance of a clash of network space that would the require NAT to 'mesh' the networks together in some hacky manner....

NAT66 is pointless - there are no real usecases that cannot be better obtained in a different way and just serves to foster the NAT44 behaviour that broke point-to-point networking and clashes of private networks.

[–]festeringsore -2 points-1 points ago

sorry, this has been archived and can no longer be voted on

No user case? Check out http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html

"Better" is very subjective. What is better to you may not be to others.

I hate to be put into a situation where I'm defendiing NAT66. It's definitely not the optimum way to do networking but sometimes the optimum way isn't an option. Unless you're arguing that NAT66 should never ever be used then you don't disagree me.

[–]Jimbob0i0 2 points3 points ago

sorry, this has been archived and can no longer be voted on

Well good job the IETF are working on this!

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03

http://tools.ietf.org/html/draft-ietf-v6ops-multihoming-without-nat66-00

And in the meantime source policy routing on a load balancer or router with IPv6 addresses from both ISPs in a small enterprise multihomed environment - and other methods - are a way to deal with it without implementing NAT again....

Heck with a load balancer such as Stingray from Riverbed you could do something like have pooled systems behind with IPv6 addresses from both providers to ease troubleshooting in the event of problems and then use ULA addresses for the purpose of the communication between the load balancer and the pool members. Then on the LB system itself source policy routing to ensure that the packet is returned on the same path for an initiated session so that stateful firewalls are happy and asynchronous routing is avoided....

For connections being initiated in your network to outbound hosts the current tricks of ICMP and scripts to detect failures and adjust default gateway albeit a little hacky are still better than NAT - or you could run the scripts at the system provided RAs to only provide a prefix for a connection tested to be up...

And that's before a resolution is come to with regards to the IETF and vendors implementations as linked above and just shooting the shit without much intent thought at near midnight...

[–]netcrusher88 0 points1 point ago

sorry, this has been archived and can no longer be voted on

use ULA addresses for the purpose of the communication between the load balancer and the pool members.

Valid, but... ew. Though I can't come up with a good reason not to do it.

[–]Jimbob0i0 1 point2 points ago

sorry, this has been archived and can no longer be voted on

ULA or even link local addresses exist for a reason....

So long as the LB and the pool members are on the same subnet you could even use FE80:: addresses....

I did say the systems should still have globally routable addresses for initiated connections and for direct connections when troubleshooting... and IMHO it's still better than putting NAT back in place...

[–]netcrusher88 2 points3 points ago

sorry, this has been archived and can no longer be voted on

Oh right, ULA. Got those mixed up with the fe80, which still strikes me as a bit off but I can't articulate a reason for it.

[–]w0lrah 0 points1 point ago

sorry, this has been archived and can no longer be voted on

So we have a technology that provides enough addresses that we could allocate the entirety of IPv4 address space to every single person on the planet for the forseeable future, and your reasoning to retain NAT is so people don't have to use ISP address space?

It seems there may be a better solution in there somewhere... Something involving people and companies that need this having their own address space... We might even come up with some sort of protocol for announcing your address space to connected ISPs...

Hell, even for those who wouldn't get their own block for whatever reason, we might even come up with a way to redirect their provider-based address space to another system temporarily.

The only non-shitty way to implement NAT for address independence would be a static NAT where each internal address is mapped to an individual external address on each provider. As I said to the other guy, if you implement IPv6 in such a way that with all firewalls down you couldn't access every service on every internet connected machine on your network via their own addresses, you did it wrong. We don't need NAT implementations that require the sort of stupid hacks this whole thread started off of.

[–][deleted] ago

sorry, this has been archived and can no longer be voted on

[deleted]

[–]w0lrah 1 point2 points ago

sorry, this has been archived and can no longer be voted on

You have no idea how much I'd love to always run my own cables, or at least have a separate VLAN. Customers tend to not want to pay for new wiring or managed switching though.

[–]dcormier -3 points-2 points ago

sorry, this has been archived and can no longer be voted on

"too lazy"

[–]RagnarIV 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Try thinking about it from their point of view, changing over to IPv6 is no minor change. First off, there are virtually NO consumer routers that are IPv6 ready and secondly users who are not using dual stack machines will have issues getting out onto the net.

Also no one wants to go first and risk losing customers to competitors due to service outages related to these changes. It's kinda retarded but the mentality for a lot of US ISPs has been, "Lets wait and see what happens when X competitor does it."

Also my company has had to replace our core routers just because there was a 75% performance loss on them once IPv6 is enabled.

[–]dcormier 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I'd love to switch to IPv6 in my home. I'll be replacing my home router soon and will be getting one that supports IPv6. My ISP claims they have already rolled it out, and I'm participating in the beta my mobile carrier is doing (which is kind of awesome, because my phone isn't NAT'ed any more).

The problem I have is that my TV, Blu-Ray player and Xbox don't support it. Device manufacturers and software developers (I've found a few apps that don't work on my phone with IPv6) need to be ready before people and businesses can fully move over.

[–][deleted] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I don't know much about IPv6 at all. Is it something you'd want to use on a local network? I'm sure some legacy equipment doesn't support it, but are there any real benefits other than more address and no NAT? (Which of course is no bother on a local network.)

Something to read up on tomorrow at work, woo!

[–]ten_thousand_puppies 3 points4 points ago

sorry, this has been archived and can no longer be voted on

SLAAC makes it much easier to get hosts up and running, since they don't need DHCPv6, and assign all of their addresses themselves. You can still rely on DHCPv6 to manage your static addresses.

Subnetting is way easier, because you're never dealing with anything smaller than a /64, and all subnets are done on hex boundaries.

It no longer has broadcasts, and has a more efficient header.

There is no more fragmentation done through routers, which gives some security benefits (can't rely on it as a way to bypass firewalls that cannot automatically reassemble packets before passing them) and provides better performance. End-to-end Path MTU is determined through ICMPv6 messages (so make sure you allow those on your ACLs!)

Ping sweeps become harder, since your typical IPv6 subnet is bigger than the entire current IPv4 addressing space. (264 vs 232). Well spaced address blocks for your statically assigned addresses can make a ping sweep an almost futile effort, and for self-assigned addresses, the address is entirely dependent upon the host's MAC address.

Multicasting is a much bigger deal in IPv6, since broadcasting doesn't exist.

ICMPv6 also plays a much bigger role, since the v6 ARP/RARP equivalent, the aforementioned Path MTU, and a host of other important things are all rolled into it.

A interface/device can now not only have more than one address assigned to it, but is guaranteed to have at least three minimum; usually there quite a few more, but it depends on the device (see scopes below).

There are now three primary address scopes:

Global Unicast addresses are pretty self-descriptive; the current allocated space for them is 2000::/3. It's the equivalent of any public IPv4 address

A subset of these are Anycast addresses, which are one-to-closest addresses which can be assigned to many devices, all of which can process a request directed to them. Think of how root DNS servers work now, and you've got a good idea of these. These addresses cannot be distinguished from other global unicast addresses

Multicast addresses are also pretty self-explanatory. They fall under the range FF00::/12, and have their own individual set of scopes (not going into details here, look it up if you want more)

Link-Local Unicast addresses are bit trickier to grasp initially; falling under the range FE80::/7, they are addresses whose scope is limited to the local subnet only. They're used for a number of things, like during address initialization, routing protocol updates, neighbor and router discovery (the former being the v6 ARP equivalent), and many other things. Again, won't go into a ton of detail, you can look it up on your own.

Each device, assuming it connects to the internet in some way, will have at least one address from each of these scopes, although as I said, they can have many many more.

People also like to say IPv6 is more "secure" since all devices that run IPv6 must also support IPSec, but that doesn't really amount to much.

Those are the biggest highlights I can think of off the top of my head, but there are plenty more I've missed. Think that gives you some stuff to read up on anyway :)

[–][deleted] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Awesome, thanks!

[–]cos 1 point2 points ago

sorry, this has been archived and can no longer be voted on

How is NAT "no bother on a local network"? Do you mean an isolated local network that is entirely cut off from the rest of the net?

IPv6 still has autoconfiguration features that would be nice even on a completely isolated network.

[–][deleted] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I really don't know why I said that. I was assuming an isolated network yes, I don't know why though. Bit of a herpy derp moment.

[–]dfbgwsdf 3 points4 points ago

sorry, this has been archived and can no longer be voted on

There's also this cool tool and the accompanying paper.

[–]braclayrab 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Yes, came here to recommend this as well. The code is available, I believe.

[–]vtbrian 3 points4 points ago

sorry, this has been archived and can no longer be voted on

It probably just uses something to the equivalent of STUN I would think.

[–]linuxraptor 2 points3 points ago

sorry, this has been archived and can no longer be voted on

Have you seen how STUN can work with TURN? Super cool: http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT

[–]vtbrian 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Yea, it is pretty cool. I do a lot of VoIP stuff so I've looked into it for remote phones and such. I always end up being able to put a VPN device on-site though so I still haven't had to use it.

[–]linuxraptor 0 points1 point ago

sorry, this has been archived and can no longer be voted on

That's brilliant! May I ask if you use openvpn? I would love to learn how to do that. Any links or google search terms you'd suggest?

[–]vtbrian 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I usually just put in a Cisco ASA 5505 or a Cisco 800 Series router at the remote site to do the IPSec VPN back to an ASA at HQ. The new Cisco phones (79x2 or 79x5) actually have built-in VPN clients that I've used before as well. Other phone manufacturers such as Snom also do VPN, but its usually just PPTP.

[–]giovannibajo 1 point2 points ago

sorry, this has been archived and can no longer be voted on

Mid-class Snom phones (€100) do support openvpn (and ssh into them). We deploy them so that telecommuters can join our firewalled Asterisk simply by plugging them into their home router.

[–]giovannibajo 0 points1 point ago

sorry, this has been archived and can no longer be voted on

BTW they also have a bultin router+switch so if people connect their computer to them, they are automatically within the VPN themselves.

[–][deleted] ago

sorry, this has been archived and can no longer be voted on

[deleted]

[–]Timmmmbob 1 point2 points ago

sorry, this has been archived and can no longer be voted on

That's a reasonable question actually. My guess is because people that make NAT routers don't give a shit about it.

[–]Theon 3 points4 points ago

sorry, this has been archived and can no longer be voted on

Wow, I just always assumed that with Hamachi and the like, the central servers act as a proxy for the clients. In retrospective, that was probably really dumb, but it never really occurred to me.

Thanks for this!

[–][deleted] 3 points4 points ago

sorry, this has been archived and can no longer be voted on

I remember a while ago trying to establish a Hamachi connection with a friend who was at university. When it said "relayed tunnel" I was like "huh, isn't that what it does normally?" Then I smacked myself, because if everything were relayed you'd get a horrible ping, and they'd have huge bandwidth usage at their servers. So today, months later, I decided to find out how that worked. It's neat, huh?

[–]keeperofdakeys 2 points3 points ago

sorry, this has been archived and can no longer be voted on

You're forgetting about UPnP, http://en.wikipedia.org/wiki/Upnp#NAT_traversal. This can be used to tell the router "give me all traffic that comes to this port". This is often used by torrent clients to allow people to connect to you.

[–][deleted] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Huh. I didn't even know that UPnP did that. I thought it was exclusively for the discovery of other devices and stuff on internal networks. I've read up on all this stuff before but apparently my memory needs refreshing.

[–]skeeto 0 points1 point ago

sorry, this has been archived and can no longer be voted on

It makes me happy when an application knows how to use UPnP. It's always worked well for me.

[–]brasso 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I wouldn't say circumvent, it implies NAT functioning like a firewall... which it does, but that's by-effect. What you're doing is establishing a NAT to NAT connection despite being hindred by it, while the NAT is still in effect. It's clever but it didn't circumvent anything. I'm just nitpicking...

[–]Signal09 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Ive done work in-regards to this type of tech; its a pain in butt :( Especially when your software is running in an enterprise network.

[–][deleted] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I may have to do the same thing soon. We have clients all over the planet, using our equipment, often in remote locations. We need to establish a connection to this equipment somehow and we weren't sure how to connect to it if they don't have direct internet access through a LAN.

[–]Schwag 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Correct me if I'm wrong, but isn't the point of P2P to avoid needing a centralized server?

According to http://www.brynosaurus.com/pub/net/p2pnat/

"Hole punching assumes that the two clients, A and B, already have active UDP sessions with a rendezvous server S"

[–]pipeep 0 points1 point ago

sorry, this has been archived and can no longer be voted on

The P2P protocol could potentially allow a client to get another (random) peer on the network to help them with the hole punching.

[–]ComicOzzy 0 points1 point ago

sorry, this has been archived and can no longer be voted on

In addition to what iateyourcookies posted, you might check out Security Now! podcast #18 and #19 from GRC.com. They mention it quite a bit in episodes after that as well, but I'm pretty sure #18 explains how it works if you're a fan of listening to podcasts.

[–]nojorge 1 point2 points ago

sorry, this has been archived and can no longer be voted on

My favorite podcast from my favorite podcast (netcast!) network. :)

[–]linuxraptor 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Steve Gibson + Leo Laporte = Winning.

[–]irve -3 points-2 points ago

sorry, this has been archived and can no longer be voted on

Now I understand why my GF gets those portscan alerts :D