I expect to be flamed for suggesting it, but why not use the Shared
Address Space for this purpose? (http://tools.ietf.org/html/rfc6598)
Cheers,
-Benson
On 11/26/12 11:52 AM, Andrew G. Malis wrote:
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 <paul(_at_)nohats(_dot_)ca
<mailto:paul(_at_)nohats(_dot_)ca>> wrote:
On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote:
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