[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec through firewalls (was re:INITIAL-CONTACT issues)
Firewall Q:
Firewall? What firewall?
I know it is a leap of faith, but folk will just have to get used to
trusting their IPSEC security gateways. If you can get that far, then you
don't need a Firewall for the IPSEC tunnel traffic, so you don't have to
poke holes.
If you want to share an Internet connection for Firewalls and Security
Gateways, you can set them up in parallel:
(hope this line picture comes out...)
Internet====Packet-Filter Router--------Firewall-----Intranet
|
-----SG----------Intranet
i.e. the Firewall and SG both have exposure to whatever gets past the rough
packet filtering of the Internet-connected router.
Any application level policy can be either part of the IPSEC policy, or
implemented 'out-side' IPSEC in a firewall style.
Another option used by some is to feed the 'Intanet' tap of the SG back into
the firewall, it all depends on what sort of policies are in place for
'private' traffic - after all, the IPSEC Tunnel should be providing the
equivalent of a leased line connection to a remote office - typically there
is no restriction on this traffic. In the case of Extranet links to
partners, then you have more of a problem.
My suggests would be (not that I know squat about firewalls):
For 'private' tunnels, use an SG in parallel with simple level 2 policy.
For Extranet tunnels, use an SG in parallel or use tunnel support within the
firewall (if any). For the parallel SG case, either make provision within
the SG for additional policy control, or feed Extranet tunnels back into the
firewall (as mentioned by another noter).
TCP Q:
There do seem to be some cracks showing in IKE connection phase (we have
been using a lot of IKE duct-tape lately). I guess it would not take us too
long to get IKE running over TCP instead - it may be worth a try, and we may
even offer the option for like-to-like running, if it makes life easier.
Steve.
From: Scott G. Kelly [ mailto:sgkelly@ix.netcom.com
<mailto:sgkelly@ix.netcom.com> ]
Sent: Saturday, May 08, 1999 2:49 PM
To: Alex Alten
Cc: Stephen Kent;
Subject: 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: