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?
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.
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?
Any other relevant thoughts, experiences, insults, rude gestures, etc.?
Thanks!
-Dave Wilburn
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
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.
I had exactly this problem - consider the situation where site a and
site b are branches of the same company, each with its own internet
gateway and site b has resources site a must (due to head office edict)
use. Now consider vpn users of site a, who must use resources from site
b. not only is it likely that replies go via the site b gateway, but it
is impossible for them *not* to - to the extent that, as site b's
firewall sensibly doesn't allow outbound packets to random destinations,
no replies are ever received at all.
The solution was fairly simple - inbound VPN users are transparently
NATted to a block of addresses in the "site a" range, and therefore
replies, looking as they do to be sourced from site a, are returned to
the firewall at site a for vpn encapsulation and dispatch.