Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a little specific problem here that I want (need) to solve in a satisfactory way. My company has multiple (IPv4) networks that are controlled by our router sitting in the middle. Typical smaller shop setup. There is now one additional network that has an IP Range OUTSIDE of our control, connected to the internet with another router OUTSIDE of our control. Call it a project network that is part of another companies network and combined via VPN they set up.

This means:

  • They control the router that is used for this network and
  • They can reconfigure things so that they can access the machines in this network.

The network is physically split on our end through some VLAN capable switches as it covers three locations. At one end there is the router the other company controls.

I Need / want to give the machines used in this network access to my company network. In fact, it may be good to make them part of my active directory domain. The people working on those machines are part of my company. BUT - I need to do so without compromising the security of my company network from outside influence.

Any sort of router integration using the externally controlled router is out by this idea

So, my idea is this:

  • We accept the IPv4 address space and network topology in this network is not under our control.
  • We seek alternatives to integrate those machines into our company network.

The 2 concepts I came up with are:

  • Use some sort of VPN - have the machines log into VPN. Thanks to them using modern windows, this could be transparent DirectAccess. This essentially treats the other IP space not different than any restaurant network a laptop of the company goes in.
  • Alternatively - establish IPv6 routing to this ethernet segment. But - and this is a trick - block all IPv6 packets in the switch before they hit the third party controlled router, so that even IF they turn on IPv6 on that thing (not used now, but they could do it) they would get not a single packet. The switch can nicely do that by pulling all IPv6 traffic coming to that port into a separate VLAN (based on ethernet protocol type).

Anyone sees a problem with using he switch to isolate the outer from IPv6? Any security hole? It is sad we have to treat this network as hostile - would be a lot easier - but the support personnel there is of "known dubious quality" and the legal side is clear - we can not fulfill our obligations when we integrate them into our company while they are under a jurisdiction we don't have a say in.

share|improve this question
add comment

1 Answer

This is a situation I've run into often, and I pretty much always do the same thing: IPSec.

Whether it works for you is dependent on whether there's an IPv4 overlap between their network and yours, which you don't say. But I know you have clue, and if there was this additional hurdle I think you'd've mentioned it, so let's assume for now that there isn't any overlap.

Set up an IPSec tunnel between their core router and yours, using PSK authentication. Most good routers will speak it, and it's not hard to do. Once you have a tunnel in place, you can trust the identity of any packets that come down it (note: I'm not saying you can trust the content of the packets, only that you can be sure they really do come from Potentially-Hostile Partner).

So then you can apply access filters to traffic coming out the tunnel, and precisely restrict what hosts on your network they have the capability to access, and on what ports, and from which machine(s) at their end (though that latter restriction is less useful as you have no control over whether devices on their network are maliciously changing ther IP addresses to elevate their access rights to your end).

Linking the networks, rather than having any random trusted client at their end use an individual VPN client, works better in my experience, not least because you'll either end up with a full-time job managing client access tokens - issuing new ones, revoking old ones, grumbling about people copying them or dealing with the fallout of mandating that any token can only be used once - or you'll issue one token that everyone will use, and you'll have lost any control over who's using it and where they're using it from. It also means that the complexity is in the core, where it's best managed.

I've had some such tunnels, between my networks and those of the PHPs, running for a decade, and they just Do Their Thing. From time to time someone needs a new machine on their end able to access some new dev box or other resource on our end, and it's a simple change to an interface access list, a one-line fix to my own kit that I can do in seconds, and everything is working. No client installs. No endpoint complications at all.

I find the v6 idea fascinating, but I suspect that it'll run onto the rocks when some v4-only client, or something riddled with v6 bugs because it's so untested, comes along and really-really-really-pretty-please needs access to your network resources.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.