Directly connect to your corpnet with IPsec and IPv6

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

  • Windows Vista Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)

  • That are domain-joined

  • Users run as non-admin

  • Group policy applies numerous settings

  • UAC is enabled

  • BitLocker is configured to protect confidential information stored offline

  • The Windows Firewall is enabled

  • NAP is used for checking health

  • Forefront Client Security for keeping malware off the box

  • Smart cards for strong authentication of users

  • IPsec is required for connection authentication and traffic encryption

  • IPv6 is required for worldwide Internet connectivity

  • A DNS suffix search list represents the data center name space

  • Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog 🙂

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Comments (26)
  1. Anonymous says:

    Interesting idea, Steve. Check out my observations at



  2. Anonymous says:

    I’m sorry if I offended you, that certainly wasn’t my intention. We can spend an eternity reading IETF drafts and dicussion lists, or we can take the technologies available today and build an environment where the distinction between the Internet and a corpnet evaporates. You ask for a specific time period, yet reject my answer, despite the evidence.

    As I’ve described, the technology is here now. You’re asking for the real world, yet not acknowledging that the building blocks already exist (no "magic" or "door-knocking" required). Nowhere have I claimed that "my test corpnet looks like the Internet." Rather, I describe how one can use the existing Internet, along with existing technologies in current products, to achieve the kind of perimeter reduction that every customer I talk to is clammoring for. Of course I encourage people to pilot it first — that’s why I’m writing and speaking about it, and that’s why I’m working on more detailed guidance. Yes, it takes some work to get to this point, but it’s work that’s entirely possible now.

    I’ve seen presentations about IPv6 deployment (or lack thereof). Do you suppose that the reason for low deployment is that no one has had a need to? While some of us netheads love it for its protocol pureness, people do things only when there’s an economic incentive. The US hasn’t adopted the metric system because to do so is very expensive — and the rest of the world is perfectly happy to convert from metric to imperial when doing business with the US. Someday it’ll cost the US more *not* to convert, then it will. Same with IPv6: up until now, there’s been no economic incentive that overcomes the cost. Well, finally, a reason is arising — one that enables mobility experiences not available previously, and organizations large and small are seeing this.

    To address a couple specific points of yours — first: traditional gateways. I’ve already described why traditional gateways won’t disappear anytime soon, because the distinction between trusted and untrusted endpoints won’t go away. There’s no contradiction here, and I’m not sure how you read that into my explanation.

    Second: the idea of "anywhere." Apparently you don’t believe me when I say that it works anywhere. How can I convince you that it does? I’ve successfully operated in this environment in 30 countries on six continents, from homes and airports and hotels and offices, over wired and wireless and tethered Bluetooth — all kinds of Internet connections, really. Never have I had to check whether IPv6 is enabled by an ISP or allowed through some random router, because my computer automatically uses one of many transition technologies (yes, even Teredo, although I’m right now verifying the extent of server-side Teredo support) included in the operating system. So I’m not sure why you claim otherwise. "Only IPv6 everywhere" is neither a requirement nor a desire.

    Rather than worrying about what other people think about IPv6 and its capabilities or pervasiveness, which will only delay migration, why not take the plunge and build a test lab similar to what I’ve described, and help accelerate change? I predict you’ll be pleasantly surprised.

  3. Anonymous says:

    I’ve already described my view of the network of the future in my article here. IPv6 is very mature and well-defined. I’m not sure why you think it’s far away? If you read my article, you’ll note that we are running IPv6 on our own corpnet now, and it (along with IPsec) is the foundation of “anywhere access,” which we are running right now.

    You’re asking a lot of questions that seem to indicate an unawareness of the capabilities of modern networking protocols. I’d suggest you settle down with a few good books and websites to get up to speed on IPv6. Perhaps you can begin with

  4. Anonymous says:

    I blogged some time ago about the " Shrinking Enterprise " and wouldn’t it be neat if we could do away

  5. Anonymous says:

    How do you define "defense in depth"? Layers of networks with firewalls between each one does not equal defense in depth. Misconfigured firewalls could be equally problematic, and no amout of even perfect firewalling will stop attacks targeted at vulnerable applications.

    Testing your IPsec policies is critical here; Vista’s simplified IPsec policies make it much easier. The border router drops anything that isn’t IPsec, and the servers will drop any IPsec requests that they can’t authenticate.

    There’s plenty of depth in the direct connect design, it’s just implemented difrerently. Some of the controls are on the host, whose configuration is set and validated by computers in the data center. Other security controls are in the data center itself.

  6. Anonymous says:

    Now that the blog spam is somewhat under control, I’ve reopened comments for longer than 90 days.

    jcorey– You’ve nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

    Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset — known humans, with known portable computers — can’t we do something better than treat them as toxic invaders?

    Indeed we can. And that’s what I’m proposing with direct connect. The technology — managed, of course, with the right processes — exists so that you can extend the trust to known computers even though you don’t trust the network they’re connected to. This is because you have mechanisms that:

    1. Allow you to configure the machine according to your requirements (domain join, group policy)

    2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

    3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

    4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

    5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

    With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don’t see that there’s any need to fall back to “detection” now. Detection technologies were — and remain — necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what’s capable today.

    You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I’m not very proud of what I just wrote, because I loathe generalities, but I’m not sure what else to think here. Sigh.

  7. Anonymous says:


    The guy merely said it’s possible. *smile*

    Security is a myth and control is an illusion. I’m with you completely about the oversimplified aspect of the implementations but you only presented the perspective of the users and implementors. What about those who actually have the power to change things ? Cause the solution, as stated, is here.

    ISP owners now has something other than price per subscription they could use as competitive edge. Hardware vendors also will set a side some budget to bet on this "just in case". Enteprise software might add this into the feature… and so on.

    I remember the time where everybody thought tcp/ip was too complicated to be worldwide. I also remember some people thought netbios will be "anywhere".

    So calm down…

    The guy merely said it’s possible. *wider smile*

  8. Anonymous says:

    Fixed the wording about Business edition and Software assurance upgrades. Thanks guys.

  9. Anonymous says:

    But Adrian, I don’t want to be patient, and my customers don’t want to be patient. My customers have real business problems to solve, and I’m giving them a technical architecture they can use right now. This is exactly the kind of presssure we need to get the RFC-naval-gazers to get off their duffs 🙂

    You can sit behind as many IPv4 NAT gateways as you want and it still works. What do you think sits in every airport, hotel, and home network? Yet my direct connect works every time.

    AYIYA is not one of our supported transition technologies, and we have no plans to implement it. Teredo, 6to4, and ISATAP are better solutions.

    SSL VPNs are a different beast. These are more appropriately viewed as application proxies. You’re right, if you’re visiting some site where they allow only outbound HTTPS, then that breaks not only IPv6 direct connect but also all traditional IPv4 VPNs, too. This is orthogonal to the discussion of IPv6 direct connect.

    If you want to move the conversation to operating systems, I can tell you that Vista certainly isn’t a requirement. It makes the most sense for two reasons:

    1. Vista includes built-in BitLocker volume encryption, which is extremely important when users with managed laptops need to carry confidential data offline. This eliminates the threat of data interception from stolen machines.

    2. Vista user account control makes it easier to build an environment where users run as non-admin.

    You can accomplish IPv6 direct connect with XP as well — all the other technologies in my list are supported. We can even include MacOS and Linux, since with the proper add-ons they support IPv6, IPsec, and NAP. But you do lose the ability to centrally control configuration through group policy.

    I’m lost why you think charts have any value. Such a chart would show 100% success for every attempt of mine. What value is that? And what does the price of connectivity have to do with anything? I can’t control how much a hotel or a coffeeshop charges for Internet access. I’ll take any connection I can get, and make my IPv6 direct connection on top of it.

  10. Anonymous says:


    Great post – even the argumentative responses! My question is how you feel about the security community’s never-ending need to do stateful packet inspection on this traffic which would now be encrypted with IPSec. I’ve spent hours arguing with absentminded security folks who fail to see the future of networks as you do. They are always a proponent of VPN (or IPSec) termination points so they can do packet inspection on traffic in the clear. Their contention is that a host could be infected, then begin attacks which are wrapped in encrypted end-to-end IPSec packets – thus losing the ability to "detect" and attack. I hate the idea that these "professionals" continue to think that IDS/IPS is the answer. Until they can detect unknown attacks, signature based anything will continue to be behind the curve. Am I wrong and is this still a valid way to think about network security? Or is the average security professional that out of touch with how we should architecting the next generation of networks.

    Btw, thanks for all the good info!

    -joe c

  11. Panagis says:

    Hey Steve, I was there when you gave that talk, nice drawings on the tablet 😉

    Seriously, I’m so glad you showed us a way to secure our environment that doesn’t require any additional tools.

    I’m sure you will agree that the real challenge here is to convince the upper management, not the IT world…

    Thanks for posting this, I can forward this to my boss and hope for the best 😉

  12. Gary B says:

    I think you’ll have to convince the security people, not the upper management.  As a security guy, this idea has tantalized me for years, but I’ve always viewed it with a healthy dose of skepticism.

    The problem, as I see it, is that there’s no defense in depth.  A misconfiguration on the IPSec side can expose your whole infrastructure to risk.  Or am I missing something?

  13. Lidvar Kornberg says:

    Hey Steve, I was attending the 2 sessions you recently had in Norway. I kind of remember that you talked about a Teledo gateway (which was running Linux….ugh!) and if I understood you correctly you placed this as the gateway between corpnet and internet. I have read up on the function of Teledo and the only reason I can think of you need to put a Teledo gateway in here is to do some 4to6 conversion. Is that correct? Does this mean that the corpnet only run pure ipv6 (no teledo tunneling over ipv4). Does this also mean that if we also run ipv4 on the corpnet that we can do this without the Teledo gateway (as we then can use the public available Teledo broker service)?

    By the way. I have start talking about this to the upper management and they totaly buy the simplicity and benefits this will have…..hey, who does not want Outlook Anywhere functionality for all services?. This is great stuff! Also thanks for the idea you gave me in the 1:1 session about using Federation between intranet AD and our "customer" AD and the use of IAG so we can get rid of the replication problems out to our DMZ networks.

    kind regards

    Lidvar Kornberg

  14. adimcev says:

    Hi Steve,

    "Nice one".:)

    I was reading about it in Tom’s blog yesterday.

    I’ve just stopped when IPv6 and now were mentioned (Tom moved into a more technical discussion).

    It would be interesting to hear how the network of the future looks to you regarding its infrastructure.

    Is IPv6 a mature technology, a well defined one ?

    How would you know how it would be like in the future?

    IPv6 is far away, and anywhere+IPv6 even further away.

    From anywhere ?

    Please, just define anywhere, will you ?

    "It DOES NOT depend on how remote hosts have obtained their own IPv6 connectivity (native IPv6, tunnel broker [RFC3053], softwires [RFC4925], Teredo [RFC4380], 6rd [thisdraft]…)."

    Do we have a time schedule to say when it will only be IPv6, as at this moment it looks like there it will be a lot of co-existence, which is yet to be defined ?

    We can only hope that IPv6 deployments will be done carefully, otherwise, we will end up with a mess.

    Even Teredo is not here yet. This one introduces its own security risks. Are we ready to deal with it, do we fully understand its security, what firewalls can hadle it ?

    Is there any plan to be followed, a clean path, so that we can talk at this moment about the network of the future having a practical solution?

    "The common thinking for the last 10+ years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4. It has not happened."

    How would you know that there would be no NAT in IPv6 ?

    "> Worst case, it doesn’t get used and we have this nice utopian NAT-free IPv6 network.

    No, that’s the best case. The worst case is that it encourages vendors to implement it and corporate IT folk to deploy it."

    "> Can you say the same for the worst-case situation for NOT standardizing v6 NAT?

    That’s a very hard question to answer, because it depends very much on how CPE and firewall vendors react in their product plans. Since they all know that NAT isn’t needed for IPv6, and product managers are not known for funding unnecessary work, in the best case, it doesn’t get implemented. In the worst case, it gets implemented randomly."

    Medieval gateways, maybe, how about IPv6, this is a technology from the 90s, would it be still possible to call it a modern technology, when it would be eventually deployed at a large scale ?

    How is it possible to achieve a "now" security solution combining a present solution(the list of technologies from Microsoft you’ve mentioned) with a theoretical and not well defined one, the IPv6 of the future ?

    Have we fully understood the security in practice of IPv6 ?

    How it would look your list of technologies say, in 2015(just a date, no allusion) ?

    Correct me, but your design appears to be based on "My test corpnet" looks like the Internet ?

    Can you sustain with a time graph your interesting solutions ?

    Who knows, I might be a boring old man before IPv6-only will exist….

    Wouldn’t be more feasible to say, it’s time to start "piloting this very idea on your internal corpnet", and to define the boundaries of this corpnet ?

    If will it be the network of the future without "boundaries", it’s just an unanswerable question in this moment, IMHO. Just because it will take a lot of joint efforts to happen. And "joint" does not have a good reputation.

    By the way, looking forward to the "October issue".



  15. adimcev says:

    Oh my, oh my!

    I really do appreciate your concerns about my level of "awareness" regarding modern network technologies and the fact that you want me to be a well informed man.

    I might have some for you as well:

    It’s just my personal feeling that you did not understand the nature of my questions.

    My questions were not asked just because I personal do not know how to answer them.

    I’m talking about the REAL world here.

    The way you described the "network of the future", this future appears to be a very close one, although you do not place it in a specific period.

    The fact that you already run IPv6 on your own corpnet is pretty much meaningless regarding the big picture.

    Your article just and only assumes that your corpnet network is a simulation at a small scale of the future "Internet".

    Your article just and only assumes that anywhere I would be in the world, I would enjoy the same benefits and face the same problems that your corpnet is currently experimenting.

    Which is deeply wrong. Hey, this is just IMHO.

    When I’m saying that IPv6 is far away I’m not talking about an IPv6 network here and one there.

    I’m talking about big scale deployments all arround the world.

    If I would contact my ISP right now, and ask them about IPv6, I would get an answer like "say what" ?

    In fact, my ISP(one of the biggest from my country), just a couple of months ago replaced their customers old IPv4 equipment with new IPv4 only ones.

    In the REAL world, there are currently small vendors involved in the ISP area which DO NOT have any product incorporating IPv6, IPv6 being just on their roadmap.

    It would take a lot of efforts from vendors, ISPs and yes, the end customer(either is a company or a home user) to make it be only IPv6 everywhere.

    Funny question though, how many of the networking guys out there are "IPv6 ready", as they are also part of the efforts too…

    As described in your article, IPv6 is a must everywhere I would be, at home, in a hotel, on a wireless campus…

    Here’s another one for you:

    There are plenty of them:

    Please don’t send me where I’ve been, there is just an awful big number of "will" there.

    One more time, I’m questioning the expandability of your design into the REAL big world in respect with the "overall infrastructure" supporting it.

    And you have no answers for that, you just imagine that this will be somehow, magically there, knocking on the door…. anywhere…

    Personal I do not "buy" that.

    These are REAL world problems, questions to answer, and interesting, there are a lot of people out there wondering about…

    I would really appreciate if you would leave my "ignorance" to rest in peace.

    Quite frankly, my "ignorance" about the near feature is mainly focused on TMG or UAG.

    Near future just means to me a couple of years.

    Interesting though, you seem to contradict yourself a little bit, because you do not throw away completely the gateways or the perimeter. So there is nothing really to count down for.

    Just plenty to dream about.


  16. adimcev says:

    Oh, and I suppose the silver bullet named Teredo was not prepared for me, as we’re talking here, for example, of anywhere.


  17. adimcev says:

    Don’t worry, I was not offended, just amused.

    It’s an old habit and pleasure of mine to read RFCs.

    Actually, I do have a test IPv6 network in my lab.

    It does not do what you describe, it’s just my little game.

    It was not my intention to find a reason why IPv6 was not adopted at a large scale, just to simply point out that it takes time, and we have to be patient.

    Actually it’s quite simple why I cannot be convinced by the idea of anywhere.

    Because of the co-existence of IPv4 and IPv6 in the near future, IMHO, thinking of your solution while being on the road, unfortunately I’m back to where I’ve been before, to the hope and prey game.

    What if I’m behind one of "those" IPv4 NAT device ?

    Although Microsoft put a lot of efforts in making Teredo work with most NAT devices, including symmetric ones, I do not know this as a fact.

    I know that it is only supposed to work. Your results show that indeed it appears to work.

    So I can hope.

    Maybe AYIYA can help me. I do not know this either as a fact.

    Let me assume that the NAT device is not a problem, maybe the NAT vendors read the existing informational RFC :).

    What if I’m behind a restrictive IPv4 firewall which does NAT and forces me to use a web proxy too(I already have some places on my mind)?

    Only HTTP and HTTPS are allowed to the Internet.

    Looks like I’m screwed. I can’t have IPv6 connectivity.

    Teredo can’t help. Neither AYIYA.

    So I can prey. I suppose that "connectivity price" is taking into equation too.

    Interesting Teredo combined with IPsec might improve my personal network security, however Teredo has quite the opposite effect to the network from where I’m connecting, if allowed.

    So the security folks, might follow the idea spread in press, that it is a good idea to block Teredo on their network firewall. Anyway, if the firewall was indeed a firewall, meaning really allowing only needed traffic, I could not use Teredo in the first place. Neither AYIYA.

    It was just a quick thought of mine, that if IPv6 native support would be everywhere, true access from anywhere might work. But I do not know this as a fact, I’m just imagining. Someone may return to me my own words like: what if you are stuck behind a proprietary IPv6 NAT device. I would just say, whatever, I will just wait and see, too early to call.

    I do not argue that the pieces are here(I’m aware of the existing networking equipment from various vendors too), nor that you have it working already. That would be stupid, because I would say that you are lying.

    As said above, I do not believe that indeed access from anywhere is a feasible possibility even with your solution.

    The gateways will still be there to complement this issue along with other problems like the existence of non-Vista machines(the market share is not that good for Vista, personal I’ve contributed to that, buying an XP OS to replace the x32 Vista edition on my laptop, although now I’m thinking to buy a x64 Vista one), which will result in my opinion in the existence of a dual architecture, and this should be taken to the management group. That’s why I did not start to deeply evaluate the security of your solution vs let’s say, the traditional one.

    I have a question for you regarding anywhere, since you was able to test access from many places around the world, did you had time to create some statistics, like a chart showing the successful connectivity rate of your solution vs a SSL VPN solution (I’m making no allusions to the security afforded by each solution), maybe taking the price of the connectivity into equation(as for example I can pay for wireless Internet or I could get it for free) ?

    According to your last post, we will have a 100% success rate with your solution, so it would be interesting to see the results for a SSL VPN solution. Although 100% results are usually hard to swallow.

    Hmm, haven’t you already noticed that me worrying about what other people think is not an aspect that concerns me:). I was just saying that some IPv6 technical aspects have not been clearly defined yet, and they are currently discussed.


  18. adimcev says:


    Yes, no patience, but a lack of patience in a good way.

    Speaking about XP, I won’t say all, ’cause I might have missed some, most docs on Microsoft site say that Teredo does only work with symmetric NAT devices on Vista or Win2008 and if you are behind such a NAT device with XP or Win 2003, game’s over with Teredo, thus no-go IPv6. My quick tests showed the same thing. Maybe a change that I did not catch occurred ?

    So Vista might be required.

    Personal I did not found any references about AYIYA on Microsoft’s web site, I just thought to mentioned it anyway as I was not sure of its status.

    The value of a chart might be for some the "kind of pressure" IMHO. Many people like charts. A good chart will not show 100%. Having such a statistic, indeed will be useless.

    The price has to do with anywhere, just imagine that I’m sitting in a hotel behind a restrictive firewall, so no IPv6 connectivity. The next door coffeeshop charges me, how it would sound to call the management and say, look I need 1$ for Internet access in order to get working the new thousands of dollars "true access from anywhere solution", and they would reply: "but you have free Internet in your hotel, we checked this aspect when we’ve made the reservation".

    Wow, that would not be nice.

    Just to stress you a little bit, OpenVPN works through a web proxy which could require certian forms of auth, and is a full network connectivity solution(if we talk only about its connectivity possibilities)

    So after all, for now, anywhere = find any connection that will work.


    I’m cool…

    Very cool…

    And smiling as well…

    I really like to spin the anywhere wheel…

    I’ve presented only those aspects, because speaking about the ones that have the power to change things we’re entering the theoretical land, a territory I wanted to avoid as much as possible. I wanted to keep things in the now time frame and in our hands, because that’s all about, to make it with what we have, on our own, and not to depend on X or Y.

    I’m not saying that IPv6 is extremely complicated, I’m just treating it with a lot of respect because I want to do things correctly.


  19. paulius says:

    "…So after all, for now, anywhere = find any connection that will work…."

    Proves the x and y is not entirely theoritical.

    And with…

    "…I’ll take any connection I can get, and make my IPv6 direct connection on top of it…."

    I find it fascinating that with all this argument, I believe the BOTH of you are trying to say the SAME thing !


  20. adimcev says:

    Hi Joe,

    If you and Steve allow me to add a few words(in case they were not already added somewhere before):

    This "network of the future" has some of its bits way in the past, in the 90s, in a paper written by Steven M. Bellovin, called Distributed Firewalls, paper which addresses some of your questions too:

    Looks like with the new line of products, Microsoft managed to "link these bits" with practical means, while adding some new bits too.

    Interesting, eh ?

    Take care,


  21. Steve says:

    Hi Steve after seeing you at techEd Australia Ive pretty much sold my management that we can do this and we should do this, bring on the instruction set 🙂

  22. dodacrazy says:

    Hey Steve you and your montize buddy Scott will soon have your hands full after the federal officers come down on your data scams and as for your educational acts i’m not buying it and if others are willing to trade your data for their profits guess there are fools born everyday tunnels oh I see drug dealers right Stevo

  23. Richard says:

    Hi Steve,

    Great article!  Great presentation (went to your talks at Tech.Ed Australia recently).

    Really can’t wait to see this written up in full in something like Tech Net Magazine so that novices like me can start to think about how to implemented it!



  24. Joseph Ozdemir says:

    G’day Steve,

    I was quite pleased when I came to this session – first session of the second day of Tech Ed Australia and I didn’t fall asleep! One of my colleagues whom you know all to well (you went to dinner with him the night before) strongly reccomended swinging by one of your sessions…

    And anyway back to my point your session on 21st century really really amazed me – I loved the idea! So basically being the nerd that I am, I’m replacing my current home server machine, implementing a Server 08 domain within my own home (Still have my free copy from Heroes Happen), and I’m going to have a crack at setting this up!

    Just wanted to say thanks for giving such great sessions at Tech Ed and id I run into any problems setting it all up I’ll shoot you an emal haha.



  25. Anders Vinger says:

    Hello Steve.

    I really like the concept of implementing an ipsec solution in order to give my roaming users acess to log into my AD and get all the "corp-net" resources while skipping VPN.

    However one question keeps popping up; Why exactly do I need to use IPv6 ?

    Apart from my users being in a country with IPv6 all over (China comes to mind), and planning for the future. Are there other reasons for why I couldnt just base my solution on IPv4 ?

  26. adimcev says:

    I was reading the DirectAccess Early Adopter’s Guide, and it looks I have to take my words back…

    IP-HTTPS will be here, so the idea of "anywhere" might be indeed true…

    And in the OS arena, Windows 7 promises to be a hit…


Comments are closed.

Skip to main content