[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec through firewalls (was re:INITIAL-CONTACT issues)

The 3 situations Scott has described are actually system integration
strategies that administrators can use with VPN devices.  As a field
engineer for a VPN company who has integrated many systems in customer
locations, I feel that I can provide a real world view of this issue.  If
this is off topic, my apoligies to the list.

The objection sysadmins have to two of these strategies - parallel and
behind the firewall - are because policies that control application level
traffic bypass the firewall. Additionally, because the firewalls typically
control TCP/UDP packets, sysadmins have trouble establishing policies for
IPSec packets (IPSEC 50/51) in the firewall.  Integrating in front of a
firewall is problematic when the firewall controlls access from public
networks to private networks (eg 10.x.x.x networks).  

There is a fourth integration method that has been successfully used.  This
implementation is to insert a third NIC in the firewall, create a
trusted/private network, and connect the VPN device to that third NIC.  The
sysadmins are able to establish policies to application traffic that comes
through the VPN.  However, sysadmins who object to "fiddling" with their
operational firewall usually end up adopting the parallel method.

Integrating a VPN device behind a firewall has been found to be problematic
when NAT is implemented as a firewall policy.  I have found that working
with devices that provide AH header & ESP trailer, and provide the ability
of the administrator to generate a NULL digital signature for packet level
authentication have proven to be successful.  I can hear the howls now.
Customer education is very important here because the ramifications of
establishing such a policy must be explained to the customer.  Having been
educated, the administrator is then able determine if the implementation of
such a policy with respect to VPN traffic is acceptable.  Such an
implementation works mainly for site to site VPNs, and has been found to be
problematic with remote access VPN implementations.





At 06:49 AM 5/8/99 -0700, Scott G. Kelly wrote:
>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
References: