On Wednesday, February 12, 2003, at 10:40 AM, David Wilburn wrote:

I've been attempting to beef up my knowledge of IPsec recently, and got to thinking hypothetically about a *possible* problem with implementing IPsec on larger networks. My experience with IPsec is currently limited at best, so hopefully I can communicate this properly:

Let's assume that I have a large-ish network with multiple connections to the Internet and ambiguous routing (meaning that a packet might come in one gateway and the response packet might leave through a different gateway). Let's also assume that I'd like to allow IPsec tunnels into my network to allow single workstations and small networks to attach to mine.

With such ambiguous routing, is my understanding correct that the response traffic could potentially bypass the VPN concentrator altogether and travel to the destination unencrypted?

Well, if it's routed then it's reachable, whether or not the packets are encrypted or unencrypted. But, that doesn't mean the unencrypted traffic needs to be permitted beyond your gateways. The security association includes the source address, so you can create policies that disallow traffic except from expected hosts. As for ambiguous (asymmetric?) routing, the tunnel is, for all intents and purposes, unaware of the underlying transport architecture, so it shouldn't make any difference as long as you have decent performance on your network as a whole. We use IPSec tunnels across the internet all the time and they work great.

Are there any solutions for quickly, reliably, and securely sharing IPsec Security Association databases between gateways, so that the other gateways would know to encrypt the traffic before letting it out?

How about setting up your own Certificate Authority. Mike ------------------------------------------------------------------------ -- Michael K. Smith NoaNet 206.219.7116 (work) 206.579.8360 (cell) mksmith@noanet.net http://www.noanet.net

On Wed, 12 Feb 2003, David Wilburn wrote:

Let's assume that I have a large-ish network with multiple connections to the Internet and ambiguous routing (meaning that a packet might come in one gateway and the response packet might leave through a different gateway).

We usually call this "asymmetric routing".

With such ambiguous routing, is my understanding correct that the response traffic could potentially bypass the VPN concentrator altogether and travel to the destination unencrypted?

This can only happen if the routing decisions are made before the encryption is done. (And there would probably have to be another problem.)

Is there any best practices advice for dealing with IPsec on such a network, or am I stuck with either "redesign your network architecture" or "don't allow IPsec?" From what I can figure, those last two options are my best bet, unless I want to allow lots of VPN concentrators deeper within the network where the routing is less ambiguous.

I would prefer a situation where the end systems do their own crypto (transport mode rather than tunnel mode) because there aren't any additional boxes in the middle that can screw up the security or break connectivity. But this is probably not an option. If you need to depend on external boxes, you must first decide whether any set of hosts can only use a single VPN box or if they can use several. In the first case you need to place this box somewhere where the traffic for the hosts you are protecting always passes through. In a good network design this will be *very* close to these hosts. If you can use several, then you probably want to have at least two for redundancy and place them just after your connections to the outside world. Presumably, in tunnel mode the hosts you are communicating send traffic back to the address found in the outer IP header = the originating VPN box, so this will make traffic for individual sessions symmetric.