As LogMein says, even with the TMobile and Rogers use, it's extremely unlikely that their customers will need to communicate with any hosts in 25/8. That said, I absolutely agree that an IPv4 range devoted to VPNs would be great. I run a personal VPN to my home LAN, and I specifically use different ranges of RFC 1918 space for the addresses in my home and my VPN.
Cheers, Andy On Sat, Nov 24, 2012 at 11:36 AM, Paul Wouters <p...@nohats.ca> wrote: > On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote: > > > http://b.logme.in/2012/11/07/**changes-to-hamachi-on-**november-19th/<http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/> >> >> LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They >> avoided conflicts with RFC 1918 space by hijacking IPv4 space in 5/8, now >> actively being allocated by LIRs in Europe. When that didn't work (see >> link above), they moved to 25/8, allocated to the UK MoD. While I'm almost >> sure that they haven't got it quite so wrong this time, following the >> comments says that the idea was not only a very bad one to start with, it's >> cost a lot of people a lot of grief that IPv6 was clearly going to mitigate >> in renumbering. Perhaps it is why they recommend it per default, if not >> for the number of applications that would be broken by it. >> > > Both TMobile in the US, and Rogers/Fido in Canada use 25/8. Our IPsec > client per default only allows incoming NAT-T for ranges in RFC1918, due > to security reasons (you don't want them hijacking google's ip range). So > we actually had to add 25/8 to the white list a few years ago. > > But, it would be nice to have an IPv4 range dedicated to VPN ranges, so > you can setup things like L2TP tunnels without fear of collision in the > RFC1918 space, although I guess technology has advanced enough to > implement proper segmentation and workarounds for this these days. > > Paul >
