Re: IPsec with ambiguous routing

[Iljitsch van Beijnum <iljitsch () muada com>]

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.