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

[FW-1] [Fwd: SecuRemote in FW NG at ADC]

Here is my experience of upgrading from 4.1 SP5 on Solaris 7
to NG FP3 on Solaris 8.

This is SecuRemote specific.


Calder.Chung wrote:
 > Hello,
 >
 >             I�m using CheckPoint FW1 ver 4.1, and we�re planning upgrade
 > to NG-FP3, any things I need to do before the upgrade ?
 >
 >             Can the NG use 4.1�s rules and objects?
 >
 >             Is it just upgrade in the 4.1 version system, and I�ll
 > upgrade automatically ?
 >
 >
 >
 >             Have you do that before (Upgrade to NG FP3) ?
 >
 >
 >
 >
 >
 > Best Regards,
 >
 > Calder Chung
 >
 > Systems Support Engineer
 >
 >
 >
 >



DETAILS -- Make SecuRemote work at ADC.

1.      SecurID authentication.  The admin who knew too much.
        Even thought SecurID is used to authenticate telnet and
        ftp access to the node, FW SecurID had different expectations.
        I had to create the directory /var/ace and links to the right
        files for Firewall based SecurID to work.

        a.  ACE uses phrases in the file, /etc/sdace.txt, to point to
        ACE authentication data.
                VAR_ACE=/opt/ace/data
                USR_ACE=/opt/ace/prog
        b.  Checkpoint ASSUMES that the files, sdconf.rec and securid
        are in the directory, /var/ace.
        mkdir /var/ace
        ln -s /opt/ace/data/sdconf.rec /var/ace/sdconf.rec
        ln -s /opt/ace/data/securid /var/ace/securid

        I made the change on nyland to make SecurID authorized administration
        work.

2.      generic*.  I had to set the authentication of the External User Profile,
        generic*, to SecurID Authentication.  The 4.1 upgrade to NG also
        carried an object, Generic*.
        a.  Delete the user object, generic*, from 4.1
        b.  Set authorization to SecurID on the External User Profile
            Add the SecurID groups to this profile

3.      Define Encryption domain for diamond2
        Define the FW group object, ADC_VPN_WAN, and include the encryption
        domain groups for all of the past firewalls at ADC
        Add diamond2 to the FW rule for encryption.

4.      Permit authentication for topology download.
        The old nyland did not require authentication for SecuRemote topology.
        Authentication is mandated by SecuRemote NG.  A dbedit is needed.
        Solution ID: sk14628
        Using dbedit on the management console, modify the
        allow_clear_gettopo property to false. The commands in dbedit are:

        dbedit
        modify properties firewall_properties allow_clear_gettopo false
        update properties firewall_properties
        quit

https://support.checkpoint.com/advanced/idsearch.jsp?id=sk14628&QueryText=%28%22topology%22+AND+%22data%22%29&;

5.      Define DNS SecuRemote Servers
        ingate and ingate3 were already defined, so just define two new servers,
        SR_DNS_ingate and SR_DNS_ingate3
        Define the domains, adc.com, basystems.com, and pairgain.com as being
        served by these DNS servers.

6.      Check "Encrypt DNS traffic".  The option is obvious, but took a long time
        to find.
        Policy --> Global Properties --> Remote Access, about 2/3 down the screen.

7.      FIND and work around BUG in Checkpoint topology and routing.
        Even though the encryption domains are right, userc.C was right,
        the remote client kept trying to connect to 155.226.8.1, the INTERNAL
        interface of the gateway, diamond2. !!

        Well the problem is in the Anti-spoofing topology statement of the
        internal interface.
        On the Topology page of the gateway, diamond2, the VPN domain can be
        defined as 'All IP addresses behind Gateway based upon Topology information'
        OR Manually defined as ADC_VPN_WAN (my choice).  The OR does not work,
        The setting is ALWAYS 'All IP addresses....'  I had to change the topology
        for the anti-spoofing rules to match the encryption domain.
        Then VPN worked via the external address of the firewall., 155.226.255.27

8.      STILL live with routing problem of IP Pool NAT's SecuRemote Clients.

        SecuRemote users behind DSL routers and cable modems could NOT have the
        same address as are used inside ADC.  Subnet 10 users are especially vulnerable.
        The problem is unexpected since the SecuRemote user is publicly NAT'd by the
        user's router, and the user is IP_Pool_NAT'd at the gateway.
        Well, the gateway would still see the hidden address of the user's desktop
        and route the ENCRYPTED traffic based upon the hidden address, NOT the
        public NAT'd address of the user.   Aaarrrrrghhh!

        So, SecuRemote users will have to stay in 10.0.0.0 addresses that are
        not used inside ADC.  192.168.0.0/16 is the best choice.

greg

_______________________________________________________________
Greg Polanski                    mailto:[email protected]
ADC Telecommunications, IncMSFAX
PO Box 1cell/pager
Minneapolis, MN  [email protected]
_______________________________________________________________

=================================================
To set vacation, Out Of Office, or away messages,
send an email to [email protected]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[email protected]
=================================================