RE: CheckPoint Firewall-1/VPN-1, SecuRemote, Exchange Serverand Outlook

["Adam Hudson" <adam () inergy net>]

Actually, the problem really is caused by some design flaws in
SecuRemote, FW-1 IP NAT Pool and MS Exchange Server.  

Here are the CheckPoint issues:

1. The VPN infrastructure in Firewall-1 is really designed to allow
inbound connections from the client workstations.  It is not designed to
allow traffic originating from the protected network to the clients.  In
other words, there are no state mechanisms or methods of rule building
for outbound traffic (see next two points).  See the PhoneBoy FAQ for
more information, http://www.phoneboy.com/faq/0164.html

2. The IP Pool NAT feature available for SecuRemote connections is
completely inadequate.  The translation of the SecuRemote traffic
happens prior to an evaluation on the rulebase, therefore building a
rule to allow traffic destined to the NAT pool (as you would naturally
want to do) does not work.  The packet is translated to the "whatever
SecuRemote address" before your rulebase gets control to allow it.  This
is also evident in the CP Log Viewer, as the client's IP address is what
is used, instead of the pool assigned address. Furthermore, when a
SecuRemote client actually conducts traffic destined for the firewall
itself (ie. SSH to Nokia IPSO), the translation doesn't happen at all!

3. When utilizing SecuRemote from behind a NAT device, the client uses
UDP encapsulation.  This causes the firewall to truly see the client as
the private address it possesses behind the NAT device.  


Now that we have outlined the above three problems, let's apply it to
the operation of Exchange Server (which is somewhat bad design also):

* Microsoft Exchange server uses a dynamic set of ports for inbound MAPI
connections (Outlook clients).  By default this is a problem, but they
can be nailed down by registry settings to allow control via the
firewall.

* The new mail notification feature is achieved by the Outlook client
informing the Exchange server of its IP address somewhere in the MAPI
communication payload.  From that point forward, the Exchange server
sends UDP packets greater than port 1024 to that IP address to notify
the client when a new message has arrived.

* Simply allowing high port UDP communication outbound from the Exchange
server does not work.  This is because you cannot nail down the
Destination side of the rule for SecuRemote clients as there is no "User
Access" specification allowed on the destination.  You cannot target the
IP NAT Pool as the destination because of the translation problem (see
item 2 above).  And, last but not least, you cannot specify the
SecuRemote clients by IP address, because they can come from anywhere on
the net!

* Allowing high port UDP communication from the Exchange server to ANY
destination is a bit of a security risk, but won't get the job done
either.  Uninitiated traffic to the SecuRemote client gets accepted by
the rule base, logged and possibly sent down the tunnel.  However,
either the SecuRemote client doesn't actually allow it to be processed,
or FW-1 doesn't actually send it down the tunnel.  I have not spent the
time with Sniffer to figure this one out fully.


Aside from the MS Exchange Server issue we have been discussing, there
is one additional and deadly problem with SecuRemote.  When a user is
connected to the VPN via IKE over UDP, their private address is used by
the firewall for communication.  For example, let's say the client was
using 10.0.0.1 (which is somewhat common).  For the duration of their
session to the firewall, another client using the same private IP
address from behind a NAT device cannot also connect.  Why?  Because the
firewall truly knows you as the 10.0.0.1 address and not your NAT hide
address (from client side NAT device), nor your IP NAT Pool address.  If
the user is utilizing a public IP address, everything is fine.  The
failing topology would look like this:

 [Client 1] --- [NAT dev]----+
 10.0.0.1                    |
                             INET---[FW-1]
                             |
 [Client 2] --- [NAT dev]----+
 10.0.0.1



All of this information pertains to the 4.1 SP5 platform.  I have not
had time to test under the NG release.  

Adam Hudson
Networking and Security Consultant
Office 720-348-0564
Fax 720-294-0778


-----Original Message-----
From: Patrick Archbold [mailto:patrick.archbold () schenkerusa com] 
Sent: Tuesday, January 08, 2002 1:32 PM
To: Adam Hudson
Subject: RE: CheckPoint Firewall-1/VPN-1, SecuRemote, Exchange Serverand
Outlook

Adam,
Thank you for reading this.  I saw your postings regarding the
securemote / outlook / exchange problems.  I am having the exact same
problem.  I was wondering if you ever found a solution to the problem?
Thank you for your time.

Patrick Archbold
IT Infrastructure Manager
Schenker IT
150 Albany Ave
Freeport, NY 11520
516-403-5455


_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards