[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec through firewalls (was re:INITIAL-CONTACT issues)
These are really 2 different discussions: one pertains to the IKE
transport mechanism, and the other pertains ipsec/firewall issues. I
think the two are independent, so I split them. It seems to me that
firewall administrators are almost always going to be uncomfortable with
letting *anything* through, given that it is their competence which is
questioned should a breach occur.
Again, we have the 3 situations I described in an earlier email, and I
think the only problematic situation is when an end-user behind a
firewall wants to establish (or permit) a secured session *through* the
firewall. Some administrators simply refuse, saying "I can't see what's
in the encrypted traffic, and that's unacceptable". I see no solution in
this case, since they do not trust their internal systems/users. Tough
situation.
For clarity, here's a picture:
+-----+ +----+ +-----+
| E1 |--------| FW |===INTERNET====| E2 |
+-----+ +----+ +-----+
The users are E1 and E2, the firewall is FW. E1 wants to establish a SA
pair with E2. The admin of FW is afraid to simply permit the encrypted
flow.
Some administrators may be willing to permit the session if they can
authenticate E2 (and perhaps E1). This requires ipsec support in the
firewall, which eventually all firewall-type systems will support (I
think). In this case, the firewall will in any event establish a secured
session with the external endpoint, through which the traffic between
the endpoints will flow. That looks like this:
+-----+ +----+ ipsec tunnel +-----+
| E1 |--------| FW |===============| E2 |
+-----+ +----+ +-----+
The final decision pertains to whether or not E1 and E2 may exchange
encrypted (or even authenticated) traffic. If the answer is no, then E1
could still get some additional protection by establishing a tunnel to
FW in which E2's traffic is carried. If the answer is yes, we're done.
Scott
Follow-Ups:
References: