Q&A with Swen Baumann, product manager at NCP engineering

We recently spoke to NCP engineering’s Swen Baumann about split tunneling and its role in IPv6, and how to best deploy it when working remotely. 

VPN Haus: How is split tunneling impacted by IPv6 dual-stack networking?

Swen: The main thing to remember is, split tunneling needs to be specifically configured. For instance, in a “dual-stacked” world – which implements both IPv4 and IPv6 stacks — you will have to configure either both or just only one, depending on which stacks you plan to use. Once you’ve completed this configuration, split tunneling will be processed — no matter if the traffic is IPv4 or IPv6. Simply put, to enable split tunneling on IPv6, you only need to configure the stack – but otherwise it should run smoothly.

VPN Haus: How does split tunneling differ from inverse split tunneling?

Swen: I know it’s stating the obvious, but it’s inverse. Here’s what that means. With conventional split tunneling you configure some networks that are to be processed within the tunnel, which means there are others not be taken into the tunnel. With inverse split tunneling it is just the other way round. You configure those networks that are not be processed through the tunnel and all the rest will be taken into the tunnel. In other words, split tunneling becomes the rule — not the exception.

VPN Haus: In cases of split tunneling for the home office, do you recommend the corporate VPN be set as the default gateway to first route all traffic, dropping those requests deemed unnecessary to secure?

Swen: Usually yes. But ultimately, it depends on the security policies of the company. Generally, the recommended approach is to direct all of the traffic into the corporate tunnel, so that all of the company’s security protocols can apply to the traffic and fulfill the organization’s security needs.

What We’re Reading, Week of 2/27

InformationWeek, 10 lessons from RSA Security Conference
Network Computing, RSA Chief Tells Enterprises: Make Security And Privacy Protection Top Priorities
InfoWorld, Making sense of mobile device, app, and information management
IT Business Edge, IPv6 Security: Not Scary, Unless it is Ignored

DirectAccess and VPN – Who’s Hurting Who? Part 1

By Nicholas Greene

It’s been called “The Death of VPN.” It’s been placed on a pedestal as one of the best available solutions to our VPN woes. But, on taking a step back, does DirectAccess  actually deliver on its promise?

Two months ago, VPN Haus ran a story asking just that. What that article found was telling- more and more, experts are saying no. While it’s certainly flexible, powerful, and packaged with a plethora of encryption and authentication options, DirectAccess decisively lacks the comprehensive features to be an all-in-one solution. Aside from only running on Windows 7, this “flexible alternative” is, ironically, more than a little inflexible when it comes to implementation, with a list of requirements a mile long, including mandatory IPv6 implementation.

Proponents of DirectAccess might postulate that it’s possible to circumvent the “mandatory IPV6 rule” by installing Microsoft’s Forefront Unified Access Gateway over DirectAccess to handle VPN requirements- installing most of the required infrastructure for DirectAccess in the process, as well as NAT64 and DNS64.

Of course, this brings to the table a whole new gallery of issues, mostly related to flexibility and client management.

If you decide to install UAG so that you can use DirectAccess over IPv4, The built in firewall will be disabled  and the Microsoft Forefront Threat Management Gateway will install. This offers full support for IPv4 — but no support for IPv6.  Not only that, NAT64 offers no support for reverse NAT mapping- so client management becomes a considerable challenge.

On the other hand, if you install DirectAccess into Windows Server 2008, the built-in firewall will be able to support IPv6. Unfortunately, this comes with a rather crippling caveat —  the firewall will only enable inbound or outbound rules.  In other words, you won’t be able to get any IPv6 traffic past the server.

Either way, there’s the potential to cripple- or at least considerably hobble- your network in some way. This is particularly true if you’re using a non-Microsoft firewall for security. If you are, well…good luck implementing DirectAccess. You’ll need it.

The fact that DirectAccess absolutely requires Windows 7 and Windows Server 2008 R2 with PKI access is extremely problematic for any non-Microsoft devices- and that includes mobile devices. Consider that for a moment- if you’re using a tablet or smartphone, you’re going to have a very, very difficult time connecting via DirectAccess. Even Microsoft’s own mobile offerings are, at the current juncture, incompatible.  This is a huge hurdle, especially in age when many are trumpeting mobile as the future of enterprise.  DirectAccess, meet the Bring Your Own Device craze. You two aren’t going to get along.

The World After IPv6 Day: A Conversation with Comodo’s Paul Lee

We’re happy to report the Internet is still standing nearly a week after IPv6 Day. More than 400 organizations — including heavyweights like Google and Facebook – enabled the much talked-about IPv6 standard on their websites. Overall, no major outages were reported. Now what? Well, Facebook plans to leave its developer site dual-stacked, supporting both IPv4 and IPv6 and Google will enable IPv6 access for only the users of its Google over IPv6 program.

At VPN Haus, we spoke with Paul Lee, director of IT at Comodo, about what his company learned from IPv6 Day.

VPN Haus: Can you tell me how Comodo enabled its main page to IPv6 enabled?

Paul Lee: We implemented dual stack on both the webservers (our NGINX platform that runs them), the kernel of said machines, firewalls and all of our core and edge Juniper comms equipment. We used GRE tunnels internally. [Comodo enabled 22 sites, in addition to its main page.]

VPN Haus: What are the key issues and lessons that came to light as a result of this experiment – both for Comodo and on a higher-level for all participating organizations?

Lee: When taking full routes from upstream providers, IPv6 has a lot more address space and so simple things like more RAM for routers is needed to hold the greater number routes (as IPv6 adoption takes hold, this will be a bigger problem). Ensuring that the kernel of machines is IPv6 enabled as well as any software running on them (can cause unforeseen issues).

We learned that adoption is very small at the moment, with a greater proportion of users in Japan, due to their poorer IPv4 to headcount ratio (hence a greater incentive to adopt than the U.S.).

VPN Haus: How has Comodo been preparing for IPv6?

Lee: Ensuring routers are compliant, upgrading Linux kernels to handle IPv6, procuring IPv6 transit links from upstreams and testing (some upstreams see more routes than others…you know who you are!) and ensuring content and applications are not hardcoded to IPv4 in any way, if so, changing that or tabling changes for the near future.

VPN Haus: Do you think security risks around IPv6 are overrated? Isn’t this more of an infrastructure issue right now?

Lee: The long overlap period of dual stack networking will undoubtedly increase the potential for security vulnerabilities, due to the necessary interaction of two separate fundaments, each with their own specific security problems. It must be said though, that most of the issues which may be talked about are not a direct result of IPv6 design flaws but of misconfiguration in this transition environment.

Aside from the problems a dual stack environment causes, this issue of security is one of my personal interests in the change. As you know, IPv4 uses NAT extensively. It is a widely held assertion that NAT will protect a network / endpoint better than a machine on the end of a routable IP. I would voice a rebuttal to this, in that any basic firewall rule which tracks and requires an associated outbound connection to be present for an inbound connection to be allowed will give one the same security as NAT. I can see that some may believe that there will be the same issues as the consumer would have with Home Wireless Security (i.e. that home routers were shipped without security initially and likewise, the world will take time to catch up and most home users don’t manage their security well), this is where the real lessons will need to be learned.

If people lose the perceived protection of NAT or if they aren’t aware or don’t want to have to be aware of their firewall rules, security will be pushed to the edge, people will be encouraged to take responsibility of their own security at the point which matters to them, their machine. Empowering people to secure their own machine, not trusting that somehow their cafe wireless Internet connection is protecting them, will be the word of the day and I welcome that day.

VPN Haus: Does IPv6 still require IPsec? If not, why was that change made and what impact will that have on IPv6 security?

Lee:  IPsec is an intrinsic part of IPv6. Also, since IPv4 IPsec is so very widely implemented and supported, IPv6 IPsec is deployable pretty much out of the box. A lot of this was driven by government edicts over the last few years, but underlying infrastructure manufacturers have been baking in support for IPv6 IPsec since after Y2K.

What We’re Reading, Week of 12/13

Internet News, OpenBSD Backdoored by the FBI?
Computerworld, Look, It Makes Them FEEL More Secure, OK?
Network World, What You Should Know About Next Generation Firewalls
Enterprise Network Planet, IPv4 Space Continues to Dwindle