ATRG_NGX

Advanced Technical Reference Guide

NGX (R60)

For additional technical information about Check Point products, consult Check Point’s SecureKnowledge at:

https://secureknowledge.checkpoint.com/

May 11, 2006

ATRG_NGX.book Thursday, May 11, 2006 8:28 AM

https://secureknowledge.checkpoint.com/


© 2003-2006 Check Point Software Technologies Ltd.

All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.

TRADEMARKS

©2003-2006 Check Point Software Technologies Ltd. All rights reserved.

Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, Cooperative Security Alliance, Eventia, Eventia Analyzer, Eventia Reporter, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, QoS, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, User-to-Address Mapping, UserAuthority, VPN

VPN Accelerator Card, VPN Edge, VPN-1 Pro, VPN-1 Pro SecureClient, VPN-1 Pro SecuRemote, VPN-1 Pro SecureServer, VPN-1 Pro VSX, VPN-1 Pro XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone Labs logo, are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.

THIRD PARTIES

Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust’s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust.

Verisign is a trademark of Verisign Inc.

The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided “as is” without express or implied warranty. Copyright © Sax Software (terminal emulation only).

The following statements refer to those portions of the software copyrighted by Carnegie Mellon University.

Check Point Software Technologies Ltd.U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, [email protected] Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com


Copyright 1997 by Carnegie Mellon University. All Rights Reserved.

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The following statements refer to those portions of the software copyrighted by The Open Group.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;


OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright © 1998 The Open Group.

The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it is useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General

Public License for more details.You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-distribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-RR02188 by the National Institutes of Health. Portions copyright 1996, 1997,


1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson ([email protected]). Portions relating to gdft.c copyright 2001, 2002 John Ellson ([email protected]). Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

The curl license

COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 1996 - 2004, Daniel Stenberg, <[email protected]>.All rights reserved.

Permission to use, copy, modify, and distribute this software for any purpose

with or without fee is hereby granted, provided that the above copyright

notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.

The PHP License, version 3.0

Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.


2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].

4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version is given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

6. Redistributions of any form whatsoever must retain the following acknowledgment:

"This product includes PHP, freely available from <http://www.php.net/>".

THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at [email protected].

For more information on the PHP Group and the PHP project, please see <http://www.php.net>. This product includes the Zend Engine, freely available at <http://www.zend.com>.

This product includes software written by Tim Hudson ([email protected]).

Copyright (c) 2003, Itai Tzur <[email protected]>

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN


NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.

Confidential Copyright Notice

Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are breached. Upon termination, any downloaded and printed materials must be immediately destroyed.

Trademark Notice

The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual property rights to the fullest extent of the


law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution of, or access to, materials in

this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 222 1600.

U.S. Government Restricted Rights

The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are

restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in Data-General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial

Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).

Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of the original creator. The Contractor/Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations.

Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty

THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO

THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRANTIES,

EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE RESPECTING, THE MATERIAL IN THIS DOCUMENT.

Limitation of Liability

UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU.

Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.

BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC"))


Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release

PCRE LICENCE

PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. Release 5 of PCRE is distributed under the terms of the "BSD" licence, as specified below. The documentation for PCRE, supplied in the "doc" directory, is distributed under the same terms as the software itself.

Written by: Philip Hazel <[email protected]>

University of Cambridge Computing Service, Cambridge, England. Phone:

+44 1223 334714.

Copyright (c) 1997-2004 University of Cambridge All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

* Neither the name of the University of Cambridge nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER

OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

ATRG_NGX.book Page i Thursday, May 11, 2006 8:28 AM

Table Of Contents

PrefaceScope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWho Should use this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixLinks to SecureKnowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixTroubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Section 1:SmartCenter

Chapter 1 Debugging and MonitoringIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Debugging Firewall NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Debugging fwd and fwm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Debugging Security Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Debugging Kernel Modules Using fw ctl debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Debugging VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10fw module Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11vpn Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12fg (QoS) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13uag (User Authority) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14rtm (SmartView Monitor) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14strmod Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Debugging cpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Debugging VPN-1 Pro, DTPS, and DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Debugging VPN-1 Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Debugging dtps (Desktop Policy Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Debugging dtls (Desktop Log Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Debugging GUI to SmartCenter Server Communication . . . . . . . . . . . . . . . . . . . . . . . . .18

Monitoring VPN-1 Pro NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19cpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19cpwd_admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19cpinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

fw monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Basic Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Additional Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Chapter 2 Secure Internal CommunicationsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Troubleshooting SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Table of Contents i

ATRG_NGX.book Page ii Thursday, May 11, 2006 8:28 AM

Debugging SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Resetting SIC on a Security Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Known SIC Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31‘Cannot Rename Firewall Object’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31‘Could not Resolve Peer Name’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32‘Failed to Connect the Module’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3 Open Security ExtensionIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Nortel (Bay) Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Configuring an SNMP Password on Nortel (Bay) Router . . . . . . . . . . . . . . . . . . . . . . . . 34Further Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Cisco Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Cisco Router Version 9 and 11 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Common Issues and Resolutions (Cisco) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Debugging Cisco Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Allowing TFTP ACL Policy Installation from SmartCenter Server . . . . . . . . . . . . . . . . 38Creating and Installing a Policy using a Command Line . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 4 SmartUpdateDebugging Licensing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Debugging Licensing Commands On Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Debugging Licensing Commands On UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Debugging Communications Between SmartUpdate GUI Client and SmartCenter Server . 43To Debug Attach and Detach Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43To Debug Import Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Adding a License to the SmartCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Remote Installation Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Pre-NGX Packages (BC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44NGX Packages and Beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 5 SmartMapIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Problems and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 6 Web IntelligenceIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Application Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Monitor only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

The ActiveStreaming Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Web Intelligence Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

ii

ATRG_NGX.book Page iii Thursday, May 11, 2006 8:28 AM

Debugging and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Enhanced Debugging Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Running Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Some debugging tips and tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Known Issues with Web Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Chapter 7 LDAP Servers and SmartDirectoryIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

New Features in VPN-1 Pro NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Introduction to SmartDashboard User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

SmartDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63LDAP Schema in NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Modifying the Netscape Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Troubleshooting LDAP Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64LDAP Troubleshooting Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Modifying the Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Updating the Registry Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Delegating Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65Adding New Attributes to the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Issues with Active Directory and NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Section 2:VPN-1 Pro/Express

Chapter 9 Network Address TranslationIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Original Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Reply Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Translated Packets and the Connection Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Debugging NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

NAT Related Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Chapter 10 Security ServersIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Editing security server default messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Calculating CPU and Memory Used for Security Servers . . . . . . . . . . . . . . . . . . . . . . . .78

Transparent Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79What Does ‘Folding’ Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

TCP Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Checking Data Content Using TCP Resource for CVP Servers . . . . . . . . . . . . . . . . . . . .80Screening URLs Using TCP Resource for UFP Servers . . . . . . . . . . . . . . . . . . . . . . . . .81

HTTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82VPN-1 Pro HTTP Security Server and HTTP 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Table of Contents iii

ATRG_NGX.book Page iv Thursday, May 11, 2006 8:28 AM

Enhanced UFP Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Chunk Transport Encoding with Content Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Partially and Fully Automatic HTTP Client Authentication on Issues . . . . . . . . . . . . . . 84Rule Order for Content Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Troubleshooting security server performance issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Signature-Based URL Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

SMTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90SMTP E-Mail Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90The SMTP Security Server Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Improvements in SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Troubleshooting SMTP-Security Server Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Debugging SMTP Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

FTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Bidirectional FTP Data Connections not Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98PWD Command not Enabled on FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Adding Support for FTP Security Server Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Session Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Chapter 11 ClusterXLIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102ClusterXL Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Debugging Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Kernel Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

fwha_enable_if_probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104fwha_monitor_if_link_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105fwha_restrict_mc_sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106fwha_send_gratuitous_arp_var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106fw_allow_connection_traffic_drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107fw_allow_simultaneous_ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108fwtcpstr_reject_synced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109fwconn_merge_all_syncs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110The CPHA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115CPHA State Update Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Debugging CPHA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118ClusterXL Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chapter 12 Voice Over IP (VoIP)Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127mgcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127skinny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127MSNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127H.232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Using the Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128All Protocols Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

iv

ATRG_NGX.book Page v Thursday, May 11, 2006 8:28 AM

SCCP (Skinny) Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129MGCP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130MSN over SIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130SIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131H.323 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

Section 3:VPN-1 Pro and Desktop Security

Chapter 14 Internal Certificate Authority (ICA)Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136Initialization and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136PKI and PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137Recovery and Renewal with OPSEC Certified CA . . . . . . . . . . . . . . . . . . . . . . . . . . . .137Recovery and Renewal with Entrust CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138

Internal CA Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142InternalCA.C File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142Administrator Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143Benefits of the Internal CA Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144Batch Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

Internal CA High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146

Chapter 15 SecuRemote/SecureClientNAT Traversal for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148The NAT Traversal Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149Connecting to the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153Verifying the IKE Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Office Mode - IP Assignment from a RADIUS Server for SecureClient . . . . . . . . . . . . . .161Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161GUI Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164

Office Mode - DHCP Enhancements for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . .167Configuring the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168General Information and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169

Office Mode per site for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Why do we need this feature? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Enabling the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170

Office Mode per IP Range for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173Turning on the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175

Table of Contents v

ATRG_NGX.book Page vi Thursday, May 11, 2006 8:28 AM

MSI Package for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176What is MSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Supporting old InstallShield Package Abilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Improvements in the MSI Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

MEP and Interface Resolving Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Interface Resolving Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Resolving Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Manually Defined VPN List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184MEP Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

General Information and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Kernel Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Link Selection and Visitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Section 4:Additional Products

Chapter 17 SNXApplication Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Basic Hooking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Debug Logs - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196StaProxy & Sta logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Debug Log - Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Network Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Troubleshooting procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Chapter 18 InterSpectIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Latest features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Memory Management Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

fw ctl pstat utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Unified Memory Allocation Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Kernel Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Fail Open NICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Performance and Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Acceleration Basic Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Debugging SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Performance Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Policy Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Bridge Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Dynamic List Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Cooperative Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Troubleshooting SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Splat Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

vi

ATRG_NGX.book Page vii Thursday, May 11, 2006 8:28 AM

Chapter 19 ConnectraDebug Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226

Debugging the CVPND Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226Apache debugging processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227Debugging the Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228Debugging File Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

Using the TraceLogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229Debugging Web Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229

Chapter 20 Eventia ReporterIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231Eventia Reporter Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232

Log Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232Eventia Reporter Client Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232Eventia Reporter Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Licensing Eventia Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234Debugging Eventia Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235Log Consolidator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235SVRServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237My SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237Log Consolidator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238SVRServer Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240DBTableStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241GeneratorApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241

Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243Common Questions/Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244

Chapter 21 Eventia AnalyzerLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249db_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250Analyzer server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250Correlation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252

Section 5:Licensing

Chapter 23 LicensingIntroduction - the license_upgrade tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257clic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258Debugging License Commands on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258Debug License Commands on Unix/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260

Return code values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260

Table of Contents vii

ATRG_NGX.book Page viii Thursday, May 11, 2006 8:28 AM

Logs Files generated by the License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Provider-1 License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

viii

ATRG_NGX.book Page ix Thursday, May 11, 2006 8:28 AM

Preface

Scope

The Check Point Advanced Technical Reference Guide - NGX is intended to help System Administrators resolve common problems and implement complex features.

This guide contains information gathered from Technical Support's real-world experience in assisting customers. Each chapter was written by a specialist in the particular area. This guide does not duplicate user guides or courseware. It expands on information found in these guides, and provides additional key information.

The Advanced Technical Reference Guide is updated to VPN-1 Pro NGX, unless noted otherwise.

Who Should use this Guide

This guide is designed to assist people who integrate, support, and administer network security and virtual private networks, using Check Point Software products.

It assumes:• An understanding and working knowledge of VPN-1 Pro NGX• Familiarity with relevant user guides• An understanding of network-security architecture

Links to SecureKnowledge

The Advanced Technical Reference Guide contains many references to solutions in the Check Point SecureKnowledge database:

http://support.checkpoint.com/kb/index.html

Preface ix

http://support.checkpoint.com/kb/index.html

ATRG_NGX.book Page x Thursday, May 11, 2006 8:28 AM

SecureKnowledge is a self-service database of technical information, designed to assist in diagnosing and solving installation, configuration, and upgrade issues with Check Point Software products. To access a solution, log in to SecureKnowledge, and copy the solution ID into the SecureKnowledge search engine.

Troubleshooting

Troubleshooting VPN-1 Pro issues can be very complex. Issues are caused by network topologies, platform issues, and VPN-1 Pro features. Efficient troubleshooting starts with an organized plan.

Troubleshooting Guidelines

1 Define the problem as a list of symptoms.Every problem can be described as a collection of symptoms. The first step is to define these symptoms. Possible symptoms are error and log messages, malfunctions of certain modules, and user complaints.

2 Make sure you have as much related information as you can.Collect log and error messages, and other symptom descriptions. Collect related information from product user guides, release notes, and other sources. Verify that the modules involved are correctly configured.

3 Find a list of causes to every symptom.Using the gathered information, try to find as many potential causes as you can for every symptom. Put the most likely cause on the list first, and organize the rest accordingly.

4 Check the causes, one by one.Make sure you initialize your environment setting before testing. Go from the most likely cause to the least.

5 Consult other reference sources.Release notes, Web sites, mailing lists, and Check Point Technical Support. These can be reached from the Check Point Support Services site, at:http://www.checkpoint.com/techsupport/

Gather Information for Support

Before contacting Technical Support, gather all necessary information about the issue. The required files for each topic are listed in the relevant chapters of this guide.

x

http://www.checkpoint.com/techsupport/

ATRG_NGX.book Page 1 Thursday, May 11, 2006 8:28 AM

Section 1:SmartCenter


CHAPTER 1

Debugging and Monitoring

In This Chapter

Introduction page 4Debugging Firewall NGX page 5Debugging VPN-1 Pro, DTPS, and DTLS page 17Monitoring VPN-1 Pro NGX page 19fw monitor page 21

3

Introduction


IntroductionVPN-1 Pro NGX introduces significant architectural changes that simplify troubleshooting and debugging Check Point products. One of the most important enhancements is the distribution of processes and kernel functions.

VPN-1 Pro includes an executable (fw) that is in charge of most user mode functions, like logging, key exchange, security servers, Security Policy installation, and more. The functions are performed by several daemons, all of which are child processes of the Firewall daemon (fwd).

Two kernel modules are in charge of all VPN-1 Pro kernel mode functions, such as Network Address Translation (NAT), encryption, inspection, packet filtering, anti-spoofing and more. Another kernel file is in charge of Check Point QoS functions.

In VPN-1 Pro NGX, many user and kernel-mode responsibilities are assigned to different processes and kernel modules. This increases performance and simplifies pinpointing and debugging problems. For example, the VPN-1 Pro executable is in charge of all key-exchange and virtual private network (VPN-1 Pro) user-mode functions. The fwssd executable is in charge of all security server functions. The kernel mode also includes separate files for Firewall and VPN functions.

An advantage of this architecture is the ability to debug and troubleshoot VPN-1 Pro NGX, with no need to kill the daemons (this was necessary in earlier versions, which required the firewalled gateway to be down). With VPN-1 Pro NGX, Security Administrators need only to decide whether to write debug information or stop it. The command syntax is the same for Windows, Linux, and UNIX platforms, and is redirected to the same files under the $FWDIR/log directory, as explained in detail in the following chapters. It also allows the Security Administrator to focus on the exact entity causing a problem, knowing that it does not interfere with the operation of any other entity.

4

Debugging fwd and fwm


Debugging Firewall NGXThis chapter presents step-by-step instructions for debugging each of the following:• fwd (Firewall daemon) and fwm (SmartCenter Server daemon)• fwssd security servers• Kernel modules• cpd (Secure Virtual Network Foundation daemon)• vpn, dtps (Desktop Policy Server), and dtls (desktop Log Server)• SmartConsole to SmartCenter Server communication

In This Section

Debugging fwd and fwm

In Firewall NGX, there is no need to kill a daemon for debugging. Killing the daemon is necessary in earlier versions, such as VPN-1/FireWall-1 4.1. The only action necessary is to start (or stop) writing debug information. The command syntax is the same for Windows, Linux, and UNIX platforms.

Debugging fwd

To debug fwd, use the following commands:• To start writing debug information (flags are examples):

fw debug fwd on TDERROR_ALL_ALL=5

• To stop writing debug information:fw debug fwd off TDERROR_ALL_ALL=0

Debugging fwd and fwm page 5Debugging Security Servers page 6Debugging Kernel Modules Using fw ctl debug page 7Debugging VoIP page 10fw module Debug Options page 11vpn Debug Options page 12fg (QoS) Debug Options page 13uag (User Authority) Debug Options page 14rtm (SmartView Monitor) Debug Options page 14strmod Debug Options page 15Debugging cpd page 16

Chapter 1 Debugging and Monitoring 5

Debugging Firewall NGX


Debug output is automatically redirected to $FWDIR/log/fwd.elg.

To debug fwm, run the following command (flags are examples):• To start writing debug information:

fw debug fwm on TDERROR_ALL_ALL=5

or:fw debug fwm on OPSEC_DEBUG_LEVEL=9

• To stop writing debug information:fw debug fwm off TDERROR_ALL_ALL=0

or:fw debug fwm off OPSEC_DEBUG_LEVEL=0

Debug output is automatically redirected to $FWDIR/log/fwm.elg.

Debugging Security Servers

Debugging security servers is much easier in VPN-1 Pro NGX than in previous versions. The debug command is:fw debug <process_name> on <ENVIRONMENT_VARIABLE>=<Value>

Usage examples appear below. To obtain debug information related to the NGX environment, a connection related to the process you choose to debug must be initiated. If this is not completed, an error message appears when trying to run the command.

To verify that the process can be debugged, look in the $FWDIR\tmp directory for product identifiers (PID) of the desired process. The process can only be debugged if a PID file exists. Below are examples of PID files:• in.aftpd.pid - FTP security server• in.ahclientd.pid - Client Authentication on port 900 security server• in.aclientd.pid - Client Authentication on port 259 security server• in.atelnetd.pid - Telnet security server• in.ahttpd.pid - HTTP security server

Note - To set more then one environment variable at a time, use the version 4.1 method:fw kill fwd or fw kill fwm.

6

Debugging Kernel Modules Using fw ctl debug


Pay close attention to the debug information you require. For example, when the action in the Rule Base is Client Authentication, debugging the in.ahtppd PID (the environment variable for the HTTP security server) does not provide information for Client Authentication in Manual Mode. Instead, debug in.ahclientd.pid or in.aclientd.pid, to provide Client Authentication debug information.

The following examples demonstrate debugging the FTP and HTTP security servers. The same command syntax is used for Telnet, SMTP and rlogin.

To Debug FTP Security Server

Run the following commands:• To start writing debug information for FTP security server:

fw debug in.aftpd on FWAFTPD_LEVEL=3

• To stop writing debug information for FTP security server:fw debug in.aftpd off FWAFTPD_LEVEL=3

The debug output is automatically redirected to $FWDIR/log/aftpd.elg.

To Debug HTTP Security Server

To debug HTTP Security Server run the following commands:• To start writing debug information:

fw debug in.ahttpd on FWAHTTPD_LEVEL=3

• To stop writing debug information:fw debug in.ahttpd off FWAHTTPD_LEVEL=3


The kernel is composed of modules installed through the initial installation process. The kernel modules are:• fw module (Firewall), which includes the ha (High Availability) module.

Kernel debugging options: error warning cookie crypt domain ex driver filter hold if install ioctl kbuf ld log machine memory misc packet

q xlate xltrc conn synatk media align balance chain bridge tcpstr scv

ndis packval sync ipopt link nat cifs drop

• vpn module (VPN)Kernel debugging options: driver err packet policy sas rdp clear cipher init sr comp xl counters mspi cphwd ref vin cluster nat l2tp warn

• fg module (QoS)Kernel debugging options: driver error chain install tcp memory sched time policy url dns rtm dom auth log conn drops dropsv rates timers

chainq llq general verbose automatch autosched fwrate




• uag module (UserAuthority)• rtm module (SmartView Monitor)• strmod module (the NIC interface on Linux and UNIX platforms)• h323 module

Kernel debugging options: error init h225 h245 ras decode align• cluster Module

Kernel debugging options: conf if stat select ccp pnote log mac forward df pivot

Each module has many debug options. Each module option can be set separately, or with others. It is also possible to combine two or more modules. The buffer size is assigned for the kernel debug itself, no matter which module is selected. Minimum buffer size is 128 Kilobytes, and the maximum buffer size is 32,768 Kilobytes. To examine the usage, type:fw ctl debug -h

Usage

fw ctl debug [-x] [-m <module>] [+|-] <options | all | 0>fw ctl debug -buf [buffer size]

8



FW CTL debug options

To Debug fw Kernel Module Memory

1 Assign the minimum buffer size - 128 KB:fw ctl debug -buf

2 Assign the debug option memory for the Firewall module:fw ctl debug -m fw memory

3 Verify that the debug option memory is assigned to the Firewall module:fw ctl debug -m fw

To begin writing debug information to file_name, use the following command. Note that the redirect sign depends on the platform and the shell:• Windows CMD prompt:

fw ctl kdebug -f 2> <file_name>

• Windows in the 4NT shell and UNIX:fw ctl kdebug -f >& <file_name>

• Disable/clear all debug options:fw ctl debug -x

• Clean kernel debug buffer:fw ctl debug -buf 0

Option Explanation

-h Display usage for running kernel module in debug mode. If kernel module is specified, show the options for the module.

-buf [buffer size] Assign buffer size (in kilobytes) for the kernel debug.min buffer size = 128 KB; max = 32,768 KB.

-x Merge objects.C file-m <module> Assign the module to be debugged.+|- Add or remove a debug option.<options|all|0> Specify one of the following:

<option> for an option<All> for all options<0> to clear an option; <CTRL+C> stops debug.

The –x option does not require <CTRL+C>.




To Combine two Kernel Modules

1 Assign the minimum buffer size of 128 KB:fw ctl debug -buf <value>

2 Assign the memory option for the Firewall module (for example):fw ctl debug -m fw <option>

3 Assign the memory option for the VPN module (for example):fw ctl debug -m vpn <option>

4 Verify that the chosen <option> is assigned to the Firewall module (-m):fw ctl debug -m fw

5 Verify that the chosen <option> is assigned to the VPN module (-m):fw ctl debug -m vpn

6 Start writing debug information to file_name:fw ctl kdebug -f > <file_name>

On UNIX or Linux, use ‘&’ after the redirect sign: >& <file_name>

7 Disable/clear all debug options:fw ctl debug -x

• Clean kernel debug buffer:fw ctl debug -buf 0

To Add/Remove an Option to Kernel Module• To add a second option for the module (-m) fw:

fw ctl debug -m fw <option> + <option>

• To remove the second option for the module (-m) fw:fw ctl debug -m fw <option> - <option>

Debugging VoIP

For information about debugging VoIP, see chapter 12, “Voice Over IP (VoIP)” on page 125.

Note - If running this command on a Windows platform, put a 2 before the redirect sign: 2> <file_name>

10

fw module Debug Options


fw module Debug Options

Option Explanation

Error Default outputWarning Warnings can be suppressed, but are still printed by default,

except on SecuRemote/SecureClient.Cookie Cookie issuesCrypt Encryption issuesDomain Domain resolution issuesEx Table expiration (time-out)Driver Kernel attachmentFilter Policy installation, SAM, fw monitor, boot-time PolicyHold Held packetsIf Network interfaceInstall fw ctl install and uninstallIoctl IOCTLsKbuf Kernel buffersLd Dynamic tablesLog LoggingMachine Virtual machine operationsMemory Memory allocationsMisc Miscellaneous issues (especially licensing)Packet Actions on packets (especially KFUNCs called by INSPECT)Q Message queuesTcpseq TCP sequence number manipulationXlate NAT (including dynamic NAT)Xltrc NAT for complex services (such as FTP)Conn Connection table issuesSynatk SYNdefenderMedia ARP, non-IP packetsAlign H.323Balance Load balancing




vpn Debug Options

Chain Cookie chain and chain modulesBridge Currently unusedTcpstr TCP streamingScv SecureClient Verification

Option Explanation

Option Explanation

Driver Issues related to driver attachmentErr Errors that should not happenPacket Events that can happen for every packet, unless covered by

more specific optionsPolicy Events that happen only for a special packet in a connection,

usually related to Policy decisions or logs/trapsSas Keys and SA information printingRdp Handling of RDP packetsClear Dump of cleartext packet contentsCipher Dump of ciphertext packet contentsInit Issues relating to the initialization of the VPN moduleSecuRemote SecuRemote server-specific eventsMem Hardware-buffer managementLuna Events that happen when using the Luna cardCounters Status counters

12

fg (QoS) Debug Options


fg (QoS) Debug Options

Option Explanation

Driver Driver activation and attachment to the kernelError Different error messages; option turned on by defaultChain Tracing each packet through QoS points in the cookie chainInstall Policy installation and building internal data structureTcp TCP streaming mechanismMemory Failed memory allocationSched Basic scheduling informationTime Currently unusedPolicy Classification informationurl URL and URI for Quality of Service (QoS) classification

mechanismDns DNS classification mechanismRtm Failures in information gathering from SmartView Monitor

moduleDom (currently unused)Auth Authenticated QoS feature debug informationLog Logging informationConn Connection information and identificationDrops Dropped packets due to WFRED PolicyDropsv Same function as drops argument, with additional debug

informationRates IQ Engine behavior and statusChainq Holding and releasing packets during critical actions (Policy

install/uninstall)




uag (User Authority) Debug Options

rtm (SmartView Monitor) Debug Options

Option Explanation

Driver Informative messages about the UAG, such as IOCTL, connection, NAT

Error Displays error messages (when turned on)Uag_forward_ip NULL pointerUag_api_client (currently unused)

Option Explanation

Driver Displays general driver information (e.g., loading/unloading)Err Default arguments (always on by default) — Displays

critical errorsTopo Displays information about how the SmartView Monitor

calculates network topography by itselfPolicy Displays fw load/unload messages (The SmartView Monitor

received the Firewall callback.)Init (rarely used)Chain Displays information about chain registering, and about the

virtual-link chain function actions. This is an important argument that helps you know if the virtual link (VL) is identifying VL packets

Ioctl RTM ioctl printoutsImport Displays information about SmartView Monitor importing

functions from other modules (Firewall, QoS)Special Displays information about how the End-to-End (E2E)

modifies E2ECP protocol packetsRtm Displays information about SmartView Monitor monitoring

14

strmod Debug Options


Additional SmartView Monitor Debug Arguments (for NG FP1 and Higher)

strmod Debug Options

Option Explanation

Rtmpkt Displays per-packet information while SmartView Monitor is monitoring (a lot of output)

Netmasks Displays information about how the SmartView Monitor handles netmasks; useful when monitoring network objects

Kviews Kernel-view debugging (when opening/closing a GUI or command-line client)

Sort Debugging the SmartView Monitor top X monitoring sortingSort_stat Displays sorting statistics; useful for debugging algorithm

effectiveness

Option Explanation

Msg Messages in the stream queuesMsgerr Problems with handling messages from stream queuesIf Interface and Qdata informationIferr Problems with interface QdataFpack ACK from data link on fastpathFpnak No ACK from data link on fastpathOkack OK ACK from data linkErrack Error ACK from data linkState Data-link attachment stateOpen Opening or closing devices/queuesOpenerr Problems opening or closing devices/queuesFilter Streams module filter (such as fastpath)Ipmsg (unused)Ipctl IP control commandsOfterr Problems with OftabsOftab Oftabs information (oftabs hold interface data)




Debugging cpd

When establishing Secure Internal Communication between a SmartCenter Server and a Security Gateway:• Port 18192 is used for Certification Authority communications (status, issue,

revoke).• Port 18191 is used by cpd on the Security Gateway when it waits to receive the

certificate from the SmartCenter Server fwm process (when clicking Initialize in the Communication window of the workstation object).

To debug cpd, should issue the following command:cpd_admin debug on <Environment Debug Flag>=<Value>

For example:# cpd_admin debug on TDERROR_ALL_ALL=5.

To disable the CPD debug, issue:cpd_admin debug off <Environment Debug Flag>=0

Logs are automatically redirected to $CPDIR\log\cpd.elg.

Note - On UNIX and Linux platforms write setenv instead of set, and no = is needed.

16

Debugging VPN-1 Pro


Debugging VPN-1 Pro, DTPS, and DTLS

In This Section

Debugging VPN-1 Pro

Logs for these commands are automatically redirected to: $FWDIR/log/vpnd.elg

Debugging VPN-1 Pro page 17Debugging dtps (Desktop Policy Server) page 18Debugging dtls (Desktop Log Server) page 18Debugging GUI to SmartCenter Server Communication page 18

Option Explanation

vpn debug < on | off | ikeon | ikeoff >

Prints debug messages to VPN-1 Pro log files

vpn crl_zap Erases all Certificate Revocation Lists (CRL) from cache

vpn drv < on | off | stat > Attaches vpn driver to fw drivervpn ver [-k] Displays VPN-1 Pro versionvpn accel < on | off | stat [-l] > Operations on VPN-1 Pro accelerator

cardvpn crlview Debugging tool for CRLsvpn pkcs11 < add | remove | test | print>

Configuring PKCS11 device

vpn debug trunc Debugging VPNd and IKE

To stop the debug, use vpn debug off and vpn debug ikeoff.

vpn debug on TDERROR_ALL_ALL=5 Adds debugs for external user queries. This debug should be collected together with fw monitor.


Debugging VPN-1 Pro, DTPS, and DTLS


Debugging dtps (Desktop Policy Server)• To start writing debug information on the Desktop Policy Server:

dtps debug on

• To stop writing debug information on the Desktop Policy Server:dtps degub off

Logs are automatically redirected to $FWDIR/log/dtpsd.elg.

Debugging dtls (Desktop Log Server)

The dtls daemon is responsible for sending desktop logs from SecureClient to the SmartCenter Server.• To start writing debug information on the Desktop Policy Server:

fw debug dtlsd on

• To stop writing debug information on the Desktop Policy Server:fw debug dtlsd off

Logs are automatically redirected to $FWDIR/log/dtlsd.elg.

Debugging GUI to SmartCenter Server Communication

To enable debug output at the SmartConsoles, proceed as follows:

1 In the Registry, open:HKEY_LOCAL_MACHINE\Software\CheckPoint\Connection\5.0

add a DWORD value Debug, and enter 1 as data (decimal). This generates a file named __CPMIreply.txt in the GUI directory under Windows:C:\Program Files\CheckPoint\SmartConsole\<NGX Version R60 or R60A> \PROGRAM

This file shows the dialog between the GUI and fwm, from the GUI point of view.

2 Set the OPSEC_DEBUG_LEVEL environment variable to 3 (in addition to the above Registry value). This generates a file named __CPDebugOutput.txt, which contains a much more detailed output.

Where there are SmartConsole and Server issues, it is useful to have debug output on both the SmartConsole and the SmartCenter Server. To enable debug output on the SmartCenter Server:

1 Run the fw debug fwm command.

2 Run tail -f on the fwm.elg file before trying to connect with the GUI Client.

Note - This step replaces the command fwpolicy -d.

18

cpstat


Monitoring VPN-1 Pro NGXThis section presents step-by-step instructions for using each of the following monitoring utilities:• cpstat

• cpwd_admin

• cpinfo

In This Section

cpstat

The cpstat command displays the status of target hosts in various formats. The cpstat command is documented in the VPN-1 Pro NGX reference guide, apart from the debug option for both local and remote versions of the command.

Usagecpstat [-h host][-p port][-f flavour][-d] entity

orcpstat [-d][-o {snmp|oid|schema}] -r {fw|vpn|fg|ha|os|mg} netobj

The -d parameter runs the command in debug mode.

cpwd_admin

This utility is used to manage and control the cpwd daemon that is responsible for the Watch Dog function. The command syntax is the same for all platforms.

cpstat page 19cpwd_admin page 19cpinfo page 21

Note - cpstat is an enhanced version of, and replaces fw stat, fw fgstat, fgate stat and similar commands. As of VPN-1 Pro NGX FP1, the –r argument no longer exists. Use the -h argument instead, followed by the module name or IP address.


Monitoring VPN-1 Pro NGX


Usagecpwd_admin start -name <app name> -path <exe path> -command <command line>

cpwd_admin stop -name <app name> [-path <exe path> -command <command line>]

cpwd_admin list

cpwd_admin kill

cpwd_admin exist

Use these commands as they are with the “ character.

CPDW_admin commands• Start CPD

cpwd_admin start -name CPD -path

“/opt/CPshared/5.0/bin/cpd” -command “cpd”

• Start FWDcpwd_admin start -name FWD -path “/opt/CPfw1-50/bin/fw”

-command “fw d”

• Stop CPD with commandcpwd_admin stop -name CPD -path

“/opt/CPshared/5.0/bin/cpd_admin” -command

“cpd_admin stop”

• Stop FWD with commandcpwd_admin stop -name FWD -path “/opt/CPfw1-50/bin/fw”

-command “fw kill fwd”

• Kill <PID> brutallycpwd_admin stop -name <PID>

• Print status of processescpwd_admin list (PID that Watch Dog is tracking)

• Stop CPWDcpwd_admin kill (Watch Dog stop tracking on PID)

• Check if CPWD is runningcpwd_admin exist

Logs are automatically redirected to $CPDIR/log/cpwd.elg.

20

cpinfo


cpinfo

The cpinfo command is used to collect information that is used for debugging and solving VPN-1 Pro problems. The cpinfo command gathers information pertaining to system parameters, interfaces, and tables of the machine on which VPN-1 Pro is installed. The cpinfo command gathers information by running operating system and VPN-1 Pro commands. The resulting file is usually sent to Check Point Technical Support ([email protected]) for analysis.

Run the command as follows:cpinfo > <file_name>

fw monitorfw monitor is a tool used to monitor traffic through a Security Gateway. Unlike standard network monitors, fw monitor can display packets at different points within the Security Gateway chain. This provides information about if, and how, VPN-1 Pro has modified a packet.

Packets are displayed after being virtually defragmented. If there are multiple fragments, the monitor displays the full packet as if it is just one fragment.

In This Section

Note - The cpinfo command replaces the fwinfo command in VPN-1 Pro 4.1.

Basic Use page 22Additional Options page 23Advanced Topics page 24


mailto: [email protected]

fw monitor


Basic Use

Run the following command:fw monitor [–e “filter-expression” | –f filter-file]

fw monitor common usage:fw monitor -e "accept;" -o <output file>

The filter is an INSPECT script, describing which packets are monitored. Packets accepted by this script are monitored. The full INSPECT script syntax is not covered in this manual, but can be found in the Check Point Reference Guide for NGX, in Chapter 4. Some simple samples include:• To see ICMP packets: accept ip_p=1.• To see HTTP packets from client to server (but also UDP port 80 packets):

accept dport=80.• To see both directions of a HTTP connection: accept dport=80 or sport=80.• The filter can either be entered into the command line, using –e, or in a file,

using –f.

Each packet is seen twice in each direction, inbound and outbound:• First, before the packet is inspected or modified.• Second, after inspection or modification.

The output prints one letter, indicating when the inspection takes place. The letter is either i (inbound, before fw), I (inbound, after fw), o (outbound, before fw), O (outbound, after fw). This determines where the packet is changed or dropped. If the packet appears with a lowercase letter, and not with a capital letter, it was dropped.

Basic data about each packet matching the filter is printed. The data includes IP addresses, size, protocol, ports, and more, according to the packet type. The monitor runs and reports packets until stopped with CTRL+C.

22

Additional Options


Additional Options

Option Explanation

-h Displays a usage string-d/-D Prints debug messages (two different debug levels)-m Shows only some of the four instances (i/I/o/O). This

parameter should be followed by a string consisting of some of these four characters. Only the specified instances are monitored. For example, use -m iI to monitor only inbound traffic, or -m IO to see only packets which have passed the firewall. The default setting is iIoO which monitors all the points that the packet passes.

-x offset, length Prints packet data. Specifies the starting offset to print and the number of bytes to print

-l length Limits the packet length. Determines the number of bytes read from the kernel for each packet. If used, make sure to include enough bytes so the IP and protocol headers fit. When using -x to print packet data, verify the data requested also fits. Default is to capture the entire packet.

-o filename Prints to the specified file in snoop format. To read the file, use the UNIX snoop utility. If used, the –x and –i options are ignored (all data is printed).

-u Prints the connection’s UUID (unique ID)-s Prints the connection’s session UUID (for FTP data

connections, prints the control connection’s UUID)-t When compiling the inspect script, includes tcpip.def.

This allows the use of TCP/IP macros in the script.-i After writing each packet - flushes standard output. This

option is useful when killing the monitor, and verifies that all data was written to the file.

–ci count, -co count

Limits the number of inbound and/or outbound packets. Once the specified number has been reached, the monitor stops. By default, fw monitor stops by pressing CTRL+C only.

ip Monitors position (See “Advanced Topics” on page 24.)


fw monitor


Advanced Topics

fw monitor and the module chain

VPN-1 Pro passes each packet through a list of chain modules. Each module can modify the packet, pass it, or drop it. There is a separate list for each direction – inbound and outbound. This list is viewed using the fw ctl chain command. Each module has the following properties:• Absolute position – A signed integer determining the order in which packets pass

the modules. Packets start with the smallest number and end with the largest. This number does not depend on the current chain entries – the same chain module always has the same absolute position in the same VPN-1 Pro version.

• Relative position – A number (starting with 0) specifying the current position on that module in the chain. This number changes when modules are added and removed.

• Name – A description of the module’s purpose• Alias (shown in parenthesis) – A short name that can be used with the –p

parameter.

fw monitor is inserted into the chain as a chain module. This way, it can capture all packets and report them. It does not change or drop any packets. The monitor is inserted into the chain at four different points – in positions minus 0x70000000 and 0x70000000 in inbound, and in the same positions in the outbound direction. The first position gives the packets before they pass most of the Firewall modules, while the latter gives them after they have passed them.

It is possible to change the position of fw monitor. This is accomplished using the -p parameter. This parameter has the following syntax:fw monitor –p[i|I|o|O] [absolute pos | relative pos | [+|-] alias]

The letter following -p is the position to change – either inbound or outbound, either first (lowercase), or last (uppercase) position. You can include this parameter up to four times to change some, or all positions.

When using a relative position, type the position of the module before which you want the monitor to enter. If you want the relative position after all modules, use any number higher than all relative positions (99 is usually enough).

When using an absolute position, type the position where you want the module. If there is a module at this position, the command fails.

When using an alias, select whether you want the monitor before or after a module.

24

Advanced Topics


Buffering

Once the fw monitor program begins running, it downloads the requested filter to the kernel and requests that it collect all packets that match the filter. The packets are collected in a buffer. If the buffer becomes full, all packets in it are deleted and it begins to fill again from the beginning. The monitor command samples the kernel at certain intervals: when it reads the collected packets and clears the buffer.

There are two buffers: one for the kernel to collect packets and one for the fw monitor command to read. At each sampling, the buffers are switched — the kernel starts collecting in a new, empty buffer, while the monitor command reads and prints the other buffer. At the next sampling, the buffers are switched again. The sampling interval depends on the level of traffic. With low traffic, the sampling rate is one per second. With high traffic, the rate increases, until there is no delay between the two samples. If the monitor program cannot read the buffer fast enough, some packets might be lost. Consider the following reasons:• The throughput is high, and fw monitor cannot process the packets fast enough.• The CPU load is high, so fw monitor has too little time to process packets.• There’s a sudden burst of packets, after a time with no filtered packets. In this

case, the sampling interval is one second. The traffic burst is discovered only after the first sample where there is a traffic burst, and this might be a second after the high load has started.

The following are some methods to prevent the buffer from overrunning:• Use the most restrictive filter possible. This reduces the number of packets which

require processing.• Use the –l parameter to reduce the size of the packets being read.• Use an OS-specific tuning tools to give the fw monitor command maximum CPU

time.


fw monitor


26


CHAPTER 2

Secure Internal Communications

In This Chapter

IntroductionSecure Internal Communications (SIC) is a certificate-based channel for communications between Modules (VPN-1 Pro SmartCenter Server, Security Gateway, QoS, OPSEC, and so on).

In VPN-1 Pro NGX, Check Point components communicate with each other using SIC. SIC is based on a Secure Sockets Layer (SSL), with digital certificates. When the SmartCenter Server is installed, a Certificate Authority (CA) is created. The CA issues certificates for all components that need to communicate with each other. For example, a remote VPN-1 Pro Security Gateway needs a certificate from the SmartCenter Server, before a Security Policy is downloaded, or before a license can be attached to the Security Gateway using SmartUpdate.

Introduction page 27Configuration page 28Troubleshooting SIC page 29Known SIC Issues page 31

Note - Some of the procedures described in this chapter do not apply to Connectra modules. Performing SIC reset between management and newer versions of Connectra is not possible from cpconfig. SIC configuration on Connectra is done via the Connectra administrator WebUI, and is outside the scope of this document. A full and updated description appears in the Connectra Administration Guide.

27

Configuration


ConfigurationFIGURE 2-1 SIC Between Entities, Referencing sic_policy.conf

When any two entities in a site (SmartCenter Server, agent, Security Gateway, OPSEC, or QoS) need to communicate, the sic_policy.conf file is referenced.

Communication takes place over SIC. This channel is encrypted in various ways. This layer can be called the SIC layer.• Port 18209 is used for communication between the VPN-1 Pro Security Gateway

and the Certificate Authority (status, issue, and revoke).• Port 18210 is used to pull certificates from CA.• Port 18211 is the port used by the cpd daemon on the Security Gateway to receive

the certificate (by clicking Initialize in SmartDashboard).

28


Troubleshooting SICTo determine whether SIC is listening to its network port, use one of the following commands depending on your OS:• Windows: netstat -na | find “18211”• UNIX: netstat -na | grep 18211

The output should be:TCP 0.0.0.0:18211 0.0.0.0:0 LISTENING

SIC is completely NAT-tolerant, since the protocol is based on certificates and SIC names, not on IP addresses. A NAT device between the VPN-1 Pro NGX SmartCenter Server and Security Gateway does not have any effect on the ability of a Check Point-enabled entity to communicate using SIC.

To verify that the module is listening for the SmartCenter Server, use the cpd -d command. The output is:[date] SIC initialization started

[date] Read the machine's sic name: CN=module,O=mngmt.domain.com.szno9r

[date] Initialized sic infrastructure

[date] SIC certificate read successfully (means module already has a

certificate)

[date] Initialized SIC authentication methods

Registry records about SIC are located under the SIC section of the registry:

Windows (REGEDIT32)HKEY_LOCAL_MACHINE \SOFTWARE\CheckPoint\ SIC

UNIX

Use vi on the file and look for otp:/opt/Cpshares/registry/HKLM_registry.data

Chapter 2 Secure Internal Communications 29

Troubleshooting SIC


Debugging SIC

On the Security Gateway, cpd provides SIC-related information to the following files:

WindowsC:\Program Files\CheckPoint\cpshared\5.0\log\cpd.elg.

UNIX/opt/CPshared/5.0/log/cpd.elg

This is completed by default, without the need to set environment variables.

SIC Debug procedure

Before debugging SIC, verify that the FireWall is up and running. To start the FireWall, run cpstart.

A sic connection can exist in different daemons. Find out which daemon should be debugged, based on the problem. In the relevant daemon, the debug should be turned on as follows (assuming the daemon is up and running):

For cpd daemon

cpd_admin debug on TDERROR_ALL_ALL=5

cpd_admin debug on OPSEC_DEBUG_LEVEL=9

To stop the debug, issue the following commands:cpd_admin debug off TDERROR_ALL_ALL=0

cpd_admin debug off OPSEC_DEBUG_LEVEL=0

For fwd daemon

fw debug fwd on TDERROR_ALL_ALL=5

fw debug fwd on OPSEC_DEBUG_LEVEL=9

To stop the debug, issue the following commands:fw debug fwd off TDERROR_ALL_ALL=0

fw debug fwd off OPSEC_DEBUG_LEVEL=0

For fwm daemon

fw debug fwm on TDERROR_ALL_ALL=5

fw debug fwm on OPSEC_DEBUG_LEVEL=9

To stop the debug, issue the following commands:fw debug fwm off TDERROR_ALL_ALL=0

fw debug fwm off OPSEC_DEBUG_LEVEL=0

30

Resetting SIC on a Security Gateway


Resetting SIC on a Security Gateway

To reset SIC on a Security Gateway, complete the following procedure (based on SecureKnowledge solution SKI1896). The order is not important:

1 In SmartDashboard, open the Security Gateway object, click Communication, and then Reset in the Communication window. This revokes the Gateway’s certificate, and changes the SIC status to “Not initialized.”

2 At the Security Gateway:On Windows, open the cpconfig configuration tool, and select Reset (on the SIC tab).On UNIX, run cpconfig, and select Secure Internal Communication. Reply Yes to the prompts, and enter a new activation key. This deletes the Gateway’s certificate and SIC entries in the registry.

Known SIC Issues

‘Cannot Rename Firewall Object’

This message appears once SIC is initiated. To resolve this issue, use SecureKnowledge solution SKI3379.

1 Delete the Firewall object.

2 On the relevant Firewall Security Gateway, use the cpconfig configuration tool to initialize SIC again for the newly created object.

3 Enter a new one-time password.

4 In SmartDashboard, create a new Firewall Security Gateway object with a new name.

5 Initialize SIC for the newly defined Firewall Security Gateway object.

Chapter 2 Secure Internal Communications 31

Known SIC Issues


‘Could not Resolve Peer Name’

This message appears while issuing test SIC status. To resolve this issue, use SecureKnowledge solution SKI3102.

Use only resolvable names, or add the name to the hosts file.

Windows%WINDIR%\system32\drivers\etc\hosts

UNIX/etc/hosts

‘Failed to Connect the Module’

This message appears while trying to initialize SIC with the module. To resolve this issue, use SecureKnowledge solution SKI2688.

1 On the Security Gateway, use cpconfig to initialize SIC, by typing a new one-time password.

2 In SmartDashboard and the Communications window of the Security Gateway object, reset SIC.

3 Initialize SIC by typing the same one-time password as used at the Security Gateway.

4 To verify SIC, click Test SIC Status.

32


CHAPTER 3

Open Security Extension

In This Chapter

IntroductionThe Open Security Extension (OSE) enables a VPN-1 Pro NGX SmartCenter Server to generate and download Access Control Lists (ACL), and configure security for Nortel and Cisco routers.

This chapter provides additional information about routers, which is not mentioned in VPN-1 Pro NGX user guides.

An NGX SmartCenter Server can manage ACLs for the following third-party routers and devices:• Bay Networks Routers: version 7.x-12.x• Cisco Routers: IOS version 9,10,11,12

Any number of routers and devices can be managed.

Introduction page 33Nortel (Bay) Routers page 34Cisco Routers page 36General Information page 38

33

Nortel (Bay) Routers


Nortel (Bay) RoutersWhen creating an ACL for Nortel routers, be aware that Nortel ACLs always include an implicit final rule accepting all communications (Any/Any/Accept). You must explicitly define a final rule in the Rule Base that drops all communications not described by the other rules (Any/Any/Drop)

Configuring an SNMP Password on Nortel (Bay) Router

To enable VPN-1 Pro to correctly communicate with the Nortel router via SNMP, complete the following procedure during configuration:

From Nortel Site Manager

1 Select the router you would like to configure. There is a small window that lists all routers the Site Manager knows about.

2 From the Site Manager Menu, select Tools > Configuration Manager > Dynamic. This opens a Configuration Manager window, which lets you configure a specific router.

3 Save the current configuration file (File > Save As somename.cfg). You can return to this state at a later time by simply booting the router with this configuration file.

4 On the configuration Manager, select Protocols > IP > SNMP Communities. This opens a window called SNMP Community List.

5 On the SNMP Community List window, select Community > Add Community to add your own community and give it read/write permissions.

6 Select the new community defined in step 5, and select Community Managers. This opens the Managers window. In this window, add the IP address of the VPN-1 Pro machine.

7 Exit the Managers and SNMP Community List windows. Do not erase the Public default community yet.

8 In the Configuration Manager, save your definition in a file, preferably with a .cfg suffix (File > Save As).

34

Further Security Considerations


In SmartDashboard

1 Select Manage > Network Objects.

2 In the Network Objects window click New… > OSE Device…

3 In the OSE Device Properties window, select Nortel from the Type menu.

4 Click SNMP Info...

5 In the SNMP Information window, change the values of both Read and Write fields to the new community defined previously, using Nortel’s Site Manager.

6 Make rules which have either routers or the specific router, in the Install On field.

7 Install the Security Policy. This loads the ACL on the router.

Further Security Considerations

After completing the above procedures, take note of the following considerations:

1 Preventing illegal SNMP access to your router:• Using Configuration Manager as described above, erase the default Public

community, or make it read only.• Whatever ACL you make, it is recommended you allow SNMP connections to

the router only from the VPN-1 Pro site, and from the Site Manager. No other SNMP connections to the router should be allowed. This does not include SNMP through the router, to different locations, which is simply a matter of Security Policy choices.

2 It is recommended that you copy the configuration file on the router to a special file called config (no extensions), which is the default configuration file used when the router returns from a failure (when turned on, after a power supply failure, and so on). This should only be done after verifying everything is correct in the configuration file.

Warning - Make sure you are not adding rules that block SNMP communication between VPN-1 Pro and the router, and from the Site Manager to the router.

Chapter 3 Open Security Extension 35

Cisco Routers


Cisco Routers

In This Section

Cisco Router Version 9 and 11 Differences

Version 9 routers do not support anti-spoofing. These routers do not distinguish between inbound and outbound. You can only install a Security Policy on a router interface.

Versions 10 and 11 support anti-spoofing, because it is possible to define inbound or outbound-filter directions.

Common Issues and Resolutions (Cisco)

Access list download failure

When a user name is defined in the router’s enable mode, ACL download fails. Every time the router asks for a user name, a time-out message is displayed. ACL installation succeeds on the second try. To avoid this issue, do not define an enable user name for Cisco routers.

Debugging Cisco Routers

To verify that VPN-1 Pro installed the ACL correctly on the router, use the following router command to display the current configuration in detail, including the ACL.Show running-config

When issues occur while installing the ACL using the SmartDashboard, use the following command from command line on the NGX SmartCenter Server:router_load -cisco

Cisco Router Version 9 and 11 Differences page 36Common Issues and Resolutions (Cisco) page 36Debugging Cisco Routers page 36

36

Debugging Cisco Routers


Syntaxrouter_load -cisco <router> <conf file> <password|XXX|PROMPT> <enable password|XXX|PROMPT>

or:router_load -cisco <router> <conf file> <user name|XXX|PROMPT> <password|XXX|PROMPT> <enable user name|XXX|PROMPT> <password|XXX|PROMPT>

or:router_load -cisco <router> <password|XXX|PROMPT> <enable password|XXX|PROMPT> [-command <command>]

or:router_load -cisco <router> <user name|XXX|PROMPT> <password|XXX|PROMPT>

<enable user name|XXX|PROMPT> <password|XXX|PROMPT> [-command <command>]

The <conf file> is the router.cl file in the conf directory. This file does not exist when configuring the router network object in SmartDashboard. This file is created by installing the ACL from SmartDashboard, when the router is not connected to the NGX SmartCenter Server.


General Information


General Information

Allowing TFTP ACL Policy Installation from SmartCenter Server

ACL Policy Download uses TFTP server to download ACLs to the router. ACL Policy is supported for all Cisco routers that support TFTP ACL download. By default, the Policy is disabled.

Use

To enable TFTP download using a host name, set the environment variable:setenv ACL_TFTP_DOWNLOAD 1

To enable TFTP download using an IP address, set environment variable:setenv ACL_TFTP_DOWNLOAD ipaddr’ (string "ipaddr")

When enabled, Open Systems Environment (OSE) creates its Access List statement on the TFTP server. OSE then downloads the entire ACL to the router. The ACL Policy file name convention is:ose.[management host name].acl

Prerequisites

The OSE device assumes that the TFTP server is configured on the SmartCenter Server. TFTP Server installation and configuration is out of the scope of the OCE device.

UNIX• Remove the comment tftpd declaration in /etc/inetd.conf.• Add router IP address to /rhosts

NT

There is no standard TFTP server for NT security considerations. Since TFTP includes no login or access-control mechanisms, do not violate the security of the server host’s file system. TFTP is often installed with controls, so that only files that have public read access are available via TFTP. Writing files with TFTP is not allowed. The Security Policy must be defined to allow TFTP only between the SmartCenter Server and the router.

Note - rhost might not exist under /root, and may need to be created. Create the /tftpboot directory.

38

Creating and Installing a Policy using a Command Line


If the router is configured to enforce NAT rules, OSE should use TFTP download using the host name (ACL_TFTP_DOWNLOAD 1). For TFTP download using a host name, the SmartCenter Server host name must be resolved by the router.

Creating and Installing a Policy using a Command Line

1 Launch SmartDashboard.

2 Create a new Policy Package for the OSE device (ACL Policy).

3 Press CTRL+S to save the Policy.

4 On the SmartCenter Server, under $FWDIR/conf, issue the following command:fwm gen -cisco <Policy file>.W > <file name>.cl

5 Edit the <file name>.cl file, with the editor tool. Remove all (0) and (1) strings from the *.cl file. When using the vi editor, issue the following commands to remove these strings::%s/( 0)//

:%s/( 1)//

6 Save the changes.

7 Once the *.cl file is edited, issue the following command:router_load -cisco <router name/IP> *.cl password <your password> enablepassword <your enable password>


General Information


40


CHAPTER 4

SmartUpdate

In This Chapter

Debugging Licensing Commands

Introduction

This chapter explains how to debug cprlic licensing commands between the SmartCenter Server and the Security Gateway.

To debug licensing issues in VPN-1 Pro NGX, it is important to understand the following principles:

1 All functions are executed by the SmartCenter Server (fwm).

2 Both fwm and the licensing command itself must be debugged in different shells.

3 Debug output can be directed either to a file or to the screen.

Debugging Licensing Commands page 41Debugging Communications Between SmartUpdate GUI Client and SmartCenter Server page 43Remote Installation Debugging page 44

41

Debugging Licensing Commands


Debugging Licensing Commands On Windows

1 Open two command windows.

2 In both windows, set the following variables:set OPSEC_DEBUG_LEVEL=3set TDERROR_DEBUG_LEVEL=3

3 If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start the Firewall (cpstart) then kill fwm.

4 In one of the shell windows type the following:fw m -d 2> fwm_debug.txt

5 From the other shell window run the cprlic command you wish to debug. For example:cprlic put <object_name> -l <license_file> >& rlic_put_debug.txt

Once the cprlic command has completed its operation, the debug output file is available.

6 Stop the fwm -d command by typing CTRL+C. This kills the fwm process, so it needs to be restarted.

Debugging Licensing Commands On UNIX

1 Open two shell consoles.

2 In both consoles, set the following variables:setenv OPSEC_DEBUG_LEVEL 3setenv TDERROR_DEBUG_LEVEL 3

3 If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start the Firewall (cpstart) then kill fwm.

4 Type the following command in one of the shell windows:fwm -d >& fwm_debug.txt

5 From the other shell window run the cprlic command that you wish to debug. For example:cprlic put <object_name> -l <license_file> >& rlic_put_debug.txt

Once the cprlic command has completed its operation, the debug output file is available.


42

To Debug Attach and Detach Operations


Debugging Communications Between SmartUpdate GUI Client and SmartCenter Server

This section describes how to debug the communication between SmartUpdate and the SmartCenter Server. Use the information in the following sections to debug the interaction between the SmartCenter Server and the Security Gateway.

In This Section

To Debug Attach and Detach Operations

1 On a Windows machine, set an environment variable by going to:Start > Control Panel > System > Environment tab, and set the environment OPSEC_DEBUG_LEVEL to 3.

2 Open the SmartUpdate client, and perform the Attach/Detach operation.

3 The file __CPDebugOutput.txt, containing debug output, is created in the directory:C:\Program Files\CheckPoint\Management Clients\5.0\PROGRAM\

To Debug Import Operations

1 Open a registry editor (regedit32) and go to:$HKEY_LOCAL _MACHINE\Software\CheckPoint\Connection\5.0

2 Add a new string value: Debug = 1

3 Close the registry editor.

4 Open the SmartUpdate client, and Import a License.

5 The file __CPMIreply.txt containing debug output is created under:C:\Program Files\CheckPoint\Management Clients\5.0\PROGRAM\

Note - The debug output is related only to operations taking place between the SmartUpdate client and the SmartCenter Server.

To Debug Attach and Detach Operations page 43To Debug Import Operations page 43Adding a License to the SmartCenter Server page 44

Chapter 4 SmartUpdate 43

Remote Installation Debugging


Adding a License to the SmartCenter Server

To resolve this issue, use SecureKnowledge solution SKI2575.

Using your Certificate Key, obtain a license from the User Center, and install it on the SmartCenter Server as follows:

1 Open the Check Point Configuration Tool (cpconfig).

2 Choose the Licenses tab.

3 Choose Fetch From File, and browse to the location of the license file received from the License Center.

4 Select Open. A message appears, stating that one license was found suitable for that module.

5 Click OK.

6 Start VPN-1 Pro by running cpstart.


Pre-NGX Packages (BC)

Management Machine• $SUROOT/log/su.elg - SUAddon debug output

• By default, only errors/warnings are written.• Set TDERROR_ALL_SU to 5 for all SU messages.

• $FWDIR/log/fwm.elg - FWM debug output• By default, nothing is written by SU.• Set TDERROR_ALL_SU to 5 for all SU messages.

• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) cprep.elg, cpget.elg (for management machine only)• Management machine (or standalone) installation logs per product, e.g.,

install_fw1_DAL.elg

• Package repository logs• Local machine cpget log, which is the same as NGX.

• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) - management script (brought by the ng_bc/trini_bc package) logs• The log filename consists of the module name and the OS name• Verification output only

44

NGX Packages and Beyond


• cprid_util logs• Set OPSEC_DEBUG_LEVEL to 3• Set SU_DEBUG_LEVEL to 4

Module Machine• /opt/CPInstLog/cpget.elg - additive; incudes cpget logs.• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) - installation logs per

product• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) - module script logs

(transfered by SU server addon)• To debug BC scripts, set SU_DEBUG_LEVEL to 5.

• CPRID logs - cprid.elg• Set OPSEC_DEBUG_LEVEL to 3• Set SU_DEBUG_LEVEL to 4

NGX Packages and Beyond

Management Machine• $SUROOT/log/su.elg - SUAddon debug output

• By default, only errors/warnings are written.• Set TDERROR_ALL_SU to 5 for all SU messages.

• $FWDIR/log/fwm.elg - FWM debug output• By default, nothing is written by SU.• Set TDERROR_ALL_SU to 5 for all SU messages.

• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) cprep.elg, cpget.elg (for management machine only)• Management machine (or standalone) installation logs per product, e.g.,

management• Package repository logs• Local machine cpget log

To receive extensive debug information:• Set TDERROR_ALL_cprep to 4

Note - CPRID logs do not apply to older packages.

Chapter 4 SmartUpdate 45



• Set TDERROR_ALL_cpget to 4• Set TDERROR_ALL_cpms to 4

• cprid_util logs - set OPSEC_DEBUG_LEVEL to 3 and SU_DEBUG_LEVEL to 4.

Module Machine• $SUROOT/tmp/<package key>/cpms.elg - an additive which incudes verification,

installation, and un-installation logs.

• /opt/CPInstLog/cpget.elg - additive; incudes cpget logs• $SUROOT/log/install_status.log - cpms places its return code in this log.• $SUROOT/log/messages.log - cpms places error descriptions of its last return code

in this log.• /opt/CPInstLog (Program Files/CheckPoint/CpInstLog) - installation logs per

product• CPRID logs - cprid.elg

• Set OPSEC_DEBUG_LEVEL to 3• Set SU_DEBUG_LEVEL to 4

• /var/log - SecurePlatform upgrade log files

Note - The cpms script runs with different parameters for installation, un-installation, and verification.

46


CHAPTER 5

SmartMap

In This Chapter

IntroductionSmartMap is a visual representation of the network objects defined in SmartDashboard, and represents the relationship between these objects. SmartMap provides a user-friendly environment, which transforms the conceptual Security Policy Rule Base into a working Topology graph.

Apart from enabling visualization of the Policies defined in SmartDashboard, the Topology View replaces hand-drawn complicated network diagrams with a single, efficient diagram, which can be printed and referenced. SmartMap also serves as a Network Objects Editor.

Critical elements of the Security Policy can be instantly located. Once discovered, the Security Administrator can easily and directly edit object parameters, and intuitively define new object groups for more efficient Policy creation. SmartMap visualizes the object.C database, and shows information calculated from Topology settings (interfaces and anti-spoofing), and from Domain (locale) information.

SmartMap improves security by illustrating the actual impact of the Security Policy when installed. This illustration of the impact of Policy rules enables the Security Administrator to validate the intent and integrity of the Policy. This eliminates common errors resulting from a mismatch between what the Security Administrator intends to enact in the Security Policy and the Policy's actual impact.

Introduction page 47Configuration page 48Troubleshooting page 49

47

Configuration


ConfigurationWhen connecting to the SmartCenter Server using SmartDashboard for the first time, SmartMap manipulates the following files (located in $FWDIR/conf):

objects_5_0.C

The objects_5_0.C file contains the graph_objects section, specific to SmartMap. It includes:• Defined implied and ambiguous networks• Connectivity clouds• Internet and folder settings• Edge indicators; these exist between graph_objects and network_objects, and in

network_objects between themselves.

In addition, the totally_disable_VPE (false or true) property allows the SmartMap window to be disabled or enabled.

objects_graph.mdl

This file specifies the actual topology structure and SmartMap view. It also specifies folders and their contents, such as object name and unique ID, map positions, and edge indicators.

This file is generated and updated automatically, and cannot be edited. Its format must not be altered in any way. It is generated after selecting File > Save in SmartDashboard, when logging into SmartDashboard for the first time.

Starting SmartMap

When logging into Check Point SmartDashboard for the first time:• There is a brief delay, caused by topology-map calculations.• The objects graph (objects_graph.mdl) is generated after selecting File > Save in

SmartDashboard.

When performing an upgrade installation of VPN-1 Pro, there might be a delay of two to four minutes during topology-map calculations, when logging in to Check Point SmartDashboard. The time taken depends on the number of objects in the objects database.

48

Problems and Solutions


TroubleshootingWhen troubleshooting SmartMap issues, remember that the Topology map and its capabilities are a reflection of the definitions in objects_5_0.C.

1 Compare object-node names between the objects_graph.mdl file under the Nodes paragraph, and object name in the objects_5_0.C file.

2 Compare object unique IDs (UID) between the objects_graph.mdl file under the Nodes paragraph, and the object UID in the objects_5_0.C file.

Problems and Solutions

Disabling and Enabling SmartMap

To disable SmartMap when logging in to SmartDashboard, open the registry editor:HKEY_CURRENT_USERE\Software\CheckPoint\Policy Editor\5.0\General Settings

Add a new Key of type DWORD, with the value VPE, and set the value to 0.

To enable SmartMap, either change the value to 1, or delete the key.

When encountering topology problems, it is best to recreate a clean topology. Delete from the server, or rename the objects_graph.mdl file. This creates a new file, and might solve the problems.

Rearranging the Map Layout

There are two ways to rearrange the map layout:• The Layout button changes the layout style incrementally.• Choosing one of the options in the Arranging Styles tab (Topology > Customization in

the menu) rearranges the map, by running one of two global layout algorithms. This often yields better results.

Verifying and Comparing Maps

The Topology map can be verified by comparing it to a Topology map from a different VPN-1 Pro network environment:

1 From the other network environment, obtain the following files:• $FWDIR/conf/objects_5_0.C

• $FWDIR/conf/objects_graph.mdl

Chapter 5 SmartMap 49

Troubleshooting


2 Back up the following files in the \Program Files\Check Point\Management Clients\5.0\PROGRAM directory. These files are used for the GUI demo mode login.• objects.fws to objects.fws.orig• objects_graph.mdl to objects_graph.orig

3 Copy the files from the other environment to the NGX machine in: Program files\CheckPoint\Management Clients\5.0\PROGRAM directory, and rename objects_5_0.C to objects.fws. Do not rename the objects_graph.mdl file.

4 Log into SmartDashboard in Demo mode.

5 Check the Demo box located under Server.

50


CHAPTER 6

Web Intelligence

In This Chapter

Introduction page 52The ActiveStreaming Mechanism page 54Licensing page 55Web Intelligence Logs page 55Debugging and monitoring page 56Known Issues with Web Intelligence page 57

51

Introduction


IntroductionWeb Intelligence is a Web application firewall technology for Check Point products. Web Intelligence inspects Web content and embedded application code, and prevents attacks. Web Intelligence's enhanced security features include:• Malicious Code Protector - a patent-pending technology that catches known and

unknown buffer overflow attacks and other malicious code.• Enhanced streaming inspection - extends the inspection and reconstruction

capabilities of the INSPECT architecture by adding active traffic control of live traffic streams.

• Simple deployment and management - built to be quickly deployed to protect Web servers, without complex tuning and configuration.

• Seamless integration with Check Point products - provides protection for the entire Web environment.

FIGURE 6-1 Web Intelligence: Protecting the Entire Web Environment

52

Application Intelligence


Application Intelligence

Application Intelligence is a set of advanced capabilities, integrated into Check Point's Firewall and SmartDefense products, which detects and prevents application-level attacks. Web Intelligence offers an additional layer of defense for the Web environment, including:• Malicious Code Protector• LDAP injection• SQL injection• Command injection• Granular HTTP format sizes• Granular allowed HTTP methods• HTTP header spoofing• Error concealment• Directory listing• Directory Traversal• ASCII only request and response

Web Intelligence Security Administrators can define Security Policies, SmartDefense, and Web Intelligence configurations from one centralized user console. Web Intelligence logs are also centrally stored and analyzed with all Check Point logs.

Monitor only

All Web intelligence defenses support monitor only, which means that the defense does not reject connections. In addition, a special "Monitor only mode" is supported. When all Web Intelligence active defenses are in monitor mode, Web Intelligence does not reject any HTTP connection, regardless of parsing issues.

Web Servers

Most Web Intelligence defenses support the "web server" concept. Each defense can be configured to be active on specific web servers or on all HTTP connections.

Chapter 6 Web Intelligence 53

The ActiveStreaming Mechanism


The ActiveStreaming MechanismThe new ActiveStreaming technology enhances the streaming capabilities that already exist in VPN to new levels of inspection. Check Point ActiveStreaming reassembles TCP segments, enabling inspection of complete protocol units before any of them reach the client or server.

In addition, ActiveStreaming provides the ability to modify TCP streams on-the-fly, and add or remove data from the stream. Active streaming is used in the following defenses:• Error concealment• Header spoofing• Directory listing• ASCII only response• In R60/R55W, when a defense has a Send Error Page checked

Passive streaming is widely used in VPN for advanced streaming uses, such as the General worm catcher, Peer to Peer protocol detection, CIFS inspection, and other purposes. It provides an API to higher application layers, enabling fast inspection and rejection of offending packet streams.

However, there are some functions which cannot be carried out by passive streaming, such as buffering an active session before passing to the server, manipulation and/or removing data from the stream, and sending an error page in case of session rejection.

Active streaming addresses this by providing all of these functions and at a greater speed than that of older security server technology, but not at the performance of passive streaming.

The differences between passive and active streaming:• Passive Streaming can:

• Analyze requests• Reject on detection• Perform advanced inspection with reduced overhead

• ActiveStreaming can:• Analyze an entire request and response header before sending it to the server

and Client• Manipulate a stream

Note - The decision as to which streaming to use is on a per connection base.

54

Web Servers


• Send an error page• Perform advanced inspection with greater control but more overhead

Licensing• Web Intelligence is licensed per Enforcement Module. All the Enforcement

Modules that enforce the new Web Intelligence features should have a license.• Enforcement Modules are counted based on the web servers object that reports

which Enforcement Module protects it.• If a web server is protected by "All", all NGX Enforcement Modules require a

Web Intelligence license.

The following features require a Web Intelligence license:• MCP• SQL injection• Cmd injection• LDAP injection• Header spoofing• Directory listing• Error Concealment• HTTP method

Web Intelligence LogsWeb Intelligence logs have a standard form: WSE0070001 worm catcher pattern found - the WSEXXXXXXX is a special code that can be used to search for an SK (all codes appear in the SKs).


Debugging and monitoring


Debugging and monitoring

In This Section

Enhanced Debugging Capabilities• Per IP debugging and tracing - focuses debugs on specific targets to eliminate

unnecessary load.• Greater tracing information - even packet dumps• Reject IDs - correlate user error with logs and debug• Error IDs - unique error identifiers• New SmartView Monitor counters for new security features• Improved logs

Running Debug• The entire architecture is debugged with:

• fw ctl debug -m WS <level> <option>• Level: fatal, error, warning, info• Many options are available. Some examples of options:

• Policy installation: spii, policy, module• Connection management: connection, session• Request/Response parsing: parser, body• Reject / Defense: policy, body, report_mgr• Adding a capture to the debug: pkt_dump, address, timestamp• You can turn everything on by using: fw ctl debug -m WS all

Enhanced Debugging Capabilities page 56Running Debug page 56Some debugging tips and tricks page 57

56

Some debugging tips and tricks


Some debugging tips and tricks• Filter a specific IP (destination and source):

• fw ctl set ip ws_debug_ip <ip_addr>To turn off:• fw ctl set ip ws_debug_ip 0

• Use pkt_dump flag to get a fw monitor view of the input.• Use the reject ID to filter out a specific session.• pkt_dump can help you understand what was the input.• Use the URL to find the session.• Use the reject ID to find the session.

Known Issues with Web IntelligenceError 1: A feature tried to use Active Streaming but Active Streaming is disabled!

Cause: Active Streaming is required for several SmartDefense/Web Intelligence features. Check Point does not recommend disabling Active Streaming. If Active Streaming is disabled and a SmartDefense or Web Intelligence feature tries to use it, the above error appears on the Security Gateway console.

Solution:

1 To enable or disable Check Point Active Streaming (CPAS), change the value of the global parameter cpas_enabled. Valid values for cpas_enabled are:1 - Enables Active Streaming on the enforcement module0 - Disables Active Streaming on the enforcement module

2 To change kernel global parameters, refer to sk25826.

3 After changing the value, run cpstop, followed by cpstart at the command line.

4 To view the current value of the cpas_enabled parameter, type the following command at the Gateway console:fw ctl get int cpas_enabled

For more information please refer to sk27151


Known Issues with Web Intelligence


Error 2: Illegal header format detected Malformed HTTP version in request

(Error Code WSE0020001)

Possible causes:

1 The request contained an illegal HTTP version; the version must be indicated by a number (for example, 1.1 or 1.0).

2 The request contained a malformed start line. This is not allowed by RFC 2616 (HTTP) and RFC 2396 (URI), and can be used by a remote attacker to launch an attack against a web server.

3 The request contained a start line without a URL. This is not allowed by RFC 2616 (HTTP), and can be used by an attacker to launch an attack against a web server.

4 The request contained a header without colons and value. This is not allowed by RFC 2616 (HTTP), and can be used by a remote attacker to launch an attack against a web server.

Solution: This error message is associated with the configurable parameters in: SmartDashboard > Web Intelligence > HTTP Protocol Inspection.

HTTP Protocol Inspection provides strict enforcement of HTTP protocol, ensuring that these sessions comply with RFC standards and common security practices. The following solutions refer to the causes specified above:

Cause (1): No workaround exists; the HTTP request cannot be parsed correctly.



Cause (4): When the error message is received with legitimate connections (not an attack), perform the following workaround procedure.

58

Some debugging tips and tricks


Workaround: Configure parameter http_strict_request_parsing to false in the GUI (see screen capture below).FIGURE 6-2 Illegal header format workaround

For more informations, see sk26440.


Known Issues with Web Intelligence


60


CHAPTER 7

LDAP Servers and SmartDirectory

In This Chapter

IntroductionThis chapter contains information about:• Lightweight Directory Access Protocol (LDAP) servers• SmartDirectory, which is integrated into the NGX SmartDashboard

To implement SmartDirectory, you must install and configure two components:• SmartCenter Server and Security Gateway• LDAP server, containing users, groups, and template information

Introduction page 61Introduction to SmartDashboard User Management page 62SmartDirectory page 63Troubleshooting LDAP Issues page 64Modifying the Active Directory Schema page 65Issues with Active Directory and NGX page 66

61

Introduction to SmartDashboard User Management


New Features in VPN-1 Pro NGX• LDAP management integrated into SmartDashboard• Account-policy lockout per account unit• LDAP password-replacement functionality• Password-strength enforcement• UID conflict resolution• Sequential LDAP server lookup• Configurable LDAP servers• On-demand DN display• Dynamic-group filter (in external groups)• Multiple account units simultaneously open• New LDAP administrator permissions• LDAP template inheritance

Introduction to SmartDashboard User ManagementAccount management for a large network can be a daunting task, and maintaining synchronized user databases is a time-consuming chore. Organizations that have multiple user databases in one firewalled network need a process where all databases are maintained from one location. NGX can perform such a process by using SmartDashboard.

An LDAP user-database administrator is allowed to define, remove, and modify LDAP users and groups, by modifying account units. However, the administrator has no permissions to change the enterprise Security Policy. While managing LDAP users, the LDAP user-database administrator does not lock the database, nor affect the Security Administrator's capabilities.

Lightweight Directory Access Protocol

LDAP is used to maintain information about users and items within an organization. It is the lightweight version of the X.500 ISO standard. Each LDAP server is called an account unit (AU). LDAP is based on a client/server model, where an LDAP client makes a TCP connection to an LDAP server. Each LDAP entry has a unique Distinguished Name (DN). Default port numbers are 389 for a standard connection, and 636 for a Secure Sockets Layer (SSL) connection.

62

Distinguished Name


Distinguished Name

The Distinguished Name (DN) is a globally unique name for an entry, and is constructed by concatenating the sequence of DNs from the lowest level of a hierarchical structure to the root. The root becomes the relative DN. For example, when searching for the name John Brown, the search path would start with John Brown's Common Name (CN).

You would then narrow the search from that point to the organization he works for, to the country, and so forth. If John Brown (CommonName) works for the ABC Company, one possible DN might be cn=John Brown, o=ABC Company, c=US. This is read as "John Brown of ABC Company in the United States." A different John Brown who works at the 123 Company might have a DN as follows:cn=John Brown, o=123 Company, c=UK

The two common names "John Brown" belong to two different organizations, with different DNs.

SmartDirectorySmartDirectory is a fully integrated component of SmartDashboard. This component is used to manage users in the LDAP directory server. All major LDAP servers come with their own GUI. Check Point provides SmartDirectory to manage VPN-1 Pro specific object attributes over LDAP. Most LDAP clients include only standard LDAP fields. Check Point has its own requirements from a user database.

LDAP Schema in NGX

In NGX, a few changes were made to the Check Point LDAP schema. The following attributes were added:fw1userPwdPolicy

fw1badPwdCount

fw1lastLoginFailure

memberoftemplate

The objectclasses were changed as follows:• fw1person must also contain sn (surname), and might also contain:

fw1userPwdPolicy, fw1badPwdCount, fw1lastLoginFailure, memberoftemplate

• fw1template might contain also fw1userPwdPolicy.

Chapter 7 LDAP Servers and SmartDirectory 63

Troubleshooting LDAP Issues


Modifying the Netscape Schema

To add the Check Point schema to your Netscape directory server, use the schema.ldif file located in the $FWDIR/lib/ldap directory. You can use this file with the ldapmodify command line. On some server versions, the delete objectclass operation might return an error, even though it was successful. In that case, run ldapmodify -c.

Troubleshooting LDAP IssuesLDAP problems can be divided into the following categories:• Installation• Problems while using the SmartDashboard User Management• NGX related issues• LDAP related issues

LDAP Troubleshooting Process

The LDAP server configuration consists of several components, which must work together properly. The primary problem is to identify the component that causes the failure. The problem might originate from the SmartDashboard, the LDAP, VPN-1 Pro NGX or even at the SecuRemote client that initiates the connection. The most important step is to identify the location of the failure, as detailed below:

1 Test the connection without SecuRemote client, and with users defined in the VPN-1 Pro database. If the problem persists, it is related neither to the LDAP server, nor SecuRemote.• In SmartDashboard, choose Manage Users, and define a default user.• Enter a User Authentication rule.• Test the connection.• If the problem persists, it is not related to the LDAP server.

2 Try to initiate a User Authentication rule with users defined on the LDAP. If the problem disappears, it might be a SecuRemote or encryption issue. If you have reached this point, the problem is probably LDAP related. Locate the log files on the LDAP, which might contain error messages that indicate the cause of the problem.

3 In Netscape LDAP there are two files located under \admin-serv\logs directory, called access and error logs.

64

Updating the Registry Settings


4 Check the slapd.conf file on the LDAP server, which contains definitions and parameters for the LDAP server.

5 Check connections between VPN-1 Pro and LDAP, run monitors, and check connectivity without SSL.

6 Check HyperBolic Schema on LDAP server. Extend the schema again, if necessary.

7 Check for error logs in SmartView Tracker.

8 Run ldapsearch to check the link with the LDAP server, and to retrieve useful information. For example:ldapsearch -h elip2 -p 389 -D "o=support,c=il"-b "o=support,c=il" -w Abc12345 cn=*

9 Run the ldapcompare utility.

Modifying the Active Directory SchemaThe Windows Advanced Server contains an LDAP server that can be adjusted to work as a user database for VPN-1 Pro.

Updating the Registry Settings

To modify the Active Directory schema, add a new registry DWORD key named SchemaUpdateAllowed, with the value different than 0. under:HKLM\System\CurrentControlSet\Services\NTDS\Parameters

Delegating Control

It is very important to delegate control over the directory to a specific user or group, since by default, the LDAP administrator is not allowed to modify the schema, or even manage directory objects through the LDAP protocol. To delegate control over the directory:

1 Display the Users and Computers Control console.

2 Right-click the domain name displayed in the left pane, and choose Delegate

Control from the context menu. The Delegation of Control Wizard window appears.

3 Add the administrator, or another user from the System Administrators group, to the list of users who can control the directory.

4 Reboot the machine.


Issues with Active Directory and NGX


Adding New Attributes to the Active Directory

This section explains how to add one attribute to the Microsoft Active Directory (in Lightweight Directory Interchange Format). All Check Point attributes can be added in a similar way. The definitions of all VPN-1 Pro attributes in Lightweight Directory Interchange Format reside within the schema_microsoft_ad.ldif file, located in the $FWDIR/lib/ldap directory.

Before attempting to run the ldapmodify command, edit schema_microsoft_ad.ldif, and replace all instances of DCROOT with the specific domain root of your organization. For example, if your domain is support.checkpoint.com, replace DCROOT with dc=support,dc=checkpoint,dc=com.

After modifying the file, run the ldapmodify command to load the file into the directory. For example, if you use the administrator account of the dc=support,dc=checkpoint,dc=com domain, the command syntax is:ldapmodify -c -h support.checkpoint.com -D

"cn=administrator,cn=users,dc=support,dc=checkpoint, dc=com" -w

<password> -f $FWDIR/lib/ldap/

schema_microsoft_ad.ldif

Issues with Active Directory and NGXIssue 1: Cannot connect to Active Directory LDAP Account Unit via SSL (port 636)

To create the certificate for the domain controller, proceed as follows:

1 Install Microsoft Enterprise CA in the same Active Directory domain.

2 In the Default Domain Controllers Policy console (of the Group Policy snap-in), select Computer Configuration > Windows Settings > Security Settings > Public Key Policies.

3 Right-click Automatic Certificate Request Settings, and select New > Automatic

Certificate Request. A wizard appears.

4 Select Domain Controller, and follow the instructions.

5 In the Encryption tab of LDAP Account Unit object's properties, specify Strong for both Min and Max encryption strength.

Note - If your Windows server does not support strong encryption, install Microsoft's Strong Encryption Pack.

66

Adding New Attributes to the Active Directory


Issue 2: Cannot save changes to the Authentication Method properties of Active Directory users

Symptom: Error message in SmartDashboard while trying to save the changes in an authentication scheme.

Symptom: Error: ldap Error 53: Overwriting object:DSA is unwilling to perform

Correction: set the Active Directory LDAP Account Unit object to use encryption (SSL to port 636).

Issue 3: Configuring the VPN-1 Pro to query the LDAP server for user name in a different attribute, instead of UID

In $FWDIR/conf/objects_5_0.C, under the set on your directory server, change the property serLoginAttr (UID) to the appropriate attribute.

For example, in order to authenticate with the employeenumber attribute, change the above line to::UserLoginAttr (employeenumber)

Issue 4: Running LDAP commands on SSL Directory Servers

Run the ssl-conn.exe application. For example:ssl-conn [IP of the NDS] 636 2 4

636 is the port; 2 4 means that the NDS is prepared to use authentication as the minimal encryption method (2), and strong as the strongest encryption method (4).

The SSL connection starts, and SSL random port is written.• ?This is accomplished in SmartDashboard, when connected to an LDAP server, in

the LDAP Account Unit Properties > Encryption tab.• Open another command line (Window NT) or terminal session (Solaris).• Run the LDAP command from the $FWDIR\bin directory:

ldapsearch -h (LOCAL HOST) -p (the random port of the ssl, e.g. 17256...) -D "bind DN" -w <password> -b "base DN for search" <fw1 objects parameter>


Issues with Active Directory and NGX


68


Section 2:VPN-1 Pro/Express


CHAPTER 9

Network Address Translation

In This Chapter

IntroductionIn VPN-1 Pro NGX, the server's address in a connection can be translated on the network interface closest to the client - the inbound interface of the first packet. This is configured by selecting Perform destination translation on the client side, on the Network Address Translation page of the Global Properties window. Prior to version NG, Static Destination Mode Network Address Translation (NAT) was performed on the Security Gateway’s server side, which required special handling for anti-spoofing and internal routing. If this checkbox is selected, the packet is treated as described in this chapter.

Introduction page 71Translated Packets and the Connection Table page 73Debugging NAT Issues page 73NAT Traversal page 75

71

Introduction


Original Packet

This example describes a scenario where both the source and the destination of the original packet are translated. The original packet goes through the following process:

1 The packet arrives at the inbound interface and passes the Security Policy rules.

2 If accepted, the packet is admitted into the connection table.

3 The packet is matched against NAT rules for the destination.

4 If a match is found, the packet is translated.

5 The packet arrives at the Security Gateway TCP/IP stack, and is routed to the outbound interface.

6 The packet goes through the outbound interface, and is matched against the NAT rules for the source.

7 If a match is found for translating the source, NAT takes place.

8 The packet leaves the Security Gateway.

Reply Packet

This example describes a scenario where both the source and the destination of the original packet are translated. The reply packet goes through the following process:

1 The packet arrives at the inbound interface of the Security Gateway.

2 Since the packet is found in the connections table, it is granted admission by the Security Policy.

3 If the packet was translated in the initial connection, its destination (which is the source of the original packet) is translated according to NAT information in the tables.

4 The packet arrives at the Security Gateway TCP/IP stack, and is routed to the outbound interface.

5 The packet goes through the outbound interface. The packet's source (which is the destination of the original packet) is translated according to the information in the NAT tables.

Note - The packet is translated, so it is routed correctly without any need to add a static route on the Security Gateway.

72

Reply Packet


6 The packet leaves the Security Gateway.

Translated Packets and the Connection TableA translated connection has four different entries in the connection table. Suppose a TCP connection, from 1.1.1.1 port 123 to 2.2.2.2 port 456, should be translated to a connection, from 8.8.8.8 port 888 to 9.9.9.9 port 999. The connection table will include the following entries:• The main entry that includes all the values associated with the entry:

<0, 01010101, 0000007b, 02020202, 000001c8, 00000006; ...[values]...>

• The entry for the outbound interface of the original packet, that should match the connection (see step 5 in “Reply Packet” on page 72).<1, 01010101, 0000007b, 09090909, 000003e7, 00000006> -> <0, 01010101, 0000007b, 02020202, 000001c8, 00000006> -

• The entry that should match the return packet as it arrives at the SecurityGateway.<0, 09090909, 000003e7, 08080808, 00000378, 00000006> -> <0, 01010101, 0000007b, 02020202 S21, 000001c8, 00000006> -

• The entry that should match the return packet on the outbound interface (see step 5 in “Reply Packet” on page 72).<1, 09090909, 000003e7, 01010101, 0000007b, 00000006> -><0, 01010101, 0000007b, 02020202, 000001c8, 00000006>

Debugging NAT IssuesTo debug NAT issues, run the following debug commands on the same configuration that produces the problem. For example, if the connection is FTP, run the following commands, open an FTP connection, and use snoop and fw monitor.

1 Run the following from the $FWDIR\bin directory:• fw ctl debug -buf 2048 - directs the information to a buffer• fw ctl debug xlate xltrc - this option is needed in FTP connection to see

the PORT command• fw ctl kdebug -f > & <filename> - reads the information printed to the

buffer by the previous command.These commands debug the translation procedure in the kernel, and produce an output with debug information.

Note - To stop the debugging, run fw ctl debug 0.

Chapter 9 Network Address Translation 73

Debugging NAT Issues


2 As these commands execute, run the fw monitor command suitable for the connection. For example, for an FTP connection, run the following:fw monitor -m iIoO -e "accept [20:2,b]=21 or [22:2,b]=21 or

[20:2,b]=20 or [22:2,b]=20;" -o <filename>

Or with the following syntax:fw monitor -m iIoO -e "accept (dport|1)=21 or (sport|1)=21 or (sport|1)=20 or (dport|1)=20;" -o <filename

3 Start a connection that reproduces the problem.

4 Stop fw monitor.

5 Stop the debug command, as specified in the note under step 1.

NAT Related Issues

Important notes• VPN Routing - IP Pool NAT on a Security Gateway that serves as a VPN router.

It enables forwarding VPN traffic from one VPN tunnel to another, and should be defined as part of the VPN Domain of the VPN router. Otherwise, VPN connections via the VPN router fail.

• VPN Communities - if one of the internally managed members is a version earlier than NGX FP3, NAT disabling in a community is not supported.

• VPN Net - When NAT is disabled inside a VPN Community, it has no effect on VPN Net modules. These modules use a NAT configuration defined on the VPN-1

Net page of the Global Properties window.• VPN Diagnostics - When using the IP Pool NAT mechanism for

Gateway-to-Gateway connections, no proper log is available for the IP assignment. When a network is contained inside another network, and you wish to define a different hide-translation, the effected translation is the one defined for the network, which contains the new hide-translation network.

Limitations• Automatic ARP is not supported with IP Pool NAT.• IP Pool NAT is not supported with security server connections.• A manual NAT rule, where only the service is translated (ANY Service > different

service), is not enforced. As a workaround, define a network range containing all possible networks 0.0.0.0 >255.255.255.255, and translate the range (all_Ips ANY Service > different service).

• OSE objects cannot be used in NAT rules. Define regular node objects with the same addresses, and translate them instead.

74

NAT Related Issues


• Microsoft Exchange Outlook Client UDP new-mail notification does not work with Hide NAT on a client. For new-mail notification, both the client and server are required, in both the source and the destination cells. In the FWDIR/libexchange.def file, enable this notification by setting the following:

#define ALLOW_EXCHANGE_NOTIFY (as stated in the file comments).Client Server MSExchange AcceptServer Client

• When SAM, NAT, and the new Disable NAT inside the VPN community feature are used together, a connection might be blocked by SAM, based on a NAT decision - even though there is no address translation on this connection. This is because it belongs to a community for which NAT is disabled.

• When using a Nokia IP cluster with NAT, the following console messages might appear. These messages have no effect on connectivity and can be safely ignored:

FW: fw_xlate_update_length: fwseqvalid_reg_offset_deltas failedFW: fw_xlate_update_packet: fw_xlate_update_length failedFW: fw_xlate_anticipate_cookie: fw_xlate_update_packet failed

NAT TraversalNAT Traversal is supported according to NAT Traversal RFC 3947.

Chapter 9 Network Address Translation 75

NAT Traversal


76


CHAPTER 10

Security Servers

In This Chapter

IntroductionThe main role of security servers is to perform content security and user authentication.

Editing security server default messages

The default security server messages reside within the file: $FWDIR/conf/spsc/spsc.en_us, and can be edited manually. For example, the string:CPSC_HTTP_FW_AT_HOST 1024 "FW at #host#:" (host)

produces the following security server message:FW at abba: Access denied

where abba has been defined as the Security Gateway. Changing the above string to:CPSC_HTTP_FW_AT_HOST 1024 "Security Server at #host#:" (host)

produces the following security server message:Security Server at abba: Access denied

Introduction page 77Transparent Server Connection page 79TCP Resources page 80HTTP Security Server page 82SMTP Security Server page 90FTP Security Server page 98

77

Introduction


Calculating CPU and Memory Used for Security Servers

Instead of a separate executable file for each security server, each security server links to the fwssd executable. Under Windows, for example, the Task Manager does not show the security server to which each process belongs. To find out which process belongs to each security server, proceed as follows:

1 Look for the relevant security server's PID in the $FWDIR/tmp directory. For example, the HTTP security server PID is written in the in.ahttpd.pid file.

2 Once you know the PID number, look for the number in the Windows Task Manager

> Processes tab (see below). This can also be accomplished for other operating systems. For example, in Solaris, after checking the process number in $FWDIR/tmp, use the Top utility to check process CPU and Memory usage.

FIGURE 10-1 Windows Task Manager Processes Tab

78

What Does ‘Folding’ Mean?


Transparent Server ConnectionWhen the kernel matches a connection to a security server rule, it folds the connection to the relevant security server. (see “What Does ‘Folding’ Mean?” below) The security server opens a connection to the server to which the client tried to connect. The packet leaving the security server has the source IP of the Security Gateway. From version NG, the outbound kernel translates this source IP to the IP address of the client that originally opened the connection. If the client is configured in the Rule Base for Hide or Static NAT, the source IP is translated, as configured in the Rule Base.

This is the default behavior of security servers. In VPN-1 Pro versions 4.0 and 4.1, connections leave the gateway with the source IP of the Security Gateway. To modify this behavior and reflect that of previous versions, use the dbedit utility to change the following properties from true to false in $FWDIR/conf/objects_5_0.C:http_transparent_server_connection

ftp_transparent_server_connection

rlogin_transparent_server_connection

telnet_transparent_server_connection

The SMTP security server operates from version NG in the same manner as previous versions. SMTP security server connections leave the Security Gateway with the source IP of the Security Gateway. To modify this behavior so connections leave with the source address of the original client, change the following property from false to true in the file $FWDIR/conf/objects_5_0.C:smtp_transparent_server_connection

What Does ‘Folding’ Mean?

When a connection is opened from the client to the server, it is redirected to the security server, which opens a second connection to the destination server. This redirection is accomplished using NAT. The kernel translates the destination address to one of its local interface addresses, and to the security server’s special port. Performing NAT on the Security Gateway address is called "folding."

Note - If clients use the HTTP security server as a proxy, connections leave the gateway with the Security Gateway's IP address as the source IP. No translation occurs.

Note - To edit objects_5_0.C, use the dbedit utility. See SecureKnowledge solution skI3301 for instructions.

Chapter 10 Security Servers 79

TCP Resources


TCP ResourcesIt is possible to define a resource for any TCP service. The TCP resource can be used to perform content inspection on any TCP service. The content inspection can be done in the following methods:• Checking the content of the data using a CVP server• Screening URLs using a UFP server

Checking Data Content Using TCP Resource for CVP Servers

The TCP genericd resource invokes a daemon, which acts as a mediator between the client, the CVP server, and the destination server. To configure:

1 Create a new TCP resource. From the SmartDashboard menu, select Manage >

Resource, and click New TCP.

2 Configure the new TCP resource to use a CVP server, and configure the server's details.

3 In a rule Service column, select Add with Resource to add the new TCP resource to the desired TCP service.

4 In the TCP Service Properties Advanced tab verify that the Enable for TCP Resource checkbox is selected.

5 Stop the Firewall.

6 Add a line to the file $FWDIR/conf/fwauthd.conf, specifying on which TCP port you want to run the daemon. For example, if you want the new TCP resource to run on an AOL service that uses port 5190, add the line:5190 fwssd in.genericd wait 0

7 Restart the Firewall.

8 Install the Policy.

80

Screening URLs Using TCP Resource for UFP Servers


Screening URLs Using TCP Resource for UFP Servers

The TCP resource for UFP servers allows the screening of URLs using a UFP server, without using a service-specific security server. The URL received by the UFP server is not a full URL, but rather IP-based. Before using the TCP resource, the Security Administrator must verify that the third-party UFP server supports IP-based URLs, and can categorize specific protocols for which the TCP resource is to be implemented.

To configure:

1 Create a new TCP resource. From the SmartDashboard menu, select Manage >

Resource, and click New TCP.

2 Configure the TCP resource using a UFP server, and configure the server's details.

3 In a rule Service column, select Add with Resource to add the new TCP resource to the desired TCP service.

4 In the TCP Service Properties Advanced tab, verify that the Enable for TCP Resource checkbox is selected.


There is no need to edit $FWDIR/conf/fwauthd.conf as the aufpd daemon. The daemon that passes the IP URLs to the UFP server, is by default already configured in the file.


HTTP Security Server



In This Section

VPN-1 Pro HTTP Security Server and HTTP 1.1

Two known problematic features in HTTP 1.1, which were not supported in versions 4.0 and 4.1, are supported by version NG:• Chunk transport encoding with content inspection• Multi-server connections to an HTTP security server acting as security proxy

Enhanced UFP Performance

NGX includes a new UFP mode (Quick UFP). Quick UFP handles connections through TCP streaming in the kernel. Connections do not pass through the HTTP security server. With Quick UFP, only the URL is forwarded to the UFP server for filtering. The rest of the connection is passed through the kernel, for better performance.

No security servers are used when using Quick UFP. URLs are extracted in the kernel, instead of the user mode:

1 The user daemon sends the URL to the UFP server.

2 The client's request is sent to the Web server before the UFP responds.

3 The user daemon receives the answer and sends it to the kernel.

4 The server's response arrives, and is sent to the client. No changes are needed on the UFP server itself.

VPN-1 Pro HTTP Security Server and HTTP 1.1 page 82Enhanced UFP Performance page 82Chunk Transport Encoding with Content Inspection page 83Partially and Fully Automatic HTTP Client Authentication on Issues page 84Rule Order for Content Security page 85Troubleshooting security server performance issues page 85Signature-Based URL Filtering page 88

82

Chunk Transport Encoding with Content Inspection


Best performance is gained when the UFP replies faster than the Web server. As a result, proxies between a Security Gateway and Web server might hamper performance.

Limitations• Quick UFP cannot be combined with a security server.• The UFP server must be faster than the Web server.• The redirected URL cannot be more than 1,500 bytes long.• If the server's response arrives before the UFP responded, it is dropped, and needs

to be retransmitted. This causes a significant slowdown.

Troubleshooting

Kernel-debug output can be used to receive statistics on the UFP "win" ratio: Server packets can indicate whether or not the UFP has succeeded in replying before the Web server does. The kernel accumulates this data over time, and prints a statistical output of the UFP win ratio. To display the UFP win ratio, use the following kernel-debug flag:fw ctl debug + tcpstr

Chunk Transport Encoding with Content Inspection

The HTTP security server can successfully clean the body of chunked data, before it passes it to content-inspection modules. The following properties, that may have been added in previous versions, are no longer needed, and can be deleted or marked as false in $FWDIR/conf/objects_5_0.C::http_cvp_allow_chunked (true)

:http_weeding_allow_chunked (true)

:http_block_java_allow_chunked (true)

Note - Since fast UFP performance is needed, it is recommended not to use SIC with the UFP server. Use clear communication instead, with no authentication and/or encryption.

Note - Use the dbedit utility to edit objects_5_0.C.




Partially and Fully Automatic HTTP Client Authentication on Issues

Packet-flow Description

When the kernel has a match on a partially automatic HTTP Client Authentication rule, it folds it to the security server. (See “What Does ‘Folding’ Mean?” on page 79.) The security server returns a redirection response, which forces the HTTP browser to open a second connection to the redirected URL. In this case, the new URL is the security server’s. The security server manages the authentication process, and adds a new entry to the Client Authentication table. It returns a redirection response, which directs the browser to the original URL. The browser opens a new connection to the original URL, but this time it passes through the Security Gateway, using the new Client Authentication table entry.

The Issue

The redirect response includes two major headers: the action header, which has the return code (such as HTTP/1.0 302 Not Allowed), and the location header, which directs the browser to the new URL (such as Location http://199.203.71.111/index .html). The browser prints the URL in its address window (the one used to enter the requested URL). After getting a redirect response, the browser replaces the original URL with the one from the location header. A URL contains two parts: the host name and the path. A transparent HTTP request does not include the full URL, but only the path. If the user enters http://www.checkpoint.com/index.html, the HTTP request includes only the /index.html portion.

The result of all this becomes evident when VPN-1 Pro redirects the browser to the original URL. It puts the IP address in the location header, instead of the host name (which is not available). This causes the browser to replace the URL with the IP address.

The Solution

When using Partially or Fully Automatic Client Authentication, it is possible to configure VPN-1 Pro, so that the redirection sent to the client pointing it to the server is performed according to the host header, and not according to the destination IP. To enable redirection according to the HTTP host header, change the following property to true::http_use_host_h_as_dst (true)

Note - Use the dbedit utility to edit objects_5_0.C.

84

Rule Order for Content Security


Session Authentication Rules and Domain Objects

In NGX, the HTTP security server (or any other resource) can be configured in the same rule with Session Authentication and domain objects.

Rule Order for Content Security

SecureKnowledge solution ID 36.0.608403.2485073

When setting up content security, a rule is needed to allow a connection from VPN-1 Pro to the CVP server on port 18181 for the control connection. The rule must also allow TCP high ports between the firewall and the CVP server. This facilitates file transfer from the Security Gateway to the CVP server for file inspection.

Rules that specify CVP inspection do not replace rules that allow FTP, HTTP, or SMTP connections. Since VPN-1 Pro examines the Rule Base sequentially, you must define rules in the appropriate order, to prevent unwanted traffic from entering your network.

Resource rules that accept HTTP, SMTP, and FTP connections must be placed before other rules that accept these services. If you define a rule that allows all HTTP connections before a rule that specifies CVP inspection on a URI resource, you are risking allowing unwanted traffic. Similarly, CVP rules must be placed after rules that reject FTP, HTTP, or SMTP resource connections. For example, a rule rejecting large e-mail messages must come before a CVP rule allowing specific SMTP connections.

Troubleshooting security server performance issues

Should the HTTP security server cause performance issues, the following information can help in troubleshooting. The goal is to determine which object is responsible for the performance issues (the HTTP security server, the CVP, the machines themselves, and so on), when, and why.




The following is an example of a possible scenario where the HTTP security server is configured with a CVP server on a loaded network.FIGURE 10-2 Test environment for solving security server performance problems

Requirements for troubleshooting

1 Separate VPN-1 Pro and the CVP servers.

2 Use monitoring tools like top, snoop, fw monitor, logs or accounts, for easy access to the objects involved.

Possible causes

Determine the possible causes of the problem. Assume that every object involved in the process can cause the problem, and that the problem can also arise from a combination of causes. Possible causes for each object include the following:

Machines• Overloaded CPU• Memory issue• Running out of file descriptors

Security Gateway• Limitation of kernel tables• A loaded kernel blocking security servers

86

Troubleshooting security server performance issues


Security Servers• A general security server issue• A security server with a CVP/UFP resource issue• CVP server saturation• Limitation of hash tables

CVP Server• Overloaded CPU• Memory issue• Possible known/unknown issue

Finding the Source of the Issue

One of the best ways to understand where the issue lies is by eliminating possibilities:

1 Change the rule so the HTTP resource is not used. Replace it with a plain HTTP service. This way, HTTP connections are passed through the kernel and not folded to the security server. (See “What Does ‘Folding’ Mean?” on page 79.)If this solves the problem, the problem is with the HTTP security server: Proceed with step 3. If it does not solve the problem, proceed with step 2.

2 Change the rule to use the HTTP resource again, instead of the plain HTTP service. Do not configure the resource with the CVP server. Under this configuration, if the problem does not exist, we know that the issue is with the interaction with the CVP server.

3 When the problem occurs, run the following:• Top (on Solaris) or Task Manager (on Windows)

Notice which process number is in charge of CPU and memory usage on both machines. Check $FWDIR/tmp to understand to which security server the PID belongs. (See “Calculating CPU and Memory Used for Security Servers” on page 78.)• lsof (on Solaris)

Run the command to check how many file descriptors are open:lsof | grep <process name> | wc -l• fw tab -s

Examine the Firewall kernel-tables counts. Look for a table with high counts:• snoop or fw monitor




The output should show if connections are being folded to the security server, and if the security server is passing them to the CVP server:• Save the log and ahttpd.log files.

Check the log file for any drops, or information about connections in the Info column. Check the ahttpd.elg file for any error messages.

Analyzing the Results

From the results, you should be able to determine:• The faulty object; from now on you can be more focused in your resolution.• A measurement of the load (by using accounts, logs, snoops) and the network view

(using snoops).• The state of the machine resources.• Whether the problem is a VPN-1 Pro and/or CVP server limitation.

Signature-Based URL Filtering

NGX introduces a method to block URL requests containing a specific URL pattern. VPN-1 Pro checks each URL request, and matches it against the desired pattern. If the URL request contains the pattern, the connection is rejected.

This feature does not use the HTTP security server. All processing is performed in the kernel, using the TCP streaming mechanism, which makes it fast and efficient.

Configuration

To configure signature-based URL filtering:

1 Close SmartDashboard.

2 On the SmartCenter Server, use dbedit to change the following property:Fwurl_filter_pattern (.ida?)

3 Edit the default .ida? to the pattern desired.

4 Open SmartDashboard and create a new URI resource. In the General tab, select Optimize URL Blocking.

5 Configure a new rule:


88

Signature-Based URL Filtering


Advanced Properties

1 It is possible to configure the URL pattern filter to look for the pattern only in the first part of the URL string, up to a given number of bytes. In this example, the pattern being searched for is XYZ, and the search length is indicated by an arrow. The URL request passes, because the pattern is outside the search area.

FIGURE 10-3 URL pattern filter

Change the following property (using dbedit) to check only the first number of bytes. The default is zero, which means searching the whole URL string.Fwurl_filter_depth (size of string)

2 It is possible to configure the URL pattern filter to look for a pattern only if the URL string is longer than a specified length; smaller URL strings are ignored. Change the following property (using dbedit), and specify the URL string length (in bytes):Fwurl_filter_total_len (size of string)

3 It is possible to configure the URL pattern filter to search for a suspicious pattern and reject the connection only if the number of bytes from the end of the pattern to the end of the string is greater than a specified number of bytes. In this example, the whole string is searched, and the suspicious pattern XYZ is found. The specified remaining length is indicated by an arrow. The URL request is rejected, because the number of bytes from the end of the pattern to the end of the string is greater than the specified remaining length (the value of Fwurl_filter_left_len).

FIGURE 10-4 Suspicious Pattern Filtering

Change the following property (using dbedit) and specify the URL string length (in bytes).Fwurl_filter_left_len (size of string)


SMTP Security Server



In This Section

SMTP E-Mail ProcessFIGURE 10-5 SMTP e-mail process

Mail is sent from the host mail client to the VPN-1 Pro asmtpd. It is placed in the spool directory until entering the mail dequeuer (MDQ), which sends it to the appropriate mail server, which in turn forwards it to the recipient.

SMTP E-Mail Process page 90The SMTP Security Server Process page 91Improvements in SMTP page 92Troubleshooting SMTP-Security Server Issues page 94Debugging SMTP Security Issues page 96

90

The SMTP Security Server Process


The SMTP Security Server ProcessFIGURE 10-6 SMTP security server

When using the SMTP security server, a certain flow of events takes place from the time the user sends the message to the time the message arrives to the actual mail server:

1 The user composes the message and sends it through the SMTP client to the original server. The user is not aware of the fact that an SMTP security server is in place.

2 The Security Gateway intercepts the SMTP connection and decides that the request should be sent to the security server. The connection is then folded into the security server.

3 The SMTP security server receives the connection and checks the appropriate resource of the rule to determine how to handle the connection (accept/drop).

4 The asmtpd daemon performs a separate rule match for every recipient.

5 After performing all the necessary actions, the message is transferred to the spool directory, and waits there for the mail dequeuer.

6 The mail dequeuer examines the spool directory for messages and performs the necessary actions (rewriting, mime stripping, and so on). Three subdirectories are located under the $FWDIR/spool directory: d_state, d_sender and d_resend. The message is first placed in the d_state directory.

7 If no errors are detected in the message, it is transferred to the d_sender directory, and from there MDQ tries to send it to the recipient.




8 If delivery of the message fails, the message is transferred to the d_resend queue. The message is queued in the resend queue from which the system tries to send the messages (when the process is not busy). Three types of messages can be placed in the spool directory. The initial letters of the files distinguish them (T, R, and E):• T stands for a Temporary file, which is not yet fully received.• R stands for a Ready file, which is ready to be sent on.• E stands for an Error file, which cannot be sent for some reason and needs to be

processed.

9 The SMTP security server receives a file that starts with T, and turns it into an R type.

10 The dequeuer takes the R file and sends it on, or processes it into an E file.

11 The mail dequeuer opens a new connection to the final SMTP server, and to the CVP server (if requested).

12 If a CVP connection is requested, the mail dequeuer receives the file from the CVP server, and completes the session by sending the message to the final SMTP server.

Improvements in SMTP

Improved Spool Handling

The spool-handling mechanism ensures FIFO behavior, and separates new mail from mail that has failed to be sent. This method grants new mail a higher priority level. This is achieved by using a new directory under $FWDIR/spool.

- d_resend, to which the system sends the mail messages that failed to be sent in the first attempt. The files are placed in a resend queue, from which the system tries to send a mail message, after two mail messages are sent from the immediate queue (d_sender).

SMTP Load Control

In previous versions, VPN-1 Pro would load the mail server with many mail files, thus causing performance problems in the mail server. In addition, the mail dequeuer opens a connection for every file. This problem is solved by adding the ability to adjust three parameters, using SmartDashboard, and opening the gateway's Workstation Properties window: • Maximum generated concurrent connections (in the SMTP page of the gateway's

Workstation Properties window)

92

Improvements in SMTP


• Maximum generated concurrent connection per site (in the SMTP page of the gateway's Workstation Properties window)

• Maximum mails per connection (configurable through the $FWDIR/conf/smtp.conf file, under the property max_mail_per_conn; by default this property is set to 20.)

FIGURE 10-7 SMTP Page - Workstation Properties Window

The load control is implemented by special queues called "send" queues. The number of these queues is set by the Maximum generated concurrent connections field. Each send queue contains a regular queue and potential connections. That number (regular+potential) is determined by the Maximum generated concurrent connections per

site field.

When the numbers for Maximum generated concurrent connections and Maximum generated

concurrent connections per site are identical, the sites battle for connections.

MX Records

An MX (Mail eXchange) query is a type of DNS resolution. The Security Gateway receives a recipient's name and resolves its domain. This is a kind of a proxy mode for SMTP, and it enables the SMTP security server to be the last among the SMTP entities handling the mail for outbound traffic.

If a mail file has recipients in more than one domain, it splits the original message by domain. When using MX resolving, there are two variables, configurable in the $FWDIR/conf/smtp.conf file, defining the number of resolved addresses that return:




• max_mx_node_per_mail (5 by default)• max_ips_per_mx_node (1 by default)

The maximum number of results is determined by the value received, by multiplying these two together.

Troubleshooting SMTP-Security Server Issues


SMTP security server problems might arise in three places:

1 Connection between the e-mail client and the SMTP security server

2 Connection between the mail dequeuer and the anti-virus (CVP) server

3 Connection between the mail dequeuer and the final e-mail server

E-mail Client Connection to Firewall SMTP Security Server Fails

To troubleshoot the connection between e-mail clients and SMTP security server:

1 Review SmartView Tracker to see if the e-mail connection is accepted from the appropriate rule in the Rule Base. Also check the Info column of SmartView Tracker. This is where the connection is described in more detail.

2 Make sure the e-mail has completed the queuing process and has a name of T#### (where ### is the e-mail order number, given by VPN-1 Pro), under the spool directory. This is located under the default installation directory of:\winnt\fw1\5.0\spool - for Windows/etc/fw/spool - for UNIX

3 If there is no file in this directory after the e-mail has been sent by the client, and the log file displays that the SMTP connection has been accepted, make sure the SMTP security server has been configured correctly. Validate this by running Check Point Configuration NGX for Windows, or /etc/fw/bin/cpconfig for UNIX. Make sure the SMTP security server is defined to start with the other security servers. This places a asmtpd entry into the directory:\winnt\fw\conf\fwauthd.conf - for Windows/etc/fw/conf/fwauthd.conf - for UNIXIf this entry does not exist, add the following line to the fwauthd.conf file:25 fwssd in.asmtpd wait 0

4 Run TELNET to the mail server on port 25, to see if the SMTP security server works. Enter the command help, to see SMTP Server replies.

94

Troubleshooting SMTP-Security Server Issues


Firewall Mail-Dequeuer Connection to Anti-Virus Server Fails


Troubleshoot the connection between the mail dequeuer and the anti-virus server as follows:

1 Make sure VPN-1 Pro can Ping the anti-virus (CVP) server.

2 If this is successful, determine if the anti-virus software has received an e-mail from the Security Gateway. This identifies if VPN-1 Pro has accepted the e-mail from the client, queued it, renamed the e-mail, and forwarded this on to the CVP server.

3 Validate that the proper CVP ports are configured on the CVP server, and the VPN-1 Pro resource. By default, the parameter FW1_cvp uses port 18181.

4 Run TELNET to the mail server on port 25, to see if the SMTP security server works. Enter the command help to see the SMTP server replies.

5 Use a packet sniffer, UNIX snoop, Windows Network Monitor Agent, or fw monitor, to determine if there is communication between the dequeuer and CVP server.




Mail-Dequeuer Connection to Final e-mail Server Fails


Troubleshoot the connection between the mail dequeuer and the final e-mail server as follows:

1 Verify VPN-1 Pro can Ping the final e-mail server.

2 Try to use the SMTP resource without the CVP server being defined. Install the Security Policy on VPN-1 Pro again, and determine if the e-mail passes from the queuer to the dequeuer, and then on to the final e-mail server. If the above works correctly, the problem lies with the CVP server. See “Firewall Mail-Dequeuer Connection to Anti-Virus Server Fails” on page 95..

3 Try to TELNET from the Security Gateway, to the final e-mail server on port 25, to determine if a connection can be made. This determines if the SMTP process on the e-mail server is configured and active, so the dequeuer can forward the e-mail to the final e-mail server.

SMTP Daemon Error Handling Mechanism

When configuring an SMTP resource, the Security Administrator can decide to notify the sender by setting the Notify Sender On Error option, and specifying the error-handling server. When an error occurs (a message was sent to a nonexistent user), the sender is notified by e-mail that the transaction failed, and given the reason. At the same time, the message is transferred to the error-handling server that tries to send it through its own channel. The error-handling server is supposed to be a fully qualified SMTP server.

Debugging SMTP Security Issues

The SMTP or MDQ must be running, to set debug mode for the security server.


To debug the SMTP security server, run the following commands:

1 Issue the fwstop command, or fw kill fwd.

2 On UNIX run:fw debug in.asmtpd on FWASMTPD_DEBUG 3

On Windows run:fw debug in.asmtpd on FWASMTPD_DEBUG=3

3 fwstart or fwd

96

Debugging SMTP Security Issues


Debug output is redirected to the file asmtpd.elg.

MDQ

In NGX, debug levels exist for the SMTP security server, to enhance debug output:• Debugging mime/file stripping:

fw debug mdq on TDERROR_ALL_MDQ_STRIP=3

• Debugging the content check of the header:fw debug mdq on TDERROR_ALL_MDQ_MAIL_HEADER=3

• Debugging the SMTP process - mail server:fw debug smtp on TDERROR_ALL_SMTP_DBG=3

• Debugging the mx resolvingfw debug mdq on TDERROR_ALL_MDQ_MX_DBG=3

Other information about the debugging ability for the SMTP security server can be found in solution sk23562.

Disable debug mode

To disable debug after the problem is reproduced:

1 Issue the fwstop command, or fw kill fwd.

2 On UNIX platforms run:fw debug in.asmtpd off FWASMTPD_DEBUG 3

fw debug mdq off MDQ_DEBUG_LEVEL 3

On Windows platform run:fw debug in.asmtpd off FWASMTPD_DEBUG=3

fw debug mdq on MDQ_DEBUG_LEVEL 3

3 Run fwstart or fwd.


FTP Security Server


FTP Security ServerThe FTP security server is optimized for security. Several FTP commands that could present risks are therefore denied access, as specified below:• SOCK commands - allow the user to open sockets (tunneling)• MAIL commands - allow the user to send and use e-mail through FTP

In addition to these security enhancements, the FTP security server provides protection from port spoofing, by not allowing ports to open to an IP address that is different from the one used to connect.

Although not recommended, it is possible to allow the prohibited SOCK, SITE and MAIL FTP commands. To allows these commands, create a file called aftpd.conf in the $FWDIR/conf directory, and add the following lines to it, depending on the type of commands for which you wish to grant access:• To allow MACB, add macb=1.• To allow MAIL, MLFL, MRCP, MRSQ, MSAM, MSND and MSOM, add mail_cmd=1.• To allow PORT command to known TCP ports, or to IP addresses different from the

client's, add port_spoof=1.• To allow REST, add restart=1.• To allow SOCK, add sock_cmd=1.• To allow SITE, add site_cmd=1.• To allow all other FTP commands, add optimist=1.

Bidirectional FTP Data Connections not Allowed

Unlike the FTP control connection that is a bidirectional connection, the DATA connection is unidirectional. One side sends ACK packets, and the other side sends DATA packets. FTP servers that allow bidirectional FTP connections allow FTP data connections from random ports on FTP servers.

The FTP Security Server always forbids bidirectional commands, because they are considered to be insecure. The FTP Security Server imposes unidirectional data transfer on connections opened with the PORT or the PASV command in the FTP protocol.

Note - SITE commands are allowed to pass during login through a proxy in the authentication process (sk26372).

98

PWD Command not Enabled on FTP Server


PWD Command not Enabled on FTP Server


When the FTP security server is enabled while issuing any data connection command, the FTP security server issues a PWD command: get, put, delete, midair, rename. The PWD command must be enabled on the server, otherwise the connection is dropped.

Adding Support for FTP Security Server Commands

The following commands are supported by FTP security server:ABOR, ACCT, ALLO, APPE, BYE, BYTE, CDUP, CWD, DELE, FIND, FW1C, HELP, LIST, MACB, MAIL, MDTM, MKD, MLFL, MODE, MRCP, MRSQ, MSAM, MSND, MSOM, NLST, NOOP, PASS, PASV, PORT, PWD, QUIT, REIN, REST, RETR, RMD, RNFR, RNTO, SITE, SIZE, SOCK, STOR, STOU, STRU, SYST, TYPE, USER, XCUP, XCWD, XMD5, XMKD, XPWD, XRMD.

To force the security server to allow possibly unsafe commands, see “FTP Security Server” on page 98 and SecureKnowledge solution ID 10022.0.2917673.2504701.

Session Authentication

In previous VPN-1 Pro versions there was a limitation where for Session Authentication rules that differ only in the user group (the source, destination and service are the same), the connection is only be matched against the first rule. Thus, a user belonging to the user group specified in the second Session Authentication rule is dropped. This limitation no longer exists. From NG, it is possible to configure Session Authentication rules that differ only in the user group.


FTP Security Server


100


CHAPTER 11

ClusterXL

In This Chapter

Introduction page 102ClusterXL Configuration Issues page 103Debugging Flags page 103Kernel Flags page 104High Availability page 110

101

Introduction


IntroductionClusterXL is a software-based Load Sharing and High Availability solution that distributes network traffic between clusters of redundant VPN-1 Pro Gateways, and provides transparent failover between machines in a cluster.

A VPN-1 Pro Gateway cluster is a group of identical VPN-1 Pro Gateways that are connected in such a way that if one fails, another immediately take its place.

FIGURE 11-1 A Firewalled Gateway Cluster

ClusterXL uses unique physical IP and MAC addresses for the cluster member, and virtual IP addresses to represent the cluster itself. Virtual addresses (in all configurations other than High Availability Legacy mode) do not belong to any real machine interface.

ClusterXL supplies an infrastructure that ensures that no data is lost in case of a failure, by making sure each gateway cluster is aware of the connections going through the other members. Passing information about connections and other VPN-1 Pro states between the cluster members is called State Synchronization.

VPN-1 Pro Gateway Clusters can also be built using OPSEC certified High Availability and Load Sharing products. OPSEC Certified Clustering products use the same State Synchronization infrastructure as ClusterXL.

102


ClusterXL Configuration IssuesFor information about ClusterXL configuration issues, and basic troubleshooting procedures, see the Check Point ClusterXL NGX (R60) Guide.

Debugging FlagsDebugging flags [-m cluster +]:• conf - Configuration related kdebug messages• if - Interface tracking and validation.• start - Cluster module state change• select - Packet selection including DF• ccp - Cluster control packet handeling• pnote - Pnote devce related• mac - mac address sync• forward - forwarding layer debug• df - decision function• drop - drops caused by SDF

To get a better debug in case you have a failover issue, please set the following kernel values to 1:• fw ctl set int fwha_dprint_io 1

• fw ctl set int fwha_dprint_all_net_check 1

Note - There is also the sync flag which is in the fw topic and shows debug that is related to sync only.

Chapter 11 ClusterXL 103

Kernel Flags


Kernel FlagsFor information on setting kernel flags so that the new value survives a reboot, refer to Sk20364.

In This Section:

fwha_enable_if_probing

Determines whether ICMP probing is enabled.

1 - turn the feature on (default)

0 - turn the feature off

When the parameter is turned on

At the point of fail-over:

1 The primary recognizes that no CCP (Cluster Control Protocol) messages have been heard on the failed interface. As such, the primary announces via state messages on all other segments that there can be an issue on the inbound direction with one of its interfaces.

2 The primary also notes that no CCP responses have been received on the failed interface. This causes the primary to announce on all other segments via state messages, that the outbound direction for one of its interfaces is in question as well.

3 At the same time as the above events, the secondary recognizes that no CCP packets have been received, and begins sending probing request messages on the affected segment. In addition, the secondary attempts ARP requests to hosts belonging to the affected segment, and begins pinging those hosts which respond. This is done in an attempt to diagnose which member has the problem. The pings

fwha_enable_if_probing page 104fwha_monitor_if_link_state page 105fwha_restrict_mc_sockets page 106fwha_send_gratuitous_arp_var page 106fw_allow_connection_traffic_drop page 107fw_allow_simultaneous_ping page 108fwtcpstr_reject_synced page 109fwconn_merge_all_syncs page 109

104

fwha_monitor_if_link_state


continue as long as the secondary cannot identify by other means (i.e. CCP packets) that the interface is alive. This happens when there are N cluster members, and N-1 of them are down. When more than two members are present, such pings are only issued if all other cluster members do not respond to CCP probing.

4 Since no probe message reply is received as a response, but the ping requests are being answered, the secondary concludes that its own interfaces are up and working, and that the interface of the primary has failed. Therefore, it announces via state messages, that all of its own interfaces are operational.

5 With this report from the secondary, the primary concludes the issue is with its own interface, and moves to the "Down/Dead" status.

6 The secondary issues gratuitous ARPs for both the physical, and cluster address per IP segment, and moves to the "Active/Active-Attention" state.

fwha_monitor_if_link_state

Determines whether the MILS feature is enabled or disabled.

1 - turn the feature on

0 - turn the feature off (default)

Testing ClusterXL with MILS Enabled

Remove a monitored interface connected to a network containing no hosts. ClusterXL detects which cluster member has its interface removed and will accordingly change the cluster’s state to Active/Down.

For more details see sk31336.


Kernel Flags


fwha_restrict_mc_sockets

Determines if a multicast socket is open.



When the parameter is turned off

When a clustering solution is being implemented (no matter if it is HA or LS) multicast sockets are opened for CCP.

When the parameter is turned on

When this parameter is turned on, the multicast socket is opened only on the sync interface.

fwha_send_gratuitous_arp_var

Controls the time that a gratuitous ARP is sent.



When the Parameter is Turned Off

During a system failure on an active primary cluster member, a secondary cluster member prepares to become the active member by sending a series of gratuitous ARPs for both the physical and Cluster IP for each segment. This updates all necessary hosts/routers on each segment with the relevant updated MAC address information. The secondary now moves to the "Active/Active-Attention" state, and assumes responsibility for processing all connections.

When the Parameter is Turned On

The active cluster member now sends gratuitous ARPs upon state changes of other cluster members, and on a periodic basis. Upon every state change of any of the other machines, the Active machine sends a gratuitous ARP immediately after 1 second, 30 seconds, and periodically every minute.

The periodic duration is configurable by the kernel parameter fw_gratuitous_arp _timeout. The default is 600 deciseconds, which is equal to 0.1 seconds.

106

fw_allow_connection_traffic_drop


fw_allow_connection_traffic_drop

Controls the behavior of the Flush and Ack mechanism on an unestablished connection.




There are cases in which a packet from the client to the server can be handled on member A and the return packet from the server back to the client can be handled on member B. For example if we have two cluster members in a loadsharing configuration: fw-a and fw-b. The first (SYN) comes via fw-a.

The Firewall holds this SYN and performs a state table sync with the other HA members. This is "flush and ack" (that is, to sync the information to all other members, and hold the packet until other members acknowledge that they have received the information). After this is complete, Firewall forwards the packet to its destination. Let’s presume the response (SYN, ACK) packet comes via fw-b and is passed through the originator. If the response to this (SYN, ACK) packet, the (ACK) comes within the state table sync interval i.e. before state-sync happens, to fw-a, then FW drops the packet by default. This behavior might result in re-transmissions and cause a delay. Certain applications, which are sensitive to this delay, might not able to work as expected, or encounter performance issues.


Allow this ACK packet to pass, or any packet that the connection has not yet established.


Kernel Flags


fw_allow_simultaneous_ping

Enables pinging the Virtual IP of the cluster regardless of failover events.




Suppose a cluster exists of two members, A and B, which connect to host H. Member A is the first to be active. Member B is the second to be active. When you ping/telnet/ssh or in general create a connection from H to the Virtual IP, what is actually saved in the connection table is the following information:H --> VIP

H --> A (assuming A is the first member to handle it) A --> H

A failover occurs, and now B is handling the traffic. B receives a packet from H and processes it, but the destination (VIP) is folded to the address of A and not the address of B because the members are synchronized, and such a connection already exists. B then attempts to forward the packet to A which originally handled the connection. Depending on the state of A, it might or might not answer.

In respect to the ICMP protocol it seems awkward to handle ICMP packets in this way, but for other stateful connections (like telnet) it is reasonable to forward the traffic to the daemon that can handle it. In the case of telnet, the telnet daemon on member B can not handle this connection. Firewall handles it in a generic way without any specific handling for non stateful protocols.

To test connectivity you should ping through the cluster and not to the VIP. If you do ping to the VIP, you can, in case of a failure, start a new connection by stopping and starting the ping so it gets a new sequence.


To make a continuous ping to work after failover, ICMP request/reply pairs have to be treated as a single connection. Setting this parameter ensures the ICMP request/reply pair is treated as a single connection by using the ICMP Sequence Number as the source port.

108

fwtcpstr_reject_synced


fwtcpstr_reject_synced



When the feature is off, passive streaming connections survive failover, but are not inspected by the streaming applications after the failover occurs.

When asymmetric routing exists, sometimes in IP clustering configurations, the connections are slow. To improve speed, turn this parameter off but only when:• Quick UFP is not in use• Packets going in the same direction on a specific connection always go through the

same cluster member.

fwconn_merge_all_syncs

Synchronizes the TCP state.




In loadsharing configurations, a user can experience “closed connections hang” for entire TCP session timeouts. When FW encounters FIN packets from both sides of a TCP connection, it lowers the connection's timeout from TCP session timeout (which is one hour by default) to the TCP end session timeout (which is typically set to less than a minute). In load sharing configurations, when routing is asymmetric, it is possible for a Firewall on one machine to discover that a certain connection is established when another machine has already encountered both FIN packets on the same session. When the less-updated machine synchronizes the other, the more-updated machine might increase the connection's timeout back to TCP session timeout. The connection then remains in Firewall's session table long after it was already finished. Such a scenario is also a possible DOS attack.


When fwconn_merge_all_syncs is set, FW synchronizes the TCP state correctly, not letting a non-updated entry override an updated one. This is possible with short TCP connections in load sharing configurations with asymmetric routing (static NAT/VPN /third party solution).


High Availability


High Availability

In This Section:

Introduction

In VPN-1 Pro version 4.1, the Management Server did not know which High Availability solution was installed on the cluster members. Enforcement Module configuration was completed via the command line, and stored locally on the Enforcement Modules using files. Internal communication between Enforcement Modules was allowed, using special services and rules. Synchronization of tables was completed using the "old" method, using fwd on port 256.

Version NG with Application Intelligence simplifies the use of the Check Point High Availability (HA) solution. The only task the Security Administrator must perform on the Security Gateway is to enable Check Point High Availability. The remaining configuration tasks are completed via the more user-friendly SmartDashboard.

Introduction page 110The CPHA Protocol page 115CPHA State Update Mechanism page 117Debugging CPHA Issues page 118ClusterXL Configuration Issues page 120

110

Introduction


The HA configuration is stored in the objects.C file. It is stored as follows:: (ha-sol2

:LS_mode ():certificates ():cluster_members (

:0 (:type (refobj):refname ("#_checkpoint-1")

):1 (

:type (refobj):refname ("#_checkpoint-2")

))

:CP_high_availability (true):HA_mode (ActiveUp):VPN ():availability_mode (HighAvailability)

:synchronization_networks (: (

:description (secured):ipaddr (10.0.0.0):netmask (255.0.0.0)

))

MAC Address-Configuration Information

The only information stored on Security Gateways is MAC address configuration. MAC addresses are stored in the following locations:

Platform Location of MAC Address Configuration

Solaris /etc/etheraddr <interface name>

Windows registry: HKEY_LOCAL_MACHINE\SYSTEM\Current control set\Services\Interface name\Parameters\Network address

Linux /etc/sysconfig/network-scripts/ifcfg-<interface_name>


High Availability


Check Point HA Sync Methods in NGX

From version NG, the only synchronization (sync) method is the “new sync”, which is used for delta sync. Delta sync is performed periodically; either when the sync buffer is full, every 0.1 seconds, or when there is a special request to send it immediately. Full synchronization is still completed by fwd on port 256, using the new sync.

There is no longer a need to configure the old sync, and exchange putkeys to make sync work. fwd looks at the IP addresses of the cluster members, and initializes a connection to port 256 with those peers. After the connection is established, full sync is completed.

Cluster Control Protocol

The Cluster Control Protocol is a proprietary Check Point protocol. It is the basis of HA solution functionality, and also of new sync. This protocol uses port 8116 UDP for internal communication between the Check Point High Availability (CPHA) cluster members, or VPN-1 Pro Security Gateways, using an external HA solution. A dedicated network must be allocated for the secured channel of cluster-control internal communication. It is important to secure both policy changes, and new-sync communication, which is not encrypted.

The CPHA protocol displays ten types of messages:• Report source machine state• Query other machine’s state• Interface active check (probe) request• Interface active check (probe) reply• Interface configuration request• Interface configuration reply• LB (Load balancing) configuration report• LB configuration report and a request for its confirmation (an FWHAP_LB_CONF

reply)• Policy ID change request/notification• New Sync packet

112

Introduction


Analyzing CPHA Packets

CPHA packets are sent as a type of “old broadcast”. Analyzing packets is difficult to perform, without a reference to the structure of a packet's data. A typical CPHA packet looks like the following. It is impossible to know the source and destination of the packet:6 0.00468 OLD-BROADCAST -> 10.0.0.0 ETHER Type=0800 (IP), size = 66 bytes6 0.00468 OLD-BROADCAST -> 10.0.0.0 IP D=10.0.0.0 S=0.0.0.0 LEN=52, ID=06 0.00468 OLD-BROADCAST -> 10.0.0.0 UDP D=8116 S=8116 LEN=320: ffff ffff ffff 0000 0000 fe00 0800 4500 ..............E.16: 0034 0000 0000 3c11 74ba 0000 0000 0a00 .4....<.t.......32: 0000 1fb4 1fb4 0020 fb02 1a90 0002 0001 ....... <FB>....48: 0005 0000 7090 0000 ffff 301b 0000 0000 ....p.....0.....64: 0000

..

The analysis of the packet is simple using the following matrix:FIGURE 11-2 Analysis matrix for a CPHA packet

It is important to pay attention to the following fields:• HA Opcode on the 48th byte: This byte defines the type of functionality of this

packet. In this case, it is an interface-configuration request initialized by the primary machine of cluster with ID 1.

• HA protocol on the 44th byte: The type of HA protocol. 2 is for NG and higher, and 1 is for 4.1.

• Source machine ID on the 56th byte: The ID number of the machine. In this case it is 0, which means Primary. This number is always the machine ID (as reported by cphaprob state) minus 1.


High Availability


The following packet is of type interface configuration reply (according to its 48th byte):7 0.00013 OLD-BROADCAST -> 10.0.0.0 ETHER Type=0800 (IP), size = 78 bytes7 0.00013 OLD-BROADCAST -> 10.0.0.0 IP D=10.0.0.0 S=0.0.0.0 LEN=64, ID=07 0.00013 OLD-BROADCAST -> 10.0.0.0 UDP D=8116 S=8116 LEN=440: ffff ffff ffff 0000 0000 fe01 0800 4500 ..............E.16: 0040 0000 0000 3c11 74ae 0000 0000 0a00 .@....<.t.......32: 0000 1fb4 1fb4 002c 2b90 1a90 0002 0001 .......,+.......48: 0006 0000 7018 0001 ffff 301b 0000 0000 ....p.....0.....64: 0001 00e0 18a8 ac0a 0001 0a00 003c .............<

The packet can be analyzed by looking at the following fields:• HA Opcode at the 48th byte: Type 6 is interface-configuration reply.• Source machine ID at the 54th byte: 01 is the Secondary machine.• Ether address starting at the 66th byte and ends at the 74th byte: It is the MAC

address of the source machine's interface.• Is IF trusted at the 72nd byte: 1 means this is the secured interface sending the

packet.• Network address at the 74th byte: The secured network.• Host address at the 76th byte: The IP address of the host sent the packet

(10.0.0.60).

To analyze all CPHA packets, use the general matrix of CPHA packets in “General Analysis Matrix for CPHA Packets” on page 119.

114

The CPHA Protocol


The CPHA Protocol

CPHA modules start running when the product is enabled from the Check Point Configuration Tool (cpconfig). From that moment on, Security Gateways keep checking the state of their peer: its configuration, its Security Policy, its priority, MAC addresses, and other parameters. The following sections focus on two of the actions CPHA modules routinely perform:• Synchronizing MAC addresses• Updating cluster members about state

MAC Address Configuration

CPHA is a hot-standby solution. Each cluster member must have the same properties as the Primary machine for its shared network interfaces. IP configuration is completed manually by the Security Administrator on each of the machines. However, MAC address configuration is very different.

MAC addresses of the cluster members are synchronized on several occasions:• During initial Security Policy installation• When the machine comes up after reboot. Also, cluster members query each other

from time to time, to check their status. Of course, unique interfaces are not changed at any time. The modules use the CPHA protocol to synchronize their MAC addresses.

• When each machine boots (when the kernel loads), it starts sending CPHA packets informing the cluster that this machine is alive. Part of these packets contain the real MAC address of the interface the packet was sent on. These packets are sent on all interfaces. Cluster members learn which other machines are around, their IP addresses, MAC addresses, random IDs, and cluster ID.

• As soon as the first Security Policy arrives, the machine checks the data it gathered, and analyzes it in the following way:• If there are other Security Gateways with the same IPs, and cluster ID, the

Security Gateway takes the MAC address from one of the other Security Gateways (see below).

• If there are no machines with the same cluster ID, it could be that no other Security Gateways are configured. Among all Security Gateways with the shared IP, the one with the lowest random ID determines which MAC addresses are taken.

• If there are Security Gateways that are already configured (already cluster members), they have all synchronized their MAC addresses. The MAC addresses are the same on all configured machines, and thus it does not matter from which machine the new Security Gateway takes the MAC address.


High Availability


Preconfigure Mode

Consider a situation where NGX is installed on all cluster members, and HA is enabled on them all. If a Policy is not installed on any of the machines, none of them are actually configured as Primary, Secondary, etc. The cluster cannot function if one machine fails. In this scenario, “preconfigure mode” occurs. In preconfigure mode, all machines look at the random IDs of all peers, and synchronize their MAC addresses with the machine considered Primary, which is the one with the lowest random ID. The decision is made when a configuration arrives from a Security Policy installation.

Preconfigure mode also comes into effect when a Policy is not installed, immediately after the Security Gateways come up after boot, or when running cphaconf init.

Analyzing the Preconfigured Data Packet

After the CPHA cluster has been configured, the Administrator sets up the priorities of each Security Gateway, and installs the Policy. When the Policy is installed, the machines look at the ID number of their peers, and synchronize MAC addresses as described in MAC Address Configuration. Each time a change occurs in the Security Policy, the machines look at the machine ID of their peers.

Consider this preconfigured packet's data, and analyze with the matrix:0: ffff ffff ffff 0000 0000 fe21 0800 4500 ...........!..E.16: 0040 0000 0000 3c11 74ae 0000 0000 0a00 .@....<.t.......32: 0000 1fb4 1fb4 002c 5348 1a90 0002 ffff .......,SH......48: 0006 0001 3e0d 0021 ffff 0000 0000 0000 ....>..!........64: 0001 0000 0000 0000 0000 0a00 001e ..............

The matrix shows that this packet was sent from 10.0.0.30, as reported in the bytes 74-78. It is a preconfigured packet, since the source machine ID is set to 0x21 as reported in bytes 54-56, and the cluster ID is 0xffff, as reported in the bytes 46-47.FIGURE 11-3 CPHA Preconfigured Packet-Analysis Matrix

116

CPHA State Update Mechanism


CPHA State Update Mechanism

CPHA modules send updates about their state every 0.1 seconds. The updates are sent on all interfaces, but packets coming in on the secured interfaces are considered more reliable. Here is an example:2 0.04832 OLD-BROADCAST -> arpanet ETHER Type=0800 (IP), size = 78 bytes2 0.04832 OLD-BROADCAST -> arpanet IP D=10.0.0.0 S=0.0.0.0 LEN=64, ID=02 0.04832 OLD-BROADCAST -> arpanet UDP D=8116 S=8116 LEN=440: ffff ffff ffff 0000 0000 fe01 0800 4500 ..............E.16: 0040 0000 0000 3c11 74ae 0000 0000 0a00 .@....<.t.......32: 0000 1fb4 1fb4 002c 6919 1a90 0002 0002 .......,i.......48: 0001 0000 8228 0001 ffff 76e4 0000 0002 .....(....v.....64: 0003 0003 0064 0004 0002 0002 3500 .....d......5.

This is a packet sent from the Primary machine of cluster 2 on network 10.0.0.0:FIGURE 11-4 Analysis Matrix for CPHA Status-Update Packet

The matrix shows this packet was sent from the Primary machine of cluster 2 (bytes 6-12) to its members. The machine reports about the state of two interfaces. (Bytes 62-63 report that the cluster member is reporting about two items. Bytes 64-65 report that it is a report about interfaces.) The state of interface 0 of the machine is down (byte 70, value 0), and the state of Interface 2 is active (byte 71, value 4). Notice byte 68. This is the HA time unit. It is 100 milliseconds. Every action is measured in HA time units.


High Availability


Debugging CPHA Issues

The best way to debug CPHA issues depends on the scenario:• If there are many collision error messages about “other machine <MAC address>

trying to be our <IP address>”, this is probably because the shared interfaces of the Security Gateways were not disconnected before enabling and configuring the CPHA modules.

• Other problems related to the functionality of the CPHA product should be debugged, based on error messages generated by the CPHA module, and a snoop on port 8116.

• In some cases, the kernel needs debugging. Note that debug output is quite complex to understand. It is best therefore to send debug output to Check Point Technical Support. Debug the kernel as follows:

a. Set the debugging flag to 0:fw ctl debug 0

b. Allocate a buffer for all messages generated by the kernel:fw ctl debug -buf

c. Set the debug flags - you can find the common flags below:fw ctl debug XXXX XXXX XXXX

d. Run debug:fw ctl kdebug -f > <file name>

e. Stop debug once the information has been collected using <CTRL+C>.

f. Set the debugging flag back to 0:fw ctl debug 0

Common cluster-debug flags are specified in “Debugging Flags” on page 103.

118

Debugging CPHA Issues


General Analysis Matrix for CPHA PacketsFIGURE 11-5 General Analysis Matrix for CPHA Packets


High Availability


ClusterXL Configuration Issues

Separate the secured networks of each ClusterXL cluster. The CCP (Cluster Control Protocol) changes from version to version. If you connect the secured interfaces of several ClusterXL clusters of different NGX versions, and add a 4.1 cluster to the same hub or VLAN, each of them hears the others' port 8116 traffic. This leads to confusion among the various cluster members. Therefore, higher versions stop passing CCP traffic and report a problem. Only the lowest version remains working. It is assumed the lowest version was in production first, and nothing should interfere with its work.

An appropriate configuration is to place each cluster on its own hub, VLAN, or switch. Full isolation must be kept on the secured network.

Modes of ClusterXL Supporting SecureXL

All ClusterXL modes are supported.

Crossover Cable Support between Two Cluster Members

A major difference between using a crossover cable and a hub/switch is when the link is disconnected. Notice that in hub/switch configuration, other than cluster members, at least one more host should be connected to the same hub/switch. When using a crossover cable, both members receive a "link down: event, and automatically change state to “down”. Special code is needed to support such cases, making one of the members still receive packets: "Active attention" mode. This additional logic is implemented in the ClusterXL product. With a hub/switch, only one member notices the problem, and can be removed from the cluster. The second member has no knowledge of the problem, and continues working normally.

Third-party clusters can choose to add this support. If this special logic is not implemented, a hub/switch must be used, otherwise, both members move to a down state (both notice the link down).

ClusterXL Error Messages and Meanings

FW: changing local mode from <MODE1> to <MODE2> because of id <MACHINE_ ID>

This log happens if the working mode of the cluster members is not synchronized (that is one machine runs HA, and another works in Load Sharing mode). In this case, the internal ClusterXL mechanism tries to synchronize the configuration of the cluster members, by reducing the working mode to the lowest common mode. The following are the priorities of the working modes: Sync only > Load Sharing > High Availability

(Active Up) > High Availability (Primary Up).

120



CPHA: received confirmations from more machines than the cluster size

This log message occurs during Policy installation on the cluster. It means a serious configuration problem exists in the cluster. It could indicate another cluster is configured with identical parameters, and the clusters have common networks.

FWHATIMEWORKER: wait failed (STATUS <NUMBER>)

This error can occur on Windows multi-CPU machines. When it occurs, ClusterXL does not operate. This is caused by an operating-system failure.

FW: FWHA_RESET_TIMER: failed to allocate TIMER DPC

This is a critical log message on Windows platform. ClusterXL halts, due to an underlying operating-system failure.

FW: FWHA_RESET_TIMER: failed to allocate TIMER object

This is a critical log message on Windows platform. ClusterXL halts, due to underlying operating-system failure.

FW:%S: there are more than 4 IPs on interface <INTERFACE NAME> notifying only the first ones

This message indicates that another cluster member, who belongs to the same cluster as the reporting machine, has more than three virtual IP addresses defined on the same interface. This is not a supported configuration, and harms ClusterXL functionality.

FW: FWHA_CREATE_ICMP_ECHO_REQUEST: failed to create packet

This log message occurs when system resources are very low, which harms ClusterXL functionality.

Inconsistencies between policies installed on cluster members

Inconsistencies exist between policies installed on the cluster members. Please reinstall the

policy on the cluster is sent when the Policy is different between two members. This occurs if two cluster members are on different operating systems (such as Linux and Windows).

SYNC could not start because there is no sync license

This is a license error message. If you have a basic Firewall license, sync is also licensed. Check the basic Firewall license.


High Availability


FWLDBCAST_TIMER: PEER X probably stopped...

This is caused when the member that printed this message stops hearing certain types of messages from cluster-member peer X. Verify cphaprob state displays all members as active. Verify that fw ctl pstat shows sync is configured correctly, and working on all cluster members. In such a case, it is probable a temporary connectivity problem that was corrected. There might be several connections suffering from connectivity problems, due to temporary synchronization issues between the two members. This can also indicate the other cluster member is really down.

Full SYNC issues with opened and closed connections during SYNC process

Similar problems can occur during a full sync session when there are connections opened and closed during the full-sync process. The full sync is performed as granularly as possible, but is not fully granular for reasons of performance. A Gateway continues to process traffic, even when serving as a full-sync server. This can cause some insignificant problems, such as connections being deleted twice, a link to an existing link, and so on. It should not cause lack of connectivity or security issues. Error messages connected to this issue include:• FW: h_slink: an attempt to link to a link

• kbuf id not found• fw_conn_post_inspect: fwconn_init_links failed

FWLDDIST_ADJUST_BUF: record too big for SYNC

This can happen, if you open active connections from SmartView Tracker, as it uses the infrastructure of the delta sync. This error can also occur during a full sync, when the active machine is very loaded. The meaning of the error indicates sync might not have been successful, for some entries. Sync recovers from this error. It can also appear during delta sync under load.

Error SEP_IKE_OWNER_OUTBOUND: other cluster member packet in outbound

The cluster is not synchronized. This error usually appears in third-party loadsharing solutions, where use_limited_flushnack is set to false.

FW : FWHA_PNOTE_REGISTER: too many registering members, cannot register

The Pnote mechanism can only store up to 16 different devices. An attempt to configure the 17th device (either by editing the cphaprob.conf file or by using the cphaprob -d... register command) results in this message.

122



FW : FWHA_PNOTE_REGISTER: <NAME> already registered (# <NUMBER>)

Each device registered with the Pnote mechanism must have a unique name. This message might appear when registering new Pnote device, and means that the device <NAME> is already registered as with Pnote number <NUMBER>.

FW : FWHA_PNOTE_REG_QUERY: pnotes not relevant in service mode

Pnotes are only configured when using a ClusterXL cluster. Third-party HA/load-sharing solutions do not support Pnotes.

fw ctl pstat Sync Output

One of the tests performed to verify sync is working, is to run the command fw ctl pstat. This is the sync output:sync new ver working sync out: on sync in: on sync packets sent:

total: 12038 retransmitted: 0 retrans reqs: 0 acks: 2297

sync packets received:

total 10567 of which 0 queued and 0 dropped by net

also received 0 retrans reqs and 188 acks to 167 cb requests

callback average delay 1 max delay 1

Please find below a short explanation of each parameter:sync new ver working

This line is a must if sync is configured. It indicates sync is working (new sync, versus old sync in 4.1).sync out: on sync in: on

If one is off, there is a problem. Off state can be a temporary condition during boot, but should not happen during normal operation. sync in can be in “save” mode when receiving full sync.sync packets sent:

total: 12038 retransmitted: 0 retrans reqs: 0 acks: 2297

Total send packets is the number of sync packets sent. A retransmission request is performed when a sync packet is received out of order. This number might increase when under load. acks refer to acknowledgements sent for received sync packets, when it was requested to acknowledge. Notice the total number of sync packets does not equal 0, and increases.sync packets received:

total 10567 of which 0 queued and 0 dropped by net


High Availability


Total received packets is the number of all received sync packets. The queued- packets figure is increased upon reception of a sync packet that complies with one of the following two cases:• The sync packet is received, with a sequence number that is not just following the

previously processed sync packet.• The sync packet is fragmented. This is used to solve MTU restrictions. This figure

is never decreased. Therefore, it is acceptable to have a non-zero value.

The dropped by net number might indicate network congestion. This number might increase slowly under loads. If this number increases too fast, a networking error might interfere with the sync protocol. Check the network.also received 0 retrans reqs and 188 acks to 167 cb requests callback average delay 1 max delay 1

This refers to retransmission requests received, in comparison to the ones sent in the section above. When this number grows very fast, it might indicate the load on the machine is becoming too high for sync to handle. acks refer to the number of acknowledgements we received for the cb request sync packets, which are sync packets with requests for acknowledgments. The callback delay is how much the packet was delayed in this member, before it was released. The delay happens when packets are held, until all other cluster members acknowledge the information within it. This figure is measured in terms of the receive window of the sync layer. Normally this number should be small (~1-5). Larger numbers might indicate load of sync traffic, which causes certain connections (connections that require sync acknowledgements) to suffer from slight latency.

124


CHAPTER 12

Voice Over IP (VoIP)

In This Chapter

Introduction page 126Debug Commands page 127Using the Debug page 128

125

Introduction


IntroductionVPN-1 Pro secures VoIP traffic in H.323, SIP, MGCP and SCCP environments. VoIP calls involve a whole series of complex protocols, each of which can carry potentially threatening information through many ports. The following figure is an overview of the VoIP protocols supported by VPN-1 Pro.FIGURE 12-1 Secured VoIP Protocols: SIP, H.323, MGCP and SCCP

VPN-1 Pro verifies that caller and receiver addresses are located where they are supposed to be, and that the caller and receiver are allowed to make and receive VoIP calls. In addition, VPN-1 Pro examines the contents of the packets passing through every allowed port, to verify that they contain proper information. Full stateful inspection on H.323, SIP, MGCP and SCCP commands ensure that all VoIP packets are structurally valid, and that they arrive in a valid sequence.

126

SIP


Debug CommandsThe following debug commands are used for VoIP SmartDefense protections. When using these commands, it is recommended to add drop, conn and ld to each debug session by adding the command: fw ctl debug + drop conn ld.

SIPfw ctl debug -buf 16000

fw ctl debug + sip

fw ctl kdebug -f > file.dbg

mgcp

fw ctl debug -buf 16000

fw ctl debug +mgcp


skinny


fw ctl debug -m CPAS skinny


MSNMS


fw ctl debug + msnms sip


H.232fw ctl debug 0


fw ctl debug -m h323 all


Chapter 12 Voice Over IP (VoIP) 127

Using the Debug


Using the Debug1 Run one of the above debug commands, depending on the scenario.

2 Run fw monitor -e "accept;" -o file.out together with the debug.If the connection contains NAT, add the flag: nat xlate xltrc. For example:

fw ctl debug + nat xlate xltrc

fw ctl debug -m CPAS skinny

3 Replicate the scenario that is being investigated.

4 After replicating the issue, stop the debug.

In This Section

All Protocols Messages page 129SCCP (Skinny) Messages page 129MGCP Messages page 130MSN over SIP Messages page 130SIP Messages page 131H.323 Messages page 132

128

All Protocols Messages


All Protocols Messages

SCCP (Skinny) Messages

Log Message Cause Resolution

Illegal redirect X.X.X.X-> X.X.X.X

• A VOIP Domain object was defined, but was not included in the rule base.

• These addresses are not part of the related endpoints.

1. If a VOIP domain is not required, delete the VOIP domain object.

2. If a handover domain is required, add the handover domain to the Rule-base.

3. If a handover domain is required, add the related endpoints addresses to the corresponding handover domain.

Host exceeded call limit (possible spam or Dos attack)

When the number of calls exceeds the defined number of call attempts. In SmartDefense VoIP (Enable

VoIP DOS Protection), further packets are rejected.

• Increase the number in Smart Defense

Or:• Deselect the Enable VOIP

DOS Protection checkbox.


Unknown SCCP message type

The specific SCCP protocol is not supported by the Firewall.

Contact Check Point Technical Support.

Connection contains real IP of NATed address

A message between the Call Manager and the Gateway should be NATed, but contains the real IP address.

NAT for SCCP service is not supported by VPN-1 Pro. NAT should not be applied on the Call Manager and its related endpoints


Using the Debug


MGCP Messages

MSN over SIP Messages


Unallowed MGCP datagram, command blocked

In SmartDefense, this message is not in the list of allowed commands.

Add the command to the allowed commands list.

broadcast/multicast addresses are not accepted (client)" / (server)

In SmartDefense, you can allow rtp in multicast mode.

Deselect the Drop multicast

RTP connections option in SmartDefense.


A message between the Call Manager and the gateway should be NATed, but contains the real IP address.

NAT for SCCP service is not supported by VPN-1 Pro. NAT should not be applied on the Call Manager and its related endpoints


File Transfer is not allowed by the security policy

1. The service MSN_Messenger_File_

Transfer is not allowed in the rule base.

2. In SmartDefense under MSN over SIP, the Block file

transfer option is checked.

1. Deselect Block File Transfer in SmartDefense.

2. Add the MSN_Messenger_File_

Transfer to the rule base.

Application Sharing is not allowed by the security policy

In SmartDefense under MSN

over SIP, the Block application

sharing option is checked.

Deselect Block Application

Sharing in SmartDefense.

Whiteboard is not allowed by the security policy


over SIP, the Block Whiteboard is checked.

Deselect Block Whiteboard in SmartDefense.

Remote Assistance is not allowed by the security policy


over SIP, the Block Remote

Assistance option is checked.

Deselect Block Remote

Assistance in SmartDefense.

130

SIP Messages


SIP Messages

Instant Messaging is not allowed by the security policy


over SIP, the Block SIP based

instant messaging option is checked.

Deselect Block SIP based

Instant Messaging in SmartDefense.

Illegal redirect X.X.X.X-> X.X.X.X

In SmartDefense under VOIP

under SIP, the Blocked calls

using a proxy or a redirect

server option is not checked.

Deselect Blocked calls using a

proxy or a redirect server in SmartDefense.



NOTIFY message out of state

This message can appear for numerous messages, not only NOTIFY. It usually indicates a problem in the SIP state machine.

Contact Technical Support services after you collect the relevant SIP debug.

Violated unidirectional connection

This log is usually issued when trying to use bi-directional SIP connections.

In the rule base, add sip_dynamic_ports service (in the UDP services list) to the corresponding SIP rule.


A real IP appeared instead of the NATed IP.

Contact Technical services after you collect the relevant SIP and NAT debug.

Malformed SIP datagram, invalid SIP headers

This is issued when the firewall expects a certain field in the SIP packet, but the field is missing.

Contact Technical services after you collect the relevant SIP debug.

Enforcing major security - reinvents rejected

This message appears when the destination tries to reinvent a call.

Deselect Block the destination

from re-inviting calls.


Using the Debug


H.323 Messages

Reinvents exceeds the limit

In SmartDefense under Application intelligence, in the VOIP section under SIP, the Maximum invitations per call option has been exceeded.

Increase the number of Maximum invitations per call.

The allowed maximum is 4.


Received Unregistration request without prior registration

When the h323_registration table is empty and the phone executes an Unregistration request.

1. Reopen the H.323 client to register the new details again.

2. Adjust the registration times in the Advanced

Service Properties window for H.323_ras.

Invalid H.225 session. Not initialized with Setup Message

This message appears when H.225 are seen without a setup message.

Due to a configuration problem in the network, the Firewall did not see the setup message.

Confirm to unknown request

ACF/GRQ/GCF/LRQ/LCF seen without a prior ARQ

Possible routing problem.

Malformed RAS message. No source phone number found

The Firewall supports the phone number in an E.164 format.

Verify that the destination/source number are in E.164 format.


132


Section 3:VPN-1 Pro and Desktop Security


CHAPTER 14

Internal Certificate Authority (ICA)

In This Chapter

IntroductionA SmartCenter Server includes an ICA (Internal Certificate Authority), which provides X.509-based certificate services for Check Point components. The ICA is used for:• SIC, which provides secure communications for Check Point components

(including OPSEC applications), replacing fw putkey.• Hybrid Mode RAS VPN, for authenticating VPN-1 Pro Security Gateways to

SecuRemote/SecureClient users.• VPN modules in site-to-site VPNs, eliminating the need to use pre-shared secrets,

and enabling easier scaling of VPN networks.

The ICA is automatically created during installation or upgrade, and is responsible for overseeing the generation, signing, and revocation of certificates.

Introduction page 135Implementation page 136Internal CA Management Tool page 139Internal CA High Availability page 146

135

Implementation


Implementation

In This Section

Requirements

The ICA only runs on a SmartCenter Server, and must be initialized before Security Gateways are remotely managed.

Initialization and Configuration

SmartCenter server

The ICA is created automatically by the Check Point configuration application (cpconfig) on the SmartCenter Server, and then creates a certificate for the SmartCenter Server.

Security gateway

The Check Point configuration application (cpconfig) starts an agent, to wait for a certificate to be pushed to the Security Gateway from the SmartCenter Server. The Gateway's certificate is initialized on the SmartCenter Server, and pushed to the Gateway from SmartDashboard. IKE certificates are managed in the Certificates tab of the Security Gateway's Workstation Properties window.

Revocation

The Security Gateway's certificate can be revoked from the SmartDashboard. After revocation, the Security Policy must be re-installed.

Validation

Certificate validation is performed using OPSEC PKI.

Requirements page 136Initialization and Configuration page 136PKI and PKCS page 137Recovery and Renewal with OPSEC Certified CA page 137Recovery and Renewal with Entrust CA page 138

136

PKI and PKCS


PKI and PKCS

When a VPN tunnel is established between Gateways managed by the same SmartCenter Server, both sides can present the certificate issued for them by the ICA to each other.

When two entities try to establish a VPN tunnel, each side supplies its peer with some information signed by its private key, and with the certificate that contains the public key. Having these pieces of information, the peer can use the public key to verify the source of the signed information, and to validate the certificate's authenticity. In other words, the validated certificate is used to authenticate the peer. This operation is crucial for fulfilling the authenticity requirement when establishing VPN tunnel. However, it can be done only if the Certificate Authority (CA) that had signed the peer's certificate is trusted. In addition, each side must have a valid certificate, to begin this process. These operations, as well as other PKI operations, must be supported in any environment that makes use of X.509 certificates.

When a certificate is revoked or becomes expired, there is a need to create another one or refresh the existing one.

Recovery and Renewal with OPSEC Certified CA

Renewal and recovery of a certificate are done by creating a certificate, using the same procedure for creation of a new one. To create a PKCS#11 Certificate Request:

1 Open the VPN tab of the relevant Network Object.

2 In the Certificate List field, press Add... The Certificate Properties window displays.

3 Enter the Certificate Nickname. The nickname is only an identifier, and has no bearing on the certificate content.

4 Choose the OPSEC Certified CA from which you would like to get the certificate.

5 Choose the appropriate method for key-pair creation and storage. The Store Keys On

Module option is relevant only if hardware storage is installed on the module.

6 Click Generate... The Generate Certificate Properties window appears.

Note - Automatic renewal is available in addition to PKCS#11.

Note - Store Keys On Module can be done with SW as well as Hardware.

Chapter 14 Internal Certificate Authority (ICA) 137

Implementation


7 Enter the desired Distinguished Name (DN). Please note that the final DN in the certificate is subject to the CA administrator decision.

8 If for some reason the Subject Alternate Name extension should appear in the certificate and contain the DN, check the Define Alternate Name box.

9 Click OK. According to your setting for the key-store location, SmartCenter Server or module, generate the key pair. The public key and DN are then used to encode a PKCS#11 Certificate Request.

10 Once the Certificate Request is ready, click View. The Certificate Request View window appears with the encoding.

11 Copy all text in the window, and deliver it to CA. This is usually done in the means the specific CA offers, such as an advanced enrollment form, versus the regular form).

Recovery and Renewal with Entrust CA

The recovery and renewal procedures are similar to the procedure for generating a new certificate:

Configuration of PKI operations

1 Obtain the Reference Number and Authorization Code from the CA administrator. These numbers are created by the Entrust CA when willing to make an entity "Entrust Enabled," and presented to the CA administrator, who can deliver them to the VPN-1 Pro Security Administrator. They are used by CA to authenticate the request and issue the certificate.

2 Click the VPN tab of the relevant network object.

3 In the Certificate List field, press Add... The Certificate Properties window displays.

4 Enter the Certificate Nickname. The nickname is only an identifier, and has no bearing on the certificate content.

5 Choose the Entrust CA from which you would like to get the certificate. The CA object must be previously defined.

6 Click Generate... The Generate Keys and Get Entrust Certificate window appears. Ensure the Generate Mode is set to Initialize.

7 Enter the Reference Number and Authorization Code. SmartCenter Server generates the key pair, and connects the Entrust CA using its appropriate protocol, to yield the required certificate. If this is the first certificate issued to a module managed by this SmartCenter Server, the Entrust CA certificate is saved from this

138

Recovery and Renewal with Entrust CA


communication. It is recommended to reopen the Entrust CA object later, and verify that the CA Certificate was stored, by clicking View... in the Entrust PKI tab of the Certificate Authority Properties window.

8 Close and save the object.

Internal CA Management ToolThe Internal CA Management Tool allows Administrators to manage and view the ICA database. The ICA is managed using two kinds of interfaces: one is by a browser using HTTP/HTTPS (for VPN-1/Fire Wall-1 NG with Application Intelligence and higher), and another by using SmartDashboard (before version VPN-1/Fire Wall-1 NG with Application Intelligence).

Administrative capabilities include:• Searching for a specific certificate in the database, and adding it to a list for later

revocation or removal.• Downloading any certificate to local disk.• Initiating certificates for single or multiple users (batch operation), including

sending mail notifications.• Recreating corrupted CRL files.• Configuring ICA attributes.• Switching between old and new CRL modes.• Downloading any CRL.• Cleaning the CA's database; removing expired from database and CRLs.

The ICA daemon (cpca) has basic HTTP server capabilities. It listens on port 18265/TCP, and waits for SmartCenter Server requests. When receiving a request (in an HTTP form), cpca finds the relevant action, and sends the results back to the requester. To connect to the ICA using this address, use https://<managemet_name>:18265/ with any browser on any platform.

There are two levels of administration:• Admin Level - allowed to perform any action• User Level - not allowed to use the advanced options (revoke / remove / clean /

configure / recreate)

Only a Security Administrator whose DN is configured in the internalCA.C file located in $FWDIR/conf is able to connect. Otherwise an access-denied error appears.

The ICA's own certificate is installed, by browsing to:http://<management_name>:18264/


Internal CA Management Tool


In This Section

Configuration Information

Access to the Internal CA Management Tool is disabled by default. The following command allows access to this tool:cpca_client_set mgmt_tool on -a <DN of admin who is allowed to connect>

Only a Security Administrator whose DN is configured in the internalCA.C file located in $FWDIR/conf is able to connect. Otherwise, an access-denied error appears. To enable access to Internal CA Management Tool, the Administrator must perform the following actions:

1 Create an Administrator certificate for himself from the ICA, in p12 format. This is done by creating a new Administrator from the Users tab in the SmartDashboard, creating a certificate for this Administrator, and saving the returned p12 file to disk.

2 On the machine from which the Administrator wants to connect to the ICA, the p12 certificate should be installed to the browser's certificate store. This is accomplished by double-clicking the p12 file, and going through the import wizard.

3 On the SmartCenter Server, run cpca_client_set mgmt_tool on -a <DN of admin who is allowed to connect>, to enable the Internal CA Management Tool. Property :mgmt_tools_web_gui is set to (1) in the InternalCA.C file.

Configuration Information page 140Command Line page 142InternalCA.C File page 142Administrator Login page 143Benefits of the Internal CA Management Tool page 144Batch Operations page 145

140

Configuration Information


4 To set the ICA Administrator, run the following command:cpca_client set_mgmt_tool on -a "CN=username,OU= administrative users bench, O=ICA FQDN"

For example:cpca_client set_mgmt_tool on -a "CN=admin,OU= users, O=firewall.domain.com.9td"

In the InternalCA.C file the following is defined::mgmt_tools_admin_list (: ("CN="CN=admin,OU= users, O=firewall.domain.com.9td"

)

The command sets the allowed users list in InternalCA.C file:cpca_client set_mgmt_tool on -u "CN=user,OU= users, O=firewall.domain.com.9td:mgmt_tools_user_list (

: ("CN=user,OU= users, O=firewall.domain.com.9td")

5 Open a browser and type the following address:https://<Management Host Name>:18265

Note - To use the Internal CA Management Tool in a clear connection (no SSL), run the following command:

cpca_client set_mgmt_tool on -no_ssl

It places the following line in the InternalCA.C file:

mgmt_tools_no_ssl : (1)

This connects to the Internal CA Management Tool by address:

HTTP://ManagementHostName or IP:18265




Command Line

The cpca_client command automatically configures attributes. No service restart is needed:cpca_client [-d] set_mgmt_tools on|off [-p <ca_port>] [-no_ssl] [-a|-u

"administrator|user DN" -a|-u "administrator|user DN" ... ]

• If the command is executed without -a or -u, it does not change the list of allowed users and Administrators, and simply starts/stops the server with the previous allowed Administrators/users.

• If two start operations are followed, nothing happens unless the SSL mode is changed. In this case, the server is stopped and run again with the new SSL mode.

InternalCA.C File

The file InternalCA.C (located in $FWDIR/conf) can be edited to configure the Web GUI properties. The following attributes should be added::mgmt_tools_web_gui (1) \\ to enable the Web GUI:mgmt_tools_admin_list (

: ("CN=xxxx")... \\ A list of allowed administrators CNs: ("CN=yyyy")

):mgmt_tools_user_list (: ("CN=zzzz") \\ A list of allowed users (user level access):mgmt_tools_no_ssl (1) \\ Use this to disable SSL (on by default).

The Internal CA should be restarted by cpca stop and cpcastart, for these additions to take effect.

Parameter Meaning

on Starts the Internal CA Management Tool (opens the 18265 port)

off Stops the Internal CA Management Tool (closes the 18265 port)

-p Specifies the CA management port; changed by running cpca with the -m option

-no_ssl Configures the server to use clear HTTP, rather than HTTPS

-a “administrator DN” Sets the DNs of the Administrators-u “user DN” Sets the DNs of the users (lower permissions)-d Turns on debugging

142

Administrator Login


Administrator Login

The Security Administrator certificate should be installed in the browser, before entering the site. This is accomplished by creating a user certificate, saving it on the Administrator's computer, and double-clicking the certificate to install it on the browser.

Using the Internal CA Management Tool, an Administrator can manage this database, and users can use the Internal CA in a simple GUI. The Internal CA Management Tool allows Administrators to manage and view the ICA database.

Each certificate issued by the ICA has a defined validity period. When this validity period is over, the certificate becomes expired. An Administrator can revoke a certificate. This can be done for a number of reasons, for instance, when a user leaves the organization. If a certificate is revoked, the serial number of the certificate is published on the CRL, indicating that the certificate has been officially revoked, and cannot be used or recognized by any entity in the system.

Certificates are created in different stages:• SIC certificates• VPN certificates for modules• User certificates

Certificates are created in one step, through SmartDashboard. User certificates can also be created in a two-step process, using either SmartDashboard or the Internal CA Management Tool.

If the user certificate is created in two steps, these steps include:

1 Initialization: A registration code is created for the user. When this is done, the certificate state is pending.

2 Registration: When the user completes the registration process in the remote client (SecuRemote/SecureClient) using the registration code, the certificate becomes valid.




Benefits of the Internal CA Management Tool

Recovery - CA is able to recover corrupted CRL files.

Direct manage - the Administrator/user are able to manage the ICA directly, and see different parts of the database (CRLs and certificates).

Operational - the Administrator/user use bulk operations.

Availability - Administrators/users can use the Internal CA Management Tool from any browser, on any platform.

Configuration - the Administrator can configure the CA while it is running; attributes saved to the $FWDIR/conf/InternalCA.C file on the SmartCenter Server.

Compatibility - an Upgrade of an old CRL mode, including reverse Security - used over an SSL connection. This requires both Administrator and server certificates.

Administrative capabilities are:• Searching for a specific certificate in the database, and add it to a list for later

revocation or removal.• Downloading any certificate to local disk.• Initiating certificates for single or multiple users (batch operation), including

sending mail notifications.• Recreating corrupted CRL files.• Configuring ICA attributes.• Switching between old and new CRL modes.• Downloading any CRL.• Cleaning the CA's database; removing expired from database and CRLs.

144

Batch Operations


Batch Operations

Batch operations include initializing certificates for a list of users, then sending user authorization codes by, by using the Internal CA Management Tool form:FIGURE 14-1 Internal CA Management Tool Form

File format

A file containing DNs should be used. The separator between the DNs should be a blank line, for example:uid=user_1,ou=People,o=intranet,dc=company,[email protected]=user_1givenName=user_1objectClass=topobjectClass=personobjectClass=organizationalPersonobjectClass=inetorgpersonsn=usercn=User OneuserPassword={crypt}xxxx/xxxxxcreatorsName=cn=directory managermodifiersName=cn=directory managercreateTimestamp=20020429143957ZmodifyTimestamp=20020429143957Z<blank_line>…uid=…


Internal CA High Availability


Internal CA High AvailabilityThe SmartCenter Server contains several databases of information about different aspects of the system, such as users, objects and Policy information. This data changes when the System Administrator makes modifications to the system. It is imperative that this data be backed up, so that crucial information is not lost in the event of a SmartCenter Server failure.

If the SmartCenter Server fails, a backup server needs to be in place, to take over the primary server's activities. In the absence of a backup SmartCenter Server, essential operations, such as downloading the CRL to Security Gateways and installing Security Policies cannot occur.

In Management High Availability, a backup SmartCenter Server functions in parallel with a primary SmartCenter Server. Security Gateways can fetch revised CRLs from both the primary and backup servers, since both servers are synchronized.

If the primary server fails, the backup server becomes the primary server. If the backup server functions exactly like the primary server, why is it necessary for it the backup to become the primary server, when the latter is down? The CRL maintained by the ICA can only be updated by an active SmartCenter Server. If the active server is down for an extended period of time, Security Gateways cannot validate certificates.

ICA database files are stored on additional backup servers, as well as on active servers. These SmartCenter Servers are constantly being synchronized, so data is maintained and ready to be used. Backup servers continue to issue CRLs, to ensure valid CRLs, if primary servers fail.

146


CHAPTER 15

SecuRemote/SecureClient

In This Chapter

NAT Traversal for SecureClient page 148Office Mode - IP Assignment from a RADIUS Server for SecureClient page 157Office Mode - DHCP Enhancements for SecureClient page 167Office Mode per site for SecureClient page 170Office Mode per IP Range for SecureClient page 172MSI Package for SecureClient page 176MEP and Interface Resolving Enhancements page 180General Information and Tips page 189

147

NAT Traversal for SecureClient



Overview

Until version R56, SecureClients located behind NAT devices used the UDP Encapsulation mechanism to solve connectivity problems.

The problem

NAT devices use source port modification on packets in order to perform NAT. IPSEC packets do not have a source port, therefore it is impossible for the NAT device to transfer the IPSEC packets to their destination.FIGURE 15-1 NAT Traversal problem

The UDP encapsulation solution

UDP Encapsulation solves the problem by changing the IPSEC packet and adding to it a UDP header that contains a source port. This way, the NAT Device manages to use this port for performing NAT.

148

The NAT Traversal Method


When using UDP Encapsulation SecureClient takes an IPSEC packet and encapsulates it within a UDP packet, using the 2746 port number.FIGURE 15-2 NAT Traversal solution

The UDP Encapsulation solution was written by Check Point. The problem with this solution is that the participating peers (Client/Gateway) are not always aware of the fact that a NAT device is located on the network between the two of them.


NAT Traversal is a method that allows two peers to detect the presence of a NAT during negotiation, and to discover where it is located. In NGX, SecureClient works in NAT Traversal by default.

How does NAT Traversal work on the Client?

Assuming both Client and Gateway support NAT Traversal - when the Client starts an IKE negotiation with the VPN peer Gateway:

In Main Mode:• In MM packet 1 and 2 both peers (Client and Gateway) determine if they support

NAT Traversal:In MM packet 1 - the Client adds a NAT-T vendor ID payload. This vendor ID contains an MD5 hash, which indicates that it supports NAT Traversal. Since NAT Traversal is not a standard yet, it does not have such an MD5, and therefore SecureClient currently uses a temporary MD5 hash.

• In MM packet 2 - the Gateway responds with a similar NAT-T vendor ID.

Chapter 15 SecuRemote/SecureClient 149



• In MM packet 3 and 4 both peers exchange information about their IPs and ports. According to this information they detect whether there is a NAT device present, and its location. The information is sent in NAT-D payloads, which contain a hash of IP and port.In MM packet 3 - The Client sends the peer's (GW) NAT-D payload to the Gateway, which contains the Gateway IP and port hash, followed by the Client's NAT-D payload. The Client simulates the existence of a NAT device (whether it is there or not) by claiming to have a different IP address. Therefore, the NAT-D payload itself always contains a fake hash of its port and IP.

• In MM packet 4 - The Gateway sends a NAT-D payload to the Client, which thinks that its information belongs to the Client (in fact, it is fake information sent by the Client), and then the Gateway NAT-D payload (which contains the Gateway IP and port hash).

The hashes calculated in MM 3 and MM 4 are compared in each peer respectively. If they match it means that there is no NAT between the two peers. Otherwise, it means that there is at least one NAT device that changes the address/port in the way.

Since the Client sends a NAT-D payload which contains a fake hash, there is a difference in the Client's hash. The Gateway thinks that the Client is behind a NAT device (even if it is not).

MM Packets 5 and 6

In case IKE was performed over UDP

In MM packet 5 and 6 the peers change the ports of the packets (destination port: 4500, source port: random port).

In case IKE was performed over TCP

When IKE is configured to be performed over TCP, and NAT-T is supported by both peers (Client and Gateway), SecureClient does not switch the port to 4500 until the connection changed to UDP. This means that in MM packets 5 and 6 the peers do not change the port. SecureClient uses port 4500 only when it starts Quick Mode.

Quick Mode

IKE continues over the new ports

• Quick Mode packet 1 - all proposals contain Nat Traversal. The Encapsulation Mode in the proposals contains VAL_CHKP_NATT_TUNNEL (61443).

• Quick Mode packet 2 - The NAT-T proposal is accepted.

150



After QM completes IPSEC packets are encapsulated in UDP port 4500 header

• The first four SPI bytes of the packet are set to zero in order to distinguish those packets from IPSEC ones.

The IKE source and destination ports are set to 4500.FIGURE 15-3 NAT Traversal Main Mode Flow - Part 1 of 2




FIGURE 15-4 NAT Traversal Main Mode Flow - Part 2 of 2

Working with IKE over TCP

When IKE is configured to be performed over TCP, and NAT-T is supported by both peers (Client and Gateway), SecureClient does not switch the port to 4500 until Main Mode is completed. This means that SecureClient uses port 4500 only when it starts Quick Mode.

152

Connecting to the Gateway


Connecting to the Gateway

In SecureClient NGX there are three ways of connecting to the Gateway:• Legacy - ('Extended' Full mode in R56) The user determines the connectivity

enhancements through which a connection is established to the Site, according to the connections profile.

• Visitor Mode - ('Compact' - simplified mode in R56) The Client connects to the Gateway through TCP Tunneling.

• Standard - (new mode in NGX) In this mode the Client determines automatically the connectivity enhancements through which a connection is established with the Site.

The Standard Mode 'Connect' flow

When working in Standard mode, the Client automatically selects whether to perform the IKE over TCP or UDP, and whether to use UDP Encapsulation/NAT Traversal or none of these methods for IPSEC packets.

When working in Standard mode, and the Client performs connect, the flow is as follows:

1 IKE negotiation starts over TCP port 500.

2 In case the TCP handshake fails, the Client tries starting the IKE negotiation again, this time using UDP port 500.

3 In case IKE was chosen to be performed over TCP or UDP:• MM packet 1 - if the Client connects to a new Gateway (NGX and above) it

adds a NAT-T vendor ID payload.• MM packet 2 - if the Client connects to a new Gateway (NGX and above) that

supports NAT Traversal it responds with a similar vendor ID.

4 In case the Gateway supports NAT-T:• In MM packet 3 - the Client sends both sides of the NAT-D payloads to the

Gateway.• In MM Packet 4 - the Gateway sends both sides of the NAT-D payloads to the

Client.

5 In case IKE was performed over UDP:• In MM packet 5 and 6 the peers change the port of the packets.

6 In case IKE was performed over TCP:• SecureClient does not switch the port to 4500 until Main Mode is completed.

This means that SecureClient uses port 4500 only when it starts Quick Mode.




• Quick Mode proposals offer only NAT-T.• Port 4500 is used through IPSEC as well.

7 In case the Gateway does not support NAT-T: (an old Gateway or a new one that does not support NAT-T):• IKE continues over port 500 (UDP or TCP).• Quick Mode proposals offer both UDP and non-UDP encapsulation transforms.• The IPSEC port remains the way it was. In case UDP encapsulation is chosen,

the packets are encapsulated and the default port remains 2746.FIGURE 15-5 Connecting to the Gateway

154

Verifying the IKE Negotiation


Backward Compatibility

The NGX Client supports NAT Traversal, and continues to support UDP Encapsulation for connecting to Gateway versions prior to NGX.

New Gateway versions support NAT Traversal, and continue to support UDP Encapsulation for client versions prior to NGX.

Important Notes• According to the NAT Traversal RFC, if NAT is detected, the initiator (the Client

in our case) should change the sport and dport of the packet to 4500. Since some NAT devices do not work properly when sport and dport are equal, the Client changes the dport to 4500 and the sport to some random port (same as in UDP encapsulation).

• After an upgrade, existing settings continue to work as before to keep the same behavior, using Legacy mode.

• New installations are configured to Standard mode by default. The user can switch to Legacy mode at any time, as required.

• There is no attempt for Nat-T when updating a site.


MM packet 1 and 2

Using the IKEView utility, you can see the VentorID payloads that the Client and Gateway exchange for notifying their NAT-T support.FIGURE 15-6 IKEView




In the $FWDIR\log\ike.elg itself you can see the vendor's IDs containing the MD5 hash, which indicates that each peer support NAT Traversal.FIGURE 15-7 Vendor ID

MM Packets 3 and 4

You cannot see the NAT-D payloads in IKEView (might be added in the future).

In the ike.elg you can see the Gateway's NAT-D payload in MM packet 3, containing the Gateway IP and port hash, and then the Client's NAT-D payload, containing the Client IP and port hash.FIGURE 15-8 Gateway NAT-D Payload 1

Note - Since NAT Traversal is not a standard yet, it still does not have a standard MD5 hash, and therefore SecureClient currently uses a temporary MD5 hash. A Microsoft hash, as shown in this example, but it might be changed to a local hash written by Check Point.

156



In MM packet 4 you can see the Client's NAT-D payload, containing the Client IP and port hash, and then the Gateway's NAT-D payload containing the Client IP and port hash.FIGURE 15-9 Gateway NAT-D Payload 2

Notice that the Client's NAT-D hash is different in MM3 and MM4, while the Gateway's NAT-D hash is equal.




Main Mode packets 5 and 6

In MM packets 5 and 6 the Client should change the dport to 4500 and the sport to some random port. In IKEView, you can see the changes in the random port: MM packets 1-4 are sent over UDP on port x, and MM packets 5-6 are sent encapsulated with NAT-T on port y.FIGURE 15-10 MM Packets 1-4

FIGURE 15-11 MM Packets 5 and 6

158



IKE negotiation should be performed on the random source port 10460, and destination port 4500. You can use fw monitor on the Gateway to verify that this kind of transportation arrived to this port.FIGURE 15-12 Quick Mode continues

Note - In IKE Over TCP we see that the port number will not be changed in Main Mode packets 5 and 6, but just on the Quick Mode packets.




Quick Mode Packet 1

In Quick Mode packet 1 all the proposals contain Nat Traversal as the encapsulation Mode.FIGURE 15-13 Quick Mode Packet 1

Quick Mode Packet 2

In Quick Mode packet 2 the accepted proposal contains Nat Traversal as the encapsulation Mode.

160

Introduction


Office Mode - IP Assignment from a RADIUS Server for SecureClient

Introduction

Up to version R55, there were three methods to assign OM IP addresses:• OM IP POOLs (manual)• OM DHCP (automatic)• IP-per-user (a manually edited list - ipassignment.conf)

Office Mode required that only one of the IP POOLs and DHCP methods are configured; assignments from IP-per-user took precedence.

In version NGX a different method for assigning OM IP addresses was added: OM from RADIUS Server.

In this method, the OM IPs are given to the Gateway from a RADIUS Server to assign them to the Clients.

Functionality

RADIUS IP assignment takes place during the user authentication to the RADIUS server. This means that the Firewall VPN Gateway gets the OM IP address from the RADIUS Server during authentication to it.

The OM IP address are given to the Gateway even though in this stage the Gateway still does not know whether the Client requested an OM IP address at all, or whether this Client deserved an IP-per-user OM address according to the ipassignment.conf configuration.

Flow

1 The Client connects to the Gateway. During the Connect operation, the RADIUS user authenticates himself to the Gateway.

2 In the Authentication stage the RADIUS Server assign an IP address to the Gateway.

Note - Only RADIUS users are authorized to get an OM address from the RADIUS server; others receive the OM address using other methods.




3 In case the Client asked for an OM IP the config mode starts after the authentication stage is finished:• In case the Client did not ask for an OM IP at all, the Gateway waits one

minute, and then sends a message to the RADIUS Server, notifying that the OM address assigned previously can be released.

• In case the Client asked for an OM address, the Gateway checks if an IP-per-user OM address should be assigned to it according to ipassignment.conf. If an IP-per-user address is assigned to this Client the Gateway waits one minute and then sends a message to the RADIUS Server, notifying that the OM address assigned previously can be released.

• In case the Client asked for an OM address, and it does not deserve an IP-per-user OM address, the Gateway assigns it the IP address previously received from the RADIUS Server. The Gateway sends a message to the RADIUS Server notifying that the OM address previously assigned should be saved.

4 An IP lease time duration is defined for the assigned OM IP.

5 The Client asks to renew this OM address each x time, according to the configured lease time.

6 Disconnect from the Gateway to prevent it from sending any more renewing requests for this OM address. The Gateway notices this and sends a message to the RADIUS Server notifying that it can release this OM address assigned previously.

When the Gateway notifies the RADIUS Server about saving the OM IP address assigned in the authentication stage, the RADIUS Server locks this address and sends a unique String to the Gateway. This String serves the Gateway when it asks the RADIUS Server to release this IP. The RADIUS Server is not able to release this IP without receiving back this String.

A new kernel table is added on the Gateway for saving this unique String information: om_radius. The key of this table is the OM IP that the RADIUS Server assigned the Gateway. The table data is the unique String received from the RADIUS Server.

When the Gateway notices that the Client is not sending any more renewing requests for an OM address, it sends the relevant unique String from the om_radius table to the RADIUS Server, and requests that this IP be released.

Note - The messages sent to the RADIUS server about locking the address are accounting-start and accounting-stop.

162

Functionality


If all addresses are either assigned or lost, the RADIUS server stops authenticating users, and they get a Wrong username or password message.FIGURE 15-14 IP Assignment from RADIUS Server flow

Warning - The om_radius table should reflect the status of the locked IP addresses that the RADIUS Server had assigned the Gateway. If any IP address are locked on the RADIUS Server, and does not appear in the om_radius table, it means that it might be lost forever. For example, the Gateway was restarted, the om_radius table was cleaned, but IPs on the RADIUS Server stayed locked. In such a case the Gateway cannot ask the RADIUS Server to release them since the unique strings for releasing the IPs were lost.

Note - Renewal of OM addresses and time are not reflected in any way to the RADIUS server; it only sees one long session.




GUI Configuration

A GUI option in the NGX Smart Console is used for configuring IP assignment from the RADIUS Server. The option is located in the Gateway object’s RemoteAccess >

Office Mode tab.FIGURE 15-15 RemoteAccess > Office Mode

When the From the RADIUS server used to authenticate the user checkbox is selected, the Gateway uses the RADIUS Server for assigning OM to RADIUS users.

Note - More than one OM method can be checked. For example, an administrator can configure an OM IP assignment from the RADIUS Server method for RADIUS users, and an IP POOL OM method for FW users.

164

GUI Configuration


In addition, the administrator has to configure the RADIUS Server object in the GUI to support IP assignment. This is done through the RADIUS object’s RADIUS Accounting tab.FIGURE 15-16 RADIUS Accounting tab

Checking the Enable IP Pool management checkbox enables this RADIUS server to support OM IP assignment. In addition, the administrator has to choose the port through which IP assignment is done. This is the port through which the RADIUS Server locks and unlocks the allocated IP addresses (each RADIUS Server has a different port).

More GUI changes

In the Gateway object’s RemoteAccess > Office Mode tab > optional parameters dialog:• The IP Pool Optional Parameters (DNS and WINs servers configuration) apply to all

the Office Mode methods, except DHCP and ipassignment.conf entries, which already contain this data.

Note - In case the DHCP or ipassignment.conf entries do not contain this data, the DNS and WINs server’s configuration is taken from here.




FIGURE 15-17 Office Mode tab > Optional Parameters

• The IP lease duration is taken from the IP Pool Optional Parameters dialog. This duration is applied to all the Office Mode methods.

166

GUI Configuration


Office Mode - DHCP Enhancements for SecureClientDHCP is one of the methods Check Point uses in Office Mode to assign IP addresses to Clients. The Gateway requests an IP address on behalf of the Client. Every DHCP packet, whether a request (from the Gateway), or a response (from the DHCP server) contains standard fields, followed by DHCP options. Currently, Check Point supports several DHCP options. Some are present only in requests (like REQUESTED_ADDRESS), some - only in replies (Like SUBNET MASK), and some in both (like LEASE_TIME).

FIGURE 15-18 Office Mode - DHCP Enhancements

There was a growing number of requests for Check Point to support four more standard DHCP options, which appear only in DHCP requests:• #12 - hostname - the name of the client computer (like dev9)• #81 - fqdn - the fqdn of the client computer (like dev9.qa.checkpoint.com)• #60 - vendor class - a string related to the client version (like MSFT 5.0 for

Windows 2000)• #77 - user class - this can be set manually by the user, using the command

ipconfig /setclassid

Note - Unlike other features, this feature applies only to SecureClient.


Office Mode - DHCP Enhancements for SecureClient


Check Point takes these four parameters on the client and sends them to the gateway as part of Office Mode. If the feature is enabled, the Gateway sends this data in the appropriate format to the DHCP server. The potential benefits are as followes:• A properly configured DHCP server can use options #12 and #81 to update a DNS

server. This way, if you connect to Check Point, and someone, either at home or at work, uses a command like ping dev9.checkpoint.com, the ping goes to the specific computer. This can be very useful for IP telephony, where some clients allow typing the destination address.

• Option #77 can be used to let the DHCP server choose among several address pools.

Configuring the Feature

A new attribute was added per Gateway in the objects_5_0.C file. The attribute’s name is: om_extended_dhcp_params.

From an NGX Client, the new DHCP options are always sent to the Gateway when asking for OM.

In case this feature is enabled (om_extended_dhcp_params is set to true), the Gateway adds the new four DHCP options described above to the DHCP request.

In case the feature is disabled, these four options are not added to the DHCP request.

In case the Client has only some of the four options configured (i.e. the user class is not configured), it sends just the available options to the Gateway, and the Gateway manages to send them to the DHCP.

Note - The DHCP request for OM from the Gateway to the DHCP is done over port 67.

168

General Information and Tips



Adding Classid with ipconfigipconfig /setclassid "Local Area Connection" <any string>

For example:ipconfig /setclassid "Local Area Connection" kuku

FIGURE 15-19 Adding classid with ipconfig


Office Mode per site for SecureClient


Office Mode per site for SecureClientAfter the Client connects to the VPN Gateway and receives an OM IP address, every connection to the Gateway's encryption domain goes out with the OM IP as the internal source IP. The connection goes out first via the virtual adapter, and then via the physical adapter.

In fact, the OM IP address is what the encryption domain hosts "see" as the Client's IP address.

Why do we need this feature?

On a secondary connect, when the Client opens a connection to the encryption domain of another Gateway in the Site, while already connected to the first Gateway, the Client uses his physical adapter with the physical IP address. This means that the OM feature is disabled on a secondary connect.

Feature description

Office Mode per site is a recent feature that allows the Client to use the OM address it receives from a Gateway on all the secondary connections to other Gateways in the same site. This means that secondary connect connections go out with the OM IP rather than the Client’s physical IP.

Enabling the feature

An attribute was added to the Global Properties: single_om_per_site. This attribute is downloaded to the Client topology userc.C file under the site managers section.

Via the SmartDashboard you can configure this property. The path is: Global Properties

> Smart Dashboard Customization > Configure button > RemoteAccess properties.

When the attribute single_om_per_site is set to true - the feature is enabled. When the attribute single_om_per_site is set to false - the feature is disabled.

By default, the feature should be disabled.

Note - Since one Gateway does not know how OM IPs were assigned by other Gateways, OM anti-spoofing and the IP-per-user features have no meaning when OM per site is enabled.

170

Enabling the feature


MEP ConfigurationFIGURE 15-20 MEP configuration

OM per site should work with MEP with no additional changes, and it has no effect on MEP configurations. Even if OM per site is enabled, connections via one Gateway should never be associated with an OM address that was assigned by another Gateway.

If you use both Office Mode and MEP, you need to have IP pool NAT on at least one of the gateways, according to the routing inside your network. For example, if you have two gateways, GW-A and GW-B, GW-A provides Office Mode with the pool 10.9.8.x. If any host behind these two gateways sends a packet to this subnet (for example, to address 10.9.8.7) it gets routed to GW-A. If the client sends an Office Mode packet through GW-B, the reply from the host goes through GW-A. This means that stateful inspection cannot work (we call this asymmetric routing). To make this work, you need to set-up IP pool NAT on GW-B, so that replies come back through it.

Routing consideration

When the feature is enabled, the encryption domain behind a Gateway should be able to handle packets with IP addresses that are not from the Gateway pool only. A Gateway might receive packets with internal IPs from other pools. One solution is to reconfigure all the routers and hosts in all on the encryption domains. The other solution is to use IP pool NAT.


Office Mode per IP Range for SecureClient


Office Mode per IP Range for SecureClientThis feature is designed is to allow administrators to configure the possibility to obtain Office Mode IPs according to the SecureClient user's source IPs. This way the administrator can differentiate between access permissions given to different users with different source IPs.

Functionality

In order to configure Office Mode according to each source IP range, the administrator has to define a table called om_per_src_range in the Management’s user.def file (located under $FWDIR\lib directory). The table keys are the ranges of the source IPs (from IP X to IP Y). The table values are the IP ranges assigned to the source IPs as the OM IPs.

The table can be defined per module or for all Site Gateways. It is defined between the #define __user_def__ and #endif signs. Here is an example of this table:• Defining the table for a specific module in the Site:

All@module1 om_per_src_range={<10.10.5.0, 10.10.5.129; 1.1.1.5, 1.1.1.87>,<20.20.5.0, 20.20.5.129; 2.2.2.5, 2.2.2.87> };

• Defining the table for all Gateways in the Site:om_per_src_range = { <70.70.5.0, 70.70.5.129; 7.7.7.5, 7.7.7.87> };

Note - The administrator can still define an IP assignment method that is used for users with source IPs that are not defined in the om_per_src_range table.

172

Flow


Flow

The Client connects to the Gateway with a profile that OM has configured for it in the Config mode stage, requested from the Gateway for an IP.FIGURE 15-21 Office Mode - IKEView

• Upon receiving a Config Mode request for an OM from a Client, the Gateway checks whether the om_per_src_range feature is turned on. In case it is turned on, the Gateway verifies that the Client's source IP is defined in the om_per_src_range table.

• In case the Client's source IP is not defined in the om_per_src_range table, the Gateway proceeds to work in the usual flow of IP Assignment. First it looks for an OM IP to assign in the ipassignment.conf file. If it does not find anything there, it assigns an IP according to the defined method: DHCP/IP POOL etc.


Office Mode per IP Range for SecureClient


• In case the Client's source IP is defined in the om_per_src_range table, the Gateway checks Client requests for a previous OM IP address that were received in the past. In case the Client received an OM IP in the past, it saves the assigned IP for further OM requests.

FIGURE 15-22 Office Mode per IP range flow

174

Turning on the feature


Turning on the feature

The feature is controlled by a flag in the global properties section of the objects_5_0.C file, that calls om_use_ip_per_src_range. A GUI for this flag is not planned for development. The administrator has to configure it via the dbedit application.

om_use_ip_per_src_range valid flag values• Exclusive - if the Client's source IP does not belong to the ranges in the

om_per_src_range table, the Gateway does not give it Office Mode at all.• True - if Client's source IP does not belong to the ranges in the om_per_src_range

table, the Gateway assigns Office Mode IP using other methods, according to the IP assignment priority.

• False - the Gateway does not use the om_per_src_range feature at all.

The default value of the om_use_ip_per_src_range flag is false.

In case the Client requests a previous OM IP, the Gateway checks the following:• Does this address belong to the user that performed the Connect?• During the previous user connection, was this address assigned in the IP per src

method?• According to the om_per_src_range table, is this IP still accessible to the user?


MSI Package for SecureClient


MSI Package for SecureClientSince some of the strategic SecuRemote/SecureClient customers use Windows Installer (a leading installation technology for windows-based applications), it was decided to implement a new installation package for SecureClient in a new MSI (Microsoft Software Installer) format.

What is MSI?

MSI (a.k.a Windows Installer) is a system service for installing and managing applications. It provides a standard method for developing, customizing, and updating applications. All the data required for installation, including product registry keys, different install files, DLLs, etc. are saved in a special database, arranged in tables.

The SecureClient MSI package replaces the SecureClient InstallShield packages. Until MSI will be deemed stable enough, both versions are supported.

Functionality

The MSI package supports the old InstallShield 6 package abilities, and includes new improvements.

Supporting old InstallShield Package Abilities• The user receives a SecureClient package, which consists of a single binary

installation file - *.msi. Double-click the package to install it.The following dialog windows are displayed to the user during the installation process:• Welcome dialog• License agreement• Update/overwrite dialog• Product installation target directory• Installed product type (SecuRemote/SecureClient)• File copy progress• Kernel installation process• Installation progress of additional components• Reboot dialog

• There are two external scripts that can be defined at product.ini::• Post install scripts, such as installing the SCV• Pre uninstall scripts, such as uninstalling the SCV

176

Supporting old InstallShield Package Abilities


The administrator can configure this file and add his own scripts.• The MSI Installation can install the following SecureClient sub-products:

• SecureClient• SecuRemote• Compact View (Simplified Client)

• The MSI Installation offers the following features:• Clean Installation• Upgrade Installation - preserve all configurations• Overwrite - reset configuration; essentially the same as uninstall and reinstall

The MSI Installation can upgrade the following products:

The supported platforms for MSI packages are: W2K, XP, and Win2003.• Entrust and Help separation:

In the InstallShield 6 SecureClient package the installation is divided into three separate sub-packages:• Main install (desktop_xxx.exe) - 7 MB• Entrust package (sc_ent.tgz) - 2.6 MB• Help packages (sc_help.tgz) - 1 MBBecause a major concern is to keep the SecureClient package small, MSI installation has the ability to be divided into smaller packages.

Products Versions Remarks

SecureClient 4.1SecuRemote 4.1

4199 and 4200 SecureClient performs part of the upgrade process (updating userc.c).

SecureClient NGXSecuRemote NGX

NGX, FP1, FP2, FP3, R54, R55

SecureClient R56SecuRemote R56Compact View R56

R56 When upgrading from Compact View, the installation automatically upgrades to Compact View; no user intervention is required.

SecureClient MSISecuRemote MSICompact View MSI

NGX and future versions

Future versions are MSI-based.


MSI Package for SecureClient


• As in the old InstallShield 6 package, creation of the MSI package is controlled according to the following files:• product.ini - affects the interactive dialog windows displayed during

installation (e.g., license agreement, installation path etc.), and has different software capabilities (e.g., enable SDL, Entrust support etc.)

• reg.ini - determines which registry keys are written to the machine's registry during installation.

Recently, the following field was added to the product.ini file regarding installation:• SplitKernelInstall - determines whether to install drivers after reboot or not.

There are two methods to change the installation language:• Using the packaging tool, modify the MSI package (change the

InstallationLanguage attribute in the product.ini, and pack the MSI again).• Run the Language Pack MSI that let the user choose the installation language and

run the regular MSI with the chosen language.

Improvements in the MSI Package• Until SecureClient version NG administrators were able to take a *.tgz

SecureClient package and customized it according to their needs. This was done by extracting the tgz file, making changes to it, and then wrapping it again in a tgz file (using a compression utility e.g., WinZip).Since the SecureClient MSI package contains only one *.msi binary file, and no tgz file is planned to be added, a new utility was developed, which allows administrators to customize packages according to their needs.The utility extracts the MSI package, allows the administrator to make changes (add files, change the product.ini configuration file, etc.), and then rewraps the package to create a *.msi file.

• MSI Installation is developed in Unicode. This means that all the strings and dialogs can be modified to seven different languages.

• SPLIT Installation: Companies that use Windows Installer technology occasionally also use Enterprise Software Distribution (ESD) software, which is a software solution for distributing software on client machines. Usually, there is a central Server which distributes software packages to its clients (e.g., Microsoft SMS, NetInstall, etc.)MSI installation can delay the installation of Firewall kernel components until the machine is rebooted. This is important for costumers who use ESD software, since the Firewall installation causes the machine to be disconnected from the network, and fails the installation from the ESD agent's viewpoint.

178

Improvements in the MSI Package


The SPLIT installation is configured via the product.ini file, and is performed as followed:

1 First, the SecureClient is installed without the Firewall kernel (the files and registry are installed). The user is asked to reboot the machine.

2 After the first reboot, the SecureClient installation continues. This time, Firewall kernel components are installed. Then, the machine reboots automatically.

3 After the second reboot, SecureClient is ready to be used.

Packaging Tool

The Packaging Tool was upgraded to support the following types of SecureClient packages:• InstallShield 6.1-based packages• MSI packages: The Packaging Tool can modify the *.msi installation by:

1 Opening the *.msi package.

2 Changing product.ini and userc.C according to Packaging Tool definitions.

3 Packing the modified package contents into an *.msi file.


MEP and Interface Resolving Enhancements



Interface Resolving Enhancements

Until version R56, the Client used different methods to resolve a suitable interface of a VPN Gateway, through which the VPN tunnel is established. The Link Selection feature provides enhancements to the SecureClient’s interface-resolving mechanism.

In NGX, there are five methods of Link Selection supported for Remote Access:• Using Main IP for VPN - forcing the Secure Client to connect to the VPN

Gateway’s Main IP. All VPN traffic is sent from the Client to the Gateway's Main IP.

• Using a single IP for VPN - forcing the Secure Client to connect to a specific VPN Gateway IP. All VPN traffic is sent from the Client to the Gateway's Single IP, as configured on the Gateway object.

• Topology Calculation - Secure Client resolves the IP through which it connects to the VPN Gateway according to Topology calculations (previously known as the static interface resolving method).

• One time probing - The Client resolves the Gateway’s destination IP through which it connects by using the RDP mechanism to probe all possible destination IPs, and choosing the first interface to respond. This method is performed only during the first time a connection is opened to the Gateway (previously known as the dynamic interface resolving method).

• On going probing - The Client resolves the Gateway’s destination IP through which it connects by using the RDP mechanism to probe all possible destination IPs, and choosing the first interface to respond. In this method, the selected interface is kept, and the Client works with it until it stops responding to the RDPs. RDP probing is activated once the first connection is opened to Gateway, and keeps working in the background (previously known as the dynamic interface resolving HA method).

Resolving Methods

Link Selection configuration is done via the GUI. In the objects_5_0.C file, a property was added to the Gateway Object - ip_resolution_mechanism. This attribute contains the selected IP resolution mechanism (as described above), which should be used by connecting clients and Gateways.

Optional values for this attribute are: mainIpVpn, singleIpVpn, topologyCalc, oneTimeProb, ongoingProb, dnsLookup, and none.

180

Resolving Methods


Default values are: mainIpVpn for none-DAIP Gateways, and none for DAIP Gateways.

Main IP

ip_resolution_mechanism - receives the mainIpVpn value.

When this method is configured, Secure Client connects to the VPN Gateway via its Main IP. After connecting, all VPN traffic to the encryption domain is sent through the Main IP interface.FIGURE 15-23 Main IP interface

When the Main IP method is configured, SecureClient topology (userc.C) includes the following VPN Gateway attributes:

:allowed_interface_ranges (: (<main_IP>

:allowed_range (: (

:type (machines_range):ipaddr_first (0.0.0.0):ipaddr_last (255.255.255.255)

)):is_ext (true):is_natted (false)

)):resolve_interface_ranges (true)




Single IP VPN

ip_resolution_mechanism - receives the singleIpVpn value.

This method facilitates using a fixed IP address as the resolved interface, rather than the main Gateway IP.

When this method is configured, Secure Client connects to the VPN Gateway via a Specific IP configured by the administrator. After connecting, all VPN traffic to the encryption domain is sent through this specific interface.

The administrator can configure the Single IP for the VPN Gateway in the GUI, under the Gateway properties.

In the objects_5_0.C file, the single_VPN_IP attribute was added under the VPN Gateway object. This attribute contains the Single IP that the administrator configures in the GUI.• Possible values for this attribute are any IP address.• Default value: none

When the Single IP method is configured, SecureClient topology (userc.C) includes the following VPN Gateway attributes:

:allowed_interface_ranges (: (<vpn_single_IP>

:allowed_range (: (

:type (machines_range):ipaddr_first (0.0.0.0):ipaddr_last (255.255.255.255)

)):is_ext (true):is_natted (false)

)):resolve_interface_ranges (true)

<vpn_single_IP> is the Single IP, defined in the Management’s single_VPN_IP property for the VPN Gateway object.

In addition, the Single IP is added to the ifaddrs set. This is relevant in case the configured Single IP is not one of the Gateway's interfaces (under the Topology tab).

182

Resolving Methods


Topology Calculation

ip_resolution_mechanism - receives the topologyCalc value.

When this method is configured, Secure Client connects to the VPN Gateway via the interface that is resolved according to topology calculation (previously known as the static interface resolving method).

The definitions in userc.C are identical to the static interface-resolving mechanism definitions. The topology includes the matching allowed_interface_ranges set for the VPN Gateway (according to the Gateway's topology configured in the GUI - external interface, internal interface, etc.) and the resolve_interface_ranges property is set to true.

Probing (RDPs Mechanism)

ip_resolution_mechanism - receives the OneTimeProb / ongoingProb value

When the probing mechanism is configured, the Client resolves the Gateway’s destination IP through which it connects by using the RDP mechanism to probe all possible destination IPs, and choosing the first interface to respond.

When the probing mechanism is used, the Client starts sending RDP packets to the Gateway's interfaces upon a Connect event.

When oneTimeProb is configured, RDP probing is performed only upon a connect event to the Gateway. This method is identical to the Dynamic Interface Resolving method.

The resolving mechanism definitions of the VPN Gateway in userc.C are identical to the dynamic interface resolving mechanism definitions. SecureClient topology includes the resolve_multiple_interfaces VPN Gateway property, set to true.

When ongoingProb is configured, RDP probing is activated upon a connect event to the Gateway, and keeps working in the background (Dynamic Interface Resolving HA).

The resolving mechanism definitions of the VPN Gateway in userc.C are identical to the dynamic interface HA resolving mechanism definitions. SecureClient topology includes the following properties for the VPN Gateway; the properties are set to true: resolve_multiple_interfaces and interface_resolving_ha.




Manually Defined VPN List

Until version R55, RDP packets were sent to all the interfaces defined in the Gateway’s Topology tab: ???then what???FIGURE 15-24 Gateway Topology tab

In some cases, this list is not exact because RDPs should not be sent to all Gateway interfaces. For example, there is no need to send RDPs that are not routable to the Gateway’s internal interfaces.

In version NGX, it is possible to configure a list of interfaces to which the RDPs are sent. This list is configured from the GUI per Gateway object.

In case the administrator configures such a list, the following attribute is added under the VPN Gateway object in the objects_5_0.C file: available_VPN_IP_list.

184



This attribute includes a list of IP interfaces (configured in the GUI by the administrator) that belong to the VPN Gateway to which the Client sends the RDP packets.• Possible values for this attribute are any valid IP string.• Default Value: none.

The administrator can configure according to which interface list the Client chooses to send RDPs: either the interface list defined in the Gateway’s Topology tab, or the manually defined list.

This behavior is determined by the GUI. In the objects_5_0.C file, the following attribute was added under the Gateway's object: use_interface_IP. This attribute specifies whether the Client should probe the interfaces defined in the Topology Gateway IP list, or in the manual VPN IP list. If true, the manually defined VPN IP list is ignored, and the interfaces IP list is used instead (in the Gateway’s Topology tab).

If the value of use_interface_IP property on the objects_5_0.C is set to false, the configured VPN IP list is downloaded to the Client (userc.C), under the available_VPN_IP_list set.

In addition, all configured IP addresses are added to the ifaddrs set of the VPN Gateway object.

Primary Interface

Version NGX introduces an option to configure a Primary interface for a VPN Gateway. The Client first tries to connect the Gateway via this Interface. In case this interface is down the Client tries connecting the Gateway via other interfaces.

The administrator manages to configure the Primary interface for the VPN Gateway in the GUI, under the Gateway's properties.

In the objects_5_0.C file the following attribute was added under the VPN Gateway object: interface_resolving_ha_primary_if. This attribute defines the IP address that was given higher priority by clients.• Possible values for this attribute are any valid IP string.• Default Value: none

If a primary interface was configured, the interface_resolving_ha_primary_if property is downloaded into the Client topology. The property includes the configured Primary Interface IP address.




Link Selection GUI Configuration

Link Selection configuration is done per Gateway. A tab called Link Selection resides within the Gateway object properties Topology tab.FIGURE 15-25 Link Selection tree node

The Link Selection tab is displayed when selecting the corresponding node.FIGURE 15-26 Link Selection tab

186



Under the VPN Link Selection section in this window the administrator can configure the suitable Link Selection method.FIGURE 15-27 Link Selection method configuration




MEP Enhancements

In version NGX, MEP configuration and behavior is similar to version R55 (preferred MEP, Fargo, and Primary/Backup MEP). The Disabling MEP enhancement was added. In case the Client works with a MEP configuration, and this property is turned on, the client connects to the Gateway defined in the Connection Profile > Gateway field without considering the MEP configuration (MEP RDP probing and failover are not performed).

In case the Gateway (defined in the Connection Profile > Gateway field) is down, all connections to the MEP encryption domain fail. This enhancement is configured globally per site.

An attribute was added to the Site's properties: desktop_disable_MEP. This property is downloaded to the Client's topology, under the managers section (in userc.C).• Turn the feature on by setting desktop_disable_MEP is set to true.• Turn the feature on by setting desktop_disable_MEP is set to false.

Preferred Backup Gateway Attribute

The preferred backup feature was introduced in version NGX. This feature allows the administrator to configure a backup Gateway from all the MEP Gateways to the one defined in Connection Profile > Gateway field.

When this feature is turned on, the Primary Gateway to which the Client connects is the one defined in the Connection Profile > Gateway field. The backup Gateway is configured in the Connection Profile, and calls a preferred backup Gateway.

When the Client connects to the Site it sends RDPs only to the Primary Gateway and to its backup. All other Gateways in the MEP are ignored. In case the Primary Gateway is down, the Client tries connecting to its backup. In case the Primary and backup gateways are down, connections to the encryption domain fail, and there is no attempt to connect to other Gateways in the MEP configuration.

Previous to version NGX, the preferred backup Gateway was configured in the Connection Profile. The administrator had to manually add the preferred_backup_gateway attribute with the backup Gateway to the Connection Profile set in userc.C.

In version NGX, the backup Gateway is configured through the GUI using centrally managed profiles. The preferred_backup_gateway property is downloaded to the client in topology.

188

Kernel Tables



Kernel Tables

The kernel tables (specified below) are the same as in the NGX Client.

resolved_interface table

The Client selects the interface through which it connects to the Gateway. It then inserts this interface to the resolved_interface kernel table.

crypt_resolver_db table

The Gateway's interface status is kept in this table• 1 - live interface• 2 - dead interface

MEP_chosen_gw table

In the the MEP_chosen_gw table’s third row the Gateway that the Client selects to connect should be indicated, according to the MEP configuration.

Link Selection and Visitor Mode

Working with Link Selection and Visitor Mode• If the Allocated IP Address is configured to a specific IP (Management > GW Object >

Remote Access tab > Visitor Mode Configuration section > Visitor Mode Settings per

Gateway), the client chooses to connect to the Gateway via this interface. This is the resolved interface regardless of the configured Link Selection method.

• If the Allocated IP Address is configured to All IPs (in Visitor Mode Settings per

Gateway), the Client first checks which resolving mechanism is configured for the Gateway.• If the configured resolving mechanism is Topology Calculation, the resolved

interface is selected according to the userc.C network topology.

Note - In case this IP is not routable, the Client fails to connect to the Site.




• If the configured resolving mechanism is Probing mechanism, the Client selects the Gateway’s Main IP as the resolved interface (Dynamic Interface Resolving is not supported in Visitor mode).

• If Main IP / Single IP is configured, the Client connects to the Gateway according to this IP.

Note - If this IP is not routable - the Client fails to connect to the Site.

190


Section 4:Additional Products


CHAPTER 17

SNX

In This Chapter

Application Mode

In This Section

Application Mode page 193Network Mode page 199

Basic Hooking page 194Debug Logs - Client page 196StaProxy & Sta logs page 197Debug Log - Server page 197Proxy Configuration page 197Connectivity Issues page 198

193

Application Mode


Basic Hooking

In SNX Application Mode, routing is done per application by means of a hooking mechanism. There is no encryption domain, and once the application is hooked, the entire traffic is encrypted and routed to the Gateway. Therefore, the basic troubleshooting directive is to check whether or not the application was hooked and the traffic routed. The window frame is the basic indicator of a hooked application. However, the window frame does not work for console applications and can also be disabled.

Process Explorer (a SysInternals tool) can be used to see whether the application was launched through SNX. Verify that it was launched with rundll32.dll, and that Sta.dll is loaded.FIGURE 17-1 Process Explorer

194

Basic Hooking


More importantly, verify that the traffic is indeed encrypted and going through the StaProxy. Use any TCP monitor tool to view the actual connections used by the application, and to verify that all connections are made locally to the StaProxy, which then opens an SSL encrypted tunnel for each connection. Check this with TcpView (another tool from SysInternals).FIGURE 17-2 TcpView

In case of a problematic application, use this tool (or a similar one) to identify the application's behavior.

In some rare cases, the framing mechanism might cause some issues, like high CPU usage by specific applications. The framing can be manually disabled by adding the file ColorConf.txt to %TEMP%\SNXAC when the first line is 0 (disable).

The file format is:• 0/1 - Disable/Enable• 0-255 - Red• 0-255 - Green• 0-255 - Blue

Note - SNX Application Mode does not support UDP traffic.

Chapter 17 SNX 195

Application Mode


Debug Logs - Client

There are several logs for the client side:

CShell

The CShell log is in the Java Console available by the JVM.

SNX can be used by Microsoft JVM or by other vendors (SUN, IBM etc.)

To view the java console when using MSJVM, check Java console enabled (requires

restart) at the Internet Options Advanced tab, and restart IE. Switching between the different JVMs (in case you have two or more) is done through the same tab.FIGURE 17-3 Internet Options - Advanced Tab

Viewing the java console when using Microsoft JVM in IE:• Select View > Java console in IE.

Viewing the java console when using other JVMs:• When using IE, select Tools > Java Console.

In most JVMs an icon appears at the tray. Right-click it and select the appropriate command to view the java console.

In this log, you can review all the initialization stages, including SNX configuration and version verification, proxy configuration detection, and StaProxy launch. After these stages, you can examine the CShell communications with StaProxy.

196

StaProxy & Sta logs


StaProxy & Sta logs

The StaProxy and Sta logs both depend on an Environment variable:• TDERROR_ALL_ALL = 5

Add the variable in Control Panel -> System -> Advanced tab -> Environment Variables.

Both logs are accumulated at:• %APPDATA%\Check Point\SNX Application Mode

(e.g. %APPDATA% - C:\Documents and Settings\<user>\Application Data)

Debug Log - Server

Regarding the server side, the vpnd log is located in $FWDIR/log/vpnd.elg.

The relevant debug topics are: proxy, rasta, rasta_protocol and slim.• vpn debug trunc

• vpn debug on [DEBUG_TOPIC=5](e.g. vpn debug on rasta=5)

In addition, the Connectra web traffic log can be used on the server side.

Proxy Configuration

When the use of a proxy for the client machine is mandatory, SNX needs proxy definitions in order to open the SSL connections to the Gateway through the proxy. The CShell can detect the proxy settings in the browser so the StaProxy uses it to connect to the Gateway. In the Java console, we can see this detection. The proxy can also be manually configured through %APPDATA%\Check Point\CShell\proxy.ini.

File format:• IP or Host Name• Port• Optional: user• Optional: password

Chapter 17 SNX 197

Application Mode


Connectivity Issues

Connectivity problems can be traced with TCP dump on both the client and server sides. All of the logs described in this section can be helpful at the relevant sides.

The Gateway connection is created on the first attempt of any launched application to connect to the network. The Gateway verification pop-up is displayed only during the first connection. The accepted Gateways are saved to the registry so that on the next run there is no pop-up.

Registry path: HKEY_CURRENT_USER\Software\CheckPoint\SSL Network Extender\accepted_cn. The pop-up means there is a connection with the Gateway and all traffic is now directed to the Gateway. Therefore, connectivity issues should probably be checked on the Gateway.

Connectivity problems on the Gateway can be related to a proxy configuration. View the proxy detected by CShell on the java console. If there is a proxy configured, it should be disabled in the browser to enable web browsing through SNX. Either use a proxy configuration file and disable the proxy settings in the browser, or leave the settings until the CShell detects and disables them in order to browse the web.

Connectivity problems to hosts behind Connectra can be greatly related to the Connectra configuration. Check the configuration of network applications, servers, services, and user groups.

198

Troubleshooting procedures


Network Mode


The following points might be useful for investigating SNX Network Mode issues on Windows with VPN-1 Pro R55/NGX and Connectra 2.0/NGX.• On the problematic client machine, verify that the service Routing and Remote

Access is disabled. This service is usually active on Windows 2000/2003 server machines.

• If you have another successfully connected client, you can view the encryption domain by opening a command prompt and typing route print. The encryption domain includes everything routed to the server through the virtual network adapter (VNA) installed by SNX. For example:

FIGURE 17-4 Route print

• View the routing table on the server by opening a console and typing: ip route or netstat -rn.

• SSL traffic can be captured on the client by using ethereal, and on the server by using tcpdump.

• fw monitor does not work for most traffic on Connectra versions prior to NGX (in NGX it does). This is because all traffic except Office Mode traffic is routed to bypass the Firewall module. It should only be used to inspect decrypted SNX traffic - not even the SSL connection's traffic. To use fw monitor, type the following at the command prompt:

fw monitor -e "src=XXX or dst=XXX or dport=XXX and sport=XXX, accept;" -o output_file.o

• On the server, type fw ctl debug drop at the command prompt to check if SNX traffic is being dropped by the Firewall. If SNX traffic vanishes without a message there is a routing problem. The exception is with packets to the client being "dropped" by the firewall with the message vpnk_tcpt need to be tunneled, which means that the packets have been forwarded to the TCP/IP stack.

Chapter 17 SNX 199

Network Mode


• Check if you can find the issue in following troubleshooting table:

TABLE 17-1 SNX Network Mode - Troubleshooting Table

Issue Resolution

All user's packets destined directly to the external SSL Network Extender Gateway are not encrypted by the SSL Network Extender.

If there is a need to explicitly connect to the Gateway through the SSL tunnel, connect to the internal interface, which is part of the encryption domain.

The SSL Network Extender Gateway allows users to authenticate themselves via certificates. Therefore, when connecting to the SSL Network Extender Gateway, the following message might appear: The Web site you want

to view requests identification.

Select the certificate to use when

connecting.

There are two ways to avoid this message:• On the client computer, access Internet Explorer. Under

Tools > Options > Security tab, select Local intranet > Sites. You can now add the SSL Network Extender Gateway to the Local intranet zone, where the Client Authentication pop up does not appear. Click Advanced, and add the Gateway's external IP or DNS name to the existing list.

• On the client computer, access Internet Explorer. Under Tools > Options > Security tab, select Internet Zone > Custom

Level. In the Miscellaneous section, select Enable for the item. Do not prompt for client certificate selection when no certificates or only one certificate exists. Click OK. Click Yes on the Confirmation window. Click OK again.

This solution changes the behavior of the Internet Explorer for all Internet sites, so if better granularity is required, refer to the previous solution.

200



The SSL Network Extender does not function properly when the following conditions are met:

• The client computer has SecuRemote/ SecureClient software installed

• SecuRemote/SecureClient is configured to work in Transparent mode

• The SecuRemote/ SecureClient encryption domain contains SSL Network Extender Gateway

• The SecuRemote/ SecureClient encryption domain otherwise overlaps with the SSL Network Extender encryption domain

To resolve this, disable the overlapping site in SecuRemote/SecureClient.


Issue Resolution

Chapter 17 SNX 201

Network Mode


• Other possibilities are to activate debugging on either client or server, and examine the relevant log files.

The SSL Network Extender does not function properly when the following conditions are met:

• The client computer has SecuRemote/ SecureClient software installed

• SecuRemote/SecureClient is configured to work in Connect mode

• The SecuRemote/ SecureClient encryption domain contains SSL Network Extender Gateway

• The SecuRemote/ SecureClient encryption domain otherwise overlaps with the SSL Network Extender encryption domain

To resolve this, verify that the flag allow_clear_traffic_while_disconnected is set to true (the default value).

SSL Network Extender connections cannot pass SCV rules. SecureClient users must be differentiated from SNX users in order to allow the SecureClient connections to pass the SCV rules.

One way to do this is to use the SCV capabilities in the rule base. In Traditional Mode you can configure two types of rules, by selecting Apply Rule Only if Desktop Configuration

Options are verified.The selected SCV rules pass SecureClient connections only, while the rules that were not selected pass SecureClient and SSL Network Extender connections.When using Simplified Mode, the administrator can specify services that are excluded from SCV checking.Both SecureClient and SSL Network Extender clients attempting to access such services are allowed access, even when SCV in not verified. SCV is not enforced on specified services for both client types.


Issue Resolution

202



Server sidevpn debug trunc

vpn debug on slim=5

Debug can be found at $FWDIR/log/vpnd.elg

Client side

For the service

Type regedit at the command prompt and set the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpextender\parameters\dbg_level to 5net stop cpextender

net start cpextender (or kill slimsvc.exe)

Debug can be found at:%Program Files%\CheckPoint\SSL Network Extender\slimsvc.log

For ActiveX (Only when using ActiveX with IE)

Type regedit at the command prompt and set the following:

set HKEY_CURRENT_USER\Software\CheckPoint\SSL Network Extender\parameters\ dbg_level to 5

Debug can be found at %APPDATA%\Check Point\extender\activex.log

Chapter 17 SNX 203

Network Mode


For the Applet (When using the Applet version)

SNX can be used by Microsoft JVM or by other vendors (SUN, IBM etc.)

To view the java console when using MSJVM, select Java console enabled (requires

restart) at the Internet Options Advanced tab, and restart IE. You can also switch between the different JVMs (in case you have two or more) through the same tab.FIGURE 17-5 Java Console in Internet Options

Viewing the java console when using Microsoft JVM in IE

Click View > Java Console in IE.

Viewing the java console when using other JVMs

When using IE, Click Tools > Java Console.

In most JVMs, an icon appears at the tray. You can right-click it and select the appropriate command to view the java console.

204


CHAPTER 18

InterSpect

In This Chapter

Introduction page 206Latest features page 207Memory Management Troubleshooting page 209Kernel Debugging page 210Fail Open NICs page 212Performance and Acceleration page 214Policy Troubleshooting page 219Cooperative Enforcement page 221Known Issues page 223

205

Introduction


IntroductionInterSpect is an internal security gateway that blocks the spread of worms and attacks inside the network and provides network zone segmentation. InterSpect prevents the spread of attacks that originate internally, thus complementing SmartDefense and Web Intelligence on a VPN-1 Pro Gateway that operates at perimeter of the organization, and prevents attacks originating in the Internet.

InterSpect supports three modes of operation: Bridge, Switch and Router:• Bridge mode is used to divide the internal network into protected zones. In this

mode, InterSpect is invisible to the IP network, which means that IP Packets appear to have been sent from the originating clients, even though they are forwarded by InterSpect. Each zone is wired to one InterSpect interface, and is bridged to the backbone through another interface.In addition, Bridge mode facilitates adding Application Intelligence to a traditional, network security firewall at the network boundary, by connecting in-line with the firewall.

• Switch mode allows InterSpect to be used as an Application Security box that replaces a switch. InterSpect acts as a multi-port Bridge, in which all interfaces are Bridged together to make one zone. Switch mode is the default mode, and allows out-of-the-box operation. No zones need to be configured, and no other configuration is required.

• Router mode allows InterSpect to be used as an Application Security box that routes IP datagrams between subnets. In this case, every active interface is configured with an IP address.

206


Latest features• Network Zone Profiles:

• SmartDefense and Web Intelligence profile per Zone, adding granular security control for different areas of the network.

• A profile can be used for one or more zones.• Application Intelligence Security:

• MS-SQL protocol-specific commands enforcements and filter access to specific MSSQL tables

• Ability to block specific UNIX RPC programs• DCE-RPC protocol inspection• Control Citrix ICA application protection• Enhanced DNS protocol security enforcement• SMTP protection including SMTP worm catcher, malicious code protector and

SMTP format restrictions• TFTP protocol security enforcement• MSN Messenger granular application filtering

• Web Intelligence Security:• New HTTP protocol security including new Malicious Code protector

protection scopes.• Sends an HTML error page to external URL.• For more information on Web Intelligence features refer to Chapter 6, “Web

Intelligence” on page 51.• Security Enforcement Capabilities:

• New auditing tools including capture of offending packets• Packet capture available for all protections can be viewed in SmartView

Tracker• New quarantine capabilities including manual quarantine by MAC or IP

address• MAC address logging for all records• Quarantine by Switch using SNMP V2

• Centralized Management updates:• Sends logs and alerts to SmartCenter/Provider-1• Download and install updates on all managed devices• InterSpect is SmartUpdate-enabled using SmartCenter R61 and above

Chapter 18 InterSpect 207

Latest features


• New Network Configuration Options including:• NIC Teaming - 802.3ad support (Active-Passive only)• A new infrastructure that enables Interspect to send packets to a zone without

the need for an IP address on the bridge• Support of standard Layer two protocols:

• Spanning Tree Protocol - active and passive support• Rapid Spanning Tree - Passive support• Nortel Split Multi Link Trunking - Passive support• Cisco Inter Switch Link - Passive Support• Cisco VLAN Trunking Protocol - Passive support• MPLS over Ethernet - Passive support• CoS, ToS and 802.1p - Passive support

• Performance enhancements:• Syn defender acceleration - Passive• Web Intelligence acceleration• Net Quota acceleration• P2P performance improvements• Inspect performance improvements• Passive TCP Streaming acceleration

• Incorporated into the fw tab:• Chunk iteration (hash tables): supports fetching the entire table information in

chunks• Avoids memory allocation failures when trying to fetch large kernel tables in a

single operation• Offline analysis of captured packets:

Provides forensic analysis information for captured attacks that are attached to the logs and can be viewed in the SmartView Tracker

• New Global "Monitor Only" mode that can be enabled per security profile• Unified recovery CD - One CD that fits all Interspect appliances

Note - It is critical for InterSpect to be able to inspect the complete traffic stream in order to apply the security policy. Network redundancy protocols that enable traffic balancing between switches might not integrate well with stateful security device such as InterSpect.

208

fw ctl pstat utility


Memory Management Troubleshooting

fw ctl pstat utility

All Interspect kernel memory allocations go through Kernel memory (kmem), which chooses to use either System Kernel memory (smem) or kmem. These statistics are shown using the fw ctl pstat command line utility.

This tool outputs many statistics, such as memory, Connections, and more.

The command output is complex and includes many fields. The description is not always intuitive, for example:#fw ctl pstatHash kernel memory (hmem) statistics:Total memory allocated: 10485760 bytes in 2558 4KB blocks using 2 poolsInitial memory allocated: 6291456 bytes (Hash memory extended by 4194304

bytes)Memory allocation limit: 42991616 bytes using 10 poolsTotal memory bytes used: 135328 unused: 10350432 (98.71%) peak: 160616Total memory blocks used: 55 unused: 2503 (97%) peak: 63Allocations: 12663 alloc, 0 failed alloc, 10145 free

hmem failures mean that the hmem is full. This is not a real memory problem, but indicates a configuration problem. If low hmem limit was configured, it leads to improper usage of the OS memory.System kernel memory (smem) statistics:Total memory bytes used: 16101136 peak: 16115540Blocking memory bytes used: 153552 peak: 167956Non-Blocking memory bytes used: 15947584 peak: 15947584

Allocations: 501 alloc, 0 failed alloc, 285 free, 0 failed free

Possible reasons for smem failures are: smem reached its limit, exhausted the OS memory or large non-sleep allocations. This can indicate some memory shortage.Kernel memory (kmem) statistics:Total memory bytes used: 5740020 peak: 7287680

Allocations: 111424 alloc, 0 failed alloc, 108689 free, 0 failed free

kmem failed allocations means that some applications did not get memory. This is usually an indication for a memory problem. The most common memory problem is memory shortage. Memory shortage sometimes indicates a memory leak. In order to troubleshoot memory shortage, stop the load on the intespect and let connections close. In case memory consumption went back to normal, you are not dealing with a memory leak. Such shortage might happen when traffic volumes are too high for the device capacity. If the memory shortage happens after a change in the system or the environment, undo the change, and check whether kmem memory consumption goes down.


Kernel Debugging


Unified Memory Allocation Accounting

InterSpect NGX introduces a unified kernel memory management for Performance Pack and FW Kernel. It uses one pool for the memory allocations.

You can see these statistics using the fw ctl pstat with the -k flag:Kernel memory (kmem) statistics:

Total memory bytes used: 5740020 peak: 7287680Allocations: 111424 alloc, 0 failed alloc, 108689 free, 0 failed free

External Allocations: 0 for packets, 0 for SXLMemory used for internal structures: 10940 bytesTotal number of items: 2735

External Allocations• packets - packets held by the Interspect kernel, and allocated by the OS• SecureXL - Allocations made for the performance pack

Kernel DebuggingThe kernel debug produces detailed information of the actions done by the different kernel modules. Useful kernel debugging options for Interspect are:• Useful & Informative Debug Topics:

• vm:• Provides debug information of traffic going through fw_filter_chain

processing and connection context information in readable format. This is a very useful debug topic to troubleshoot connectivity issues.

• Relatively low verbosity• drop:

• Provide a debug message for each packet dropped during kernel processing• Low verbosity

• SmartDefense:• Network Security:

• Port scanning issues: portscan• SynDefender: synatk• Packet Validation (Packet Sanity, Max Ping Size, Small PMTU, Sequence

Verifier): packval• Application Intelligence:

• Mail: mail, smtp• Citrix: citrix• TFTP: tftp

210



• DNS: domain• MS-SQL: sql• Micorsoft Networks | CIFS (File and Print Sharing, NULL CIFS Session,

Popup message, Long CIFS password): cifs• MSN over MSNMS (message type, application ID, opening and closing

connections, and additional information parsed from the packets): sip msnms• Other:

• Logging: dynlog, log• Dynamic List/ SAM: sam• Quarantine: quarantine

• Streaming• tcpstr (Passive Straeming)• Debugging Module CPAS (Active Streaming):

fw ctl debug -m CPAS + error warning tcp http

• spii (INSPECT Streaming)• Various Packet Processing:

• packet

• chain

• Policy Installation:• filter• install• asm

• Memory:• memory

• Zone Policy:• bridge sam

• Web Intelligence - refer to “Debugging and monitoring” on page 56.

A kernel debug example:#fw ctl debug 0

#fw ctl debug -buf 8150

#fw ctl debug -m fw tcpstr cifs drop

#fw ctl kdebug -f >& filename.ctl &

To reset all kernel debug values, run:# fw ctl debug 0


Fail Open NICs


An example of troubleshooting sending mail:

A client computer from the internal LAN is not successful in sending a mail message through the mail server that is connected on a different zone. You find a drop log on SmartView Tracker on the packet originated from the client.

You can run the following debug:#fw ctl debug 0

#fw ctl debug -buf 8150

#fw ctl debug -m fw mail drop log

#fw ctl kdebug -f >& filename.ctl &

After recreating the issue, make sure you stop the debug:# fw ctl debug 0

On the debug output, look for the client machine IP. The drop log writes the IP address on a normal IP format. There are cases when you need to convert the IP value to hexadecimal format.

Fail Open NICsInterSpect NGX supports the 802.3ad static link aggregation standard. An 802.3ad trunk groups two or more physical NICs into a single logical network device called a bond.

In InterSpect, these logical bonds are implemented by means of NIC teaming. Once a NIC team is configured, InterSpect is not aware of the underlying physical NICs.

NIC teams can operate in Active-Backup mode. This mode ensures that one (and only one) of the NICs in the NIC team transmits at any given moment. This mode is useful for implementing high availability solutions using two hubs.

To view the status of the fail open NICs, and to enable or disable fail open, use:# failopen

Usagefailopen [on|off|status]

For example:# failopen status

eth2> Slave: eth3; Bypass: off; Watchdog: on; Time till bypass: 1280

Troubleshooting example

212



A possible Fail Open NIC issue is when the watchdog is not started after rebooting InterSpect. This can be caused by the F/O driver not loading for some reason, or the F/O not configured correctly using the failopen on command. Interspect starts, but traffic does not pass through it. To verify this is the issue, run:# failopen status

eth2> Slave: eth3; Bypass: off; Watchdog: off; Time till bypass: 12800

You can see that the Watchdog is off.[Expert@IS74]# cpd_sched_config printTask: "RotateLogs"

Command: /sbin/cp_logrotateArguments:Interval: 100Active: trueRunAtStart: true

Task: "BypassWD" Command: /bin/failopen bypass_wd_refreshArguments:Interval: 8Active: trueRunAtStart: true

Task: "Sim_Affinity" Command: simArguments: affinity -cInterval: 60Active: trueRunAtStart: false

Note - The watch dog pings the failopen NICs every eight seconds. This leaves a four-second response time with software related failures. On the hardware level, the response time is instant.


Performance and Acceleration


Performance and AccelerationPerformance is measured in several aspects:• Packet Rate - How many packets InterSpect can forward per second• Throughput - How many bits per second InterSpect can forward

• TCP Session Rate - how many connections can be established and tear down per second

Acceleration achieves better performance by:• Improving packet rate and throughput• Improving session rate

• with the aid of templates• connection created and expired by SecureXL with minimizing the overhead of

notifications

SecureXL is enabled by default. To enable and disable the acceleration use the command:• fwaccel on

• fwaccel off

In order for the configuration to be consistent across system restarts, configure it via cpconfig.

Acceleration Basic Functionality• The first SYN packet is forwarded to the InterSpect kernel, since it does not exist

in the Acceleration connection table.Subsequent packets of the connection are accelerated, assuming that the security profile and protections that should be applied to the connections supports acceleration.If a connection matches an existing template, the whole connection is accelerated (including the SYN packet).

• SecureXL updates InterSpect kernel with all connection information, including changes in TCP states.As a result, the connection table is always updated with the exact status of each connection found in the SecureXL.

• The Acceleration device expires TCP connections by notifying InterSpect kernel to expire them.

Note - The value of throughput is a combination of packet rate and packet size. It is important when approaching technical services to clearly specify the measurements units.

214

Acceleration Basic Functionality


To display acceleration statistics, use fwaccel stats, for example:

# fwaccel stats:

To display the acceleration status:# fwaccel statAccelerator Status: onTemplates: enabledAccelerator Features: Accounting, NAT, Cryptography, Routing,

HasClock, Templates, Synchronous, IdleDetection,Sequencing, TcpStateDetect, AutoExpire,DelayedNotif, TcpStateDetectV2, CPLS, WireMode

Name Value Name Value

conns created 823585 conns deleted 325745

temporary conns 801365 templates 26584

nat conns 235 accel packets 658521365

accel bytes 4215685421 F2F packets 17196

ESP enc pkts 0 ESP enc err 0

ESP dec pkts 0 ESP dec err 0

ESP other err 0 espudp enc pkts 0

espudp enc err 0 espudp dec pkts 0

espudp dec err 0 espudp other err 0

AH enc pkts 0 AH enc err 0

AH dec pkts 0 AH dec err 0

AH other err 0 memory used 0

free memory 0 acct update interval 30

current total conns 256 TCP violations 0

conns from templates 765239 TCP conns 196

delayed TCP conns 9 non TCP conns 190

delayed nonTCP conns 0 F2F conns 0

F2F bytes 1074122 crypt conns 0

enc bytes 0 dec bytes 0

pattern match 0 dropped pkts 0

Note - When there is a low percent of accelerated traffic (accel packets/F2F packets), it calls for analyzing the security policy and the traffic mix. For more details regarding the features that might disable templates for certain services, refer to the SmartDefence Guide.

On the same notion, when there is a low percentage of connection creation from templates. this might indicate a session rate performance issue.



f


The fwaccel stat command output:• Shows whether acceleration is enabled or disabled• Shows templates status (enabled, disabled, disabled starting rule #N)• Shows supported features

To display SecureXL templates:# fwaccel templates

Total number of templates: 1

This output:• Shows templates existing in the SecureXL device.• Shows the template key, flags, last create time, delay value and interfaces.• Flags are the same as fwaccel conns. You should not see F, N, C.• LCT - How many seconds ago a connection was created by the template.• DLY - The Delayed Synchronization value for the template.

Debugging SecureXL

The Fwaccel dbg command:• Debug SecureXL API• Debug Output to regular FW-1 debugging buffer

Example:#fwaccel dbg -m api + verbose add

Important flags• init: SecureXL enable/disable• offload: connection offloading code• upd: connection updates• del/Acct: expiration/deletion code• conf: device configuration (for example, interfaces)• template: template handling• API module: displays API calls to the device:

• verbose: print parameter values; goes together with other flags• add/Del/Upd: add/delete/update connection

Source SPort Destination DPort PR Flags LCT DLY C2S i/f S2C i/

10.10.10.1 * 20.20.20.2 23 6 ..... 3 60 eth1 /eth2

eth2 /eth1

216

Performance Pack


• err module: displays critical errors; run fwaccel dbg -m err all

Performance Pack

Checking the Performance Pack version:# sim ver -k

This is Check Point Performance Pack InterSpect NGX (R60) - Build 349

Kernel: NGX (R60) - Build 349

Checking Performance Pack status:# cat /proc/ppk/confActive : yesForward Packets : yesInstalled Inbound : yes Attached in inbound directionInstalled Outbound : yes Attached in inbound directionRandom Initialized : yes Crypto random bufferVlan Support : yesBridge hook used : yes

Flags : 0x00000816 Configuration flagsAccounting Update Interval : 30Conn Refresh Interval : 512SA Sync Notification Interval : 0UDP Encapsulation Port : 0TCP Auto-Expire Timeout : 20Connection Limit : 599800TmplQuota Enabled : 0TmplQuota Quota (rate) : 512TmplQuota Drop Dduration : 300TmplQuota Monitor only : 0TmplQuota Dropped pkts : 0

Total Number of conns : 2 CountersNumber of F2F conns : 2Number of Crypt conns : 0Number of TCP conns : 1Number of Non-TCP conns : 1Number of Delayed TCP conns : 0Number of Delayed Non-TCP conns: 0




Debugging Performance Pack

The Sim dbg command:• Debug Acceleration Device - in case of Performance Pack.• Debug Output to /var/log/messages file or to dmsg

Example:# sim dbg -m mgr + add

Important Flags• pkt pkt: packet handling• pkt f2f: reason for forwarding a packet to the firewall• pkt tcpstate: TCP state handling• err module: displays critical errors. Run fwaccel dbg -m err all

Passive Streaming Library (PSL)

PSL is the infrastructure, which transparently listens to TCP traffic as network packets, and rebuilds the TCP stream out of these packets. Passive streaming can listen to all TCP traffic, but process only the data packets, which belongs to a previously registered connection.

PSL is built on the same infrastructure as the former passive streaming technology (fwtcpstr), and is on by default. In order to verify that PSL is working on InterSpect, run fw ctl get int psl_acceleration_mode and check that the returned value is 0.

sim affinity

On an Interspect with more then one CPU, the performance pack can divide the processes between them.

To list the configuration for sim affinity run sim affinity -l for example:#sim affinity -l

eth0 (irq 20) : All

eth1 (irq 21) : All

eth2 (irq 16) : All

eth3 (irq 17) : All

br0 (irq 0) : All

218

Bridge Policy


Policy Troubleshooting

Bridge Policy

When InterSpect is configured in Bridge mode, there is no IP configured on it, so it uses a different concept for rule matching. Traffic is allowed or not according to the zone it's heading to/from, and according to its direction.

Available actions:• inspect - (same as accept) the packet goes through the Inspect code, and might

be dropped by service handlers or other protections.• block - same as drop• bypass - accept without going through inspect code• quarantine - quarantine the client; send HTML page and redirect

A connection can go through more than one zone, and then the rule match is different for each zone. This contradicts the 'connection' concept, where the fate of the connection is decided on the first packet. When not in the first zone, the packet is no longer considered a 'first packet'.

To Debug bridge configuration run on cmd line

# brctl show (mgmt nic should be part of the bridge)

Note - Avoid setting InterSpect through sysconfig. Use the GUI as much as you can.


Policy Troubleshooting


Dynamic List Policy

Interspect NGX uses SAM V2 for managing the dynamic policy. The main modification from the SAM V1 version is that the sam_uid table was added, and it allows better management of SAM rules.

SAM policy is unique, since it offers filtering capabilities for both Layer 2 and Layer 3:• Layer 2 - src MAC, dst MAC, src and dst MAC addresses• Layer 3 - src IP, dst IP, and dst port and their combinations

SAM offers the following action options:

Bypass, Notify (log only), Inspect, Quarantine, Inhibit Reject, and Inhibit Drop

It offers the following tracking options:

no log, log, and log + alert

SAM allows closure of currently open connections.

Controlling SAM Rules

Users can control SAM rules using the command line or GUI. From a command line, rules can be added using the fw samp command, for example:#fw samp add -a b -l r ip -s 10.0.0.2

This performs bypass on any traffic coming from host 10.0.0.2, and logs it.

In InterSpect's GUI, SAM rules are found in the Dynamic List view, in SmartDashboard.

After configuring the new rule(s), choose Activate Dynamic List to activate the new SAM policy.

Dynamic Rules take precedence over the rule base.

SAM runs only on the first packet, while the zone rule match runs on every packet.

The SAM action has to be remembered and taken into account for the following zones.

Debugging Dynamic List

You can view the SAM V2 table with the command:fw tab -t sam_requests_v2 -u -f

To run the dynamic link policy in kernel, run:fw ctl debug -m fw vm machine sam bridge drop

220

Troubleshooting SIC


Cooperative EnforcementThe Cooperative Enforcement Technology allows administrators to enforce network security by implementing uniform network access criteria on employee PC's in the internal network. Consequently, it ensures that only users with up-to-date endpoint security policies and agents can connect to enterprise networks, while denying network access to non-compliant users.

InterSpect cooperates with an Integrity server that sets the policy to be followed by Clients, and checks that the client is compliant with the Integrity Server policy.

InterSpect denies access to hosts for any of the following reasons:• No Integrity Client is installed or running - unless the host has been explicitly

allowed• The Integrity Client is not compliant with the Integrity Server policy (min-version,

anti-virus, enforcement)• The Integrity Client has a malfunction which prevents it receiving updates or

sending its status

For the components to communicate, a certificate is created on InterSpect and pushed to the Integrity Server. At the Integrity Server, the certificate is pulled over from InterSpect.

Then Secure Internal Communication (SIC) is initialized between InterSpect and the Integrity Server.

Troubleshooting SIC

If while SIC was established, InterSpect entity in the Integrity Server was either edited, or deleted, or the Integrity Server was uninstalled - the old InterSpect certificate on the Integrity Server must be deleted before SIC can be reestablished. Complete the following procedure:

1 In the Integrity Server Web UI, go to System Configuration > Certificate.

2 In the list of Integrity certificates, locate InterSpect certificate by its DN.

3 Delete the InterSpect certificate.

4 Manually delete the temporary file <InterSpect_IP_address>.p12 (that is, the file with the .p12 extension and the name that is the same as InterSpect IP address) from C:\Program Files\CheckPoint\Integrity\engine\temp.You might need to stop the Integrity services before you can delete the file.


Cooperative Enforcement


Troubleshooting• When the process is up and running you can type:

# fw debug igwd on TDERROR_IGWD_ALL=3# fw debug igwd on IG_COMM_MODE=3

output is found in $FWDIR/log/igwd.elgNote that you sent the command to a specific process, and if the process restarts you must repeat the commands in order to debug.

• If there is a firewall between InterSpect and Integrity, ensure that a connection can be established between them by creating firewall rules that allow:• TCP port 5054 (for traffic between Integrity Server and IS)• TCP port 18210 (for the SIC connection)

• Relevant Kernel Debug topic:• vm sam integrity quarantine drop

• Important Kernel table:• integrity_clients_status

This is a kernel table that holds the Integrity Server authorization status of clients. Every entry contains two values:• Host IP address• 0 - if this host is authorized; 1 - if this host in not authorized

222

Troubleshooting SIC


Known IssuesEnabling SecurePlatform user-mode core dumps

Core-dump information can be vital for troubleshooting a severe operating-system problem. For a description of how to enable a core dump on InterSpect, see sk30911.

https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?id=sk30911

Forcing network interfaces on SecurePlatform NG to full/half duplex or 10/100/1000 Mbps using 'ethtool'

Network interfaces on SecurePlatform are configured to auto-negotiate link speed and duplex settings with the device they are physically connected to. If an interface is unable to auto-negotiate with the device, it is necessary to hard-code the settings. For details, see sk25886.

In a central management configuration, the connection between Interspect and the Integrity Server disconnects and reconnects repetitively

Reason: The interspect module tries to fetch CRL for the integrity certificate.

The address from which the CRL should be fetched is derived from the FQDN which is given to the management station Internal CA. Since the interspect cannot resolve the FQDN, it cannot fetch the CRL.

Solutions:

1 Add the fqdn resolving into the etc/hosts on the interspect box.The FQDN can be found by viewing the ICA certificate in the SDB, or by running cpconfig (on the mgmt station) and choosing the Certificate authority option.

2 A less favorable option is to set the IG_COMM_MODE environment variable to 3, which causes the connection to the Integrity Server to be established without requiring CRL verification. This solution requires cpstop and cpstart operations, but can be set prior to the initial cpstart during boot.

SmartDefense updates to InterSpect NGX R60 are failing

The cause is a problem in the SmartDefense update mechanism that causes InterSpect to block any SmartDefense update.

For a solution, see sk31471.

https://secureknowledge.checkpoint.com/SecureKnowledge/login.do?OriginalAction=solution&id=sk31471


https://secureknowledge.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?id=sk30911



Known Issues


Bypass action in InterSpect's dynamic list does not work with some defenses

The symptom is that when setting an entire network in bypass list and activating MS_SQL Monitor protocol protection, packets are dropped even though they arrive from the bypass network.

For a solution, see sk31588.


Splat Tools

Identifying which physical port is connected with a network device:ethtool -p eth2 30

This command starts blinking the LEDs next to eth2 for 30 seconds.

From man ethtool:ethtool -p ethX [N]

Initiates adapter-specific action intended to enable an operator to easily identify the adapter by sight. Typically, this involves blinking one or more LEDs on the specific ethernet port.

N: Length of time to perform phys-id (in seconds)

Tcpdump: available for all NICS# tcpdump -i eth0

# tcpdump -i br0

224



CHAPTER 19

Connectra

In This Chapter

Debug Information page 226Using the TraceLogger page 229

225

Debug Information


Debug InformationTo access the debug output files:

1 Type: >echo “admin” > /etc/scpusers.

2 Use either pscp or WinSCP to connect your desktop to Connectra using administrator credentials.

3 Copy the relevant debug output files to your desktop. The CVPN log directory should be in the following format: /opt/CPcvpn-R55D/log/.

In This Section

Debugging the CVPND Process

To activate cvpnd debug output enter: >cvpnd_admin debug and set:

TDERROR_ALL_SUBJECT=level.• This command immediately affects the currently running cvpnd process.• The debug settings are reset during each cvpnrestart.• Individual debug subjects cannot be turned off.• The debug output appears in: $CVPNDIR/log/cvpnd.elg.

To cancel the debug output, run: >cvpnd_admin debug off.

Debugging the CVPND Process page 226Apache debugging processes page 227Debugging the Portal page 228Debugging File Shares page 228

226

Apache debugging processes


Apache debugging processes

Activating httpd debug output

1 Edit: $CVPNDIR/conf/httpd.conf.

2 Change the first line (beginning with LogLevel) from emerg to one of the following:• error for errors only• warn for warnings and errors only• info for all debug output• debug - this command is just like info, except that it includes coverage info.

3 Type cvpnrestart to restart Apache with the new debug settings.

The debug output appears in $CVPNDIR/log/httpd.log.

Canceling httpd debug output

1 Change the line described in step 2 above back to emerg.

2 Type: >cvpnrestart.

Activating packet dumps in the Apache debug output file

1 Set the debug level described in step 2 above to debug.

2 Type: >setenv LOGHEXDUMP 1.

3 Type: >cprestart.

Disabling packet dumps

1 Type: >unsetenv LOGHEXDUMP.

2 Type: >cprestart.

Note - Make sure not to type cvpnrestart.

Note - Make sure not to type cvpnrestart.

Chapter 19 Connectra 227

Debug Information


Debugging the Portal

Debugging the server’s PHP code

1 Backup and edit the: $CVPNDIR/conf/php.ini file:• In the error_reporting line, leave only E_ALL.• Change the display_errors line to On.


Debugging the client-side’s JavaScript code

Execute one of the following instructions:• In Internet Explorer, set the Tools > Options > Advanced > display a notification about

every script error option.• Use Mozilla’s JavaScript console.

Debugging File Shares

First, determine which implementation is active: CIFS (latest client) or SMB (previous client). In case CIFS is active, revert the implementation to SMB by completing the following procedure.

Reverting the implementation to SMB

1 Backup the original soft link >mv $CVPNDIR/bin/Mount $CVPNDIR/bin/MountLast.

2 Make a new link pointing to the SMB implementation >ln -s $CVPNDIR/bin/MountSmb $CVPNDIR/bin/Mount.


Note - Make sure not to type cprestart.

228

Debugging Web Intelligence


Using the TraceLoggerThe TraceLogger provides a textual traffic dump for inbound and outbound Web application traffic, both to external and internal networks. It does not show traffic to the portal itself or to the administration GUI.

Activating the TraceLogger

1 Edit: $CVPNDIR/conf/httpd.conf

2 Remove the comments from the lines beginning with:• LoadModule trace_logger

and• CvpnTraceLogMaxByte


The debug output appears in the $CVPNDIR/log/trace_log/ directory.

Disabling the TraceLogger

1 Change the line described in step 2 above, back to a comment.


Debugging Web Intelligence

Activating Web Intelligence debug output

1 Edit: $CVPNDIR/conf/httpd.conf.

2 Copy the line beginning with: #CvpnWsDebugSubjects.

3 Uncomment one of the copies, and remove all irrelevant debug subjects.


The debug output appears in $CVPNDIR/log/mod_ws.log, and in $CVPNDIR/log/mod_ws_boa.log.

Disabling Web Intelligence debug output

1 Change the line described in step 3 above back to a comment.


Chapter 19 Connectra 229

Using the TraceLogger


Additional debug subjects

The following subjects are available, but are not included in the commented line:• pfinder (for the pattern finder)• body (for debugging the body of HTTP requests)• analyzer (for debugging MCP analyzers)• spider (for debugging MCP spiders)

230


CHAPTER 20

Eventia Reporter

In This Chapter

IntroductionThe Check Point Eventia Reporter delivers a comprehensive solution for monitoring and auditing traffic in a Firewalled network. It can be used to generate fully detailed or summarized reports for all connections intercepted and logged by the Firewall module and other Check Point products. Reports can be used to track and analyze traffic between the enterprise network and the Internet, as well as transactions within the enterprise.

Introduction page 231Eventia Reporter Architecture page 232Licensing Eventia Reporter page 234Debugging Eventia Reporter page 235Known Limitations page 243Common Questions/Issues page 244

231

Eventia Reporter Architecture


Eventia Reporter ArchitectureThis section explains the structure of Eventia Reporter and its two basic implementations. More information can be found in the Check Point Eventia Reporter Guide.

Eventia Reporter consists of two basic processes: Log consolidation and Data retrieval.

In This Section

Log Consolidation

Reports are based on log data from Check Point and OPSEC. The sources of these logs are Log Servers defined in the Check Point SmartCenter. A user-defined Consolidation Policy specifies terms and parameters for loading log data into the Reporting Database, which maintains the data for report generation.

The Consolidation Policy allows consolidation terms for multiple log entries to be defined and combined into meaningful connection records.

Data Retrieval

Predefined reports specify which database fields are to be retrieved from the Reporting Database in order to generate reports, and the filters by which the reports can be customized. The reports can be distributed in different formats to a variety of targets.

Eventia Reporter Client Components

Eventia Reporter includes two GUI Clients:• Reporter Log Consolidation Policy Editor: resides within the SmartDashboard

GUI and used to define the Log Consolidation Policy.• Eventia Reporter GUI client: used to manage reports. Consolidator and database

management controls can be found in this GUI.

Log Consolidation page 232Data Retrieval page 232Eventia Reporter Client Components page 232Eventia Reporter Server Components page 233

Warning - Express reports retrieve data from the SmartView Monitor history. These reports are generally less flexible than log-based reports. In order to enable this feature, SmartView Monitor must be enabled on participating Firewall modules.

232

Eventia Reporter Server Components


The definitions set in these clients are downloaded to the Reporting Server. The Reporting Server then uploads Log data and generates reports based on parameters defined on the Reporter Client.

Eventia Reporter Server Components

The Eventia Reporter server consists of the following components:• Server Management Program• Log Consolidator Engine• Reporting Database• Reporter Generator

Log Consolidation Engine

The Log Consolidation Engine implements the Consolidation Policy, which is defined using the Log Consolidation Policy Editor. The engine also collects multiple log entries from the specified Log Server and integrates them into detailed connection records. Specified details from these consolidated logs are then stored in the Reporter Database. The engine can run in several instances simultaneously for different Log Servers.

Reporter Database

The Log Consolidation Engine populates the Reporter Database with consolidated logs. The Reporter Database maintains these connection records, which are later retrieved by the Reporter Server.

Reporter Generator

The Reporter Generator creates reports according to the report criteria, format, and distribution parameters, defined through the Eventia Reporter client. The Reporter Generator retrieves selected connection details from the Reporter Database, or from AMON history via SmartCenter, and uses them to generate the required report and send the results (in the requested format) to the specified targets.

Chapter 20 Eventia Reporter 233

Licensing Eventia Reporter


Licensing Eventia ReporterLicenses are installed on the SmartCenter/MDS Server on a per-Gateway basis and a per-CMA basis. Gateways and CMAs are selected in the Reporter GUI, if necessary. When the license is installed on a per-Gateway basis, the user must match Gateways and reports. With Provider-1, select customers instead of Gateways. For example, if you have three Gateways and you buy three licenses, you do not need to select the Gateways because the system “knows” that you only have three. However, if you have four Gateways and three licenses you have to choose the Gateways to which each license belongs.

Up to four VPN Edge devices are considered a single Gateway. Beyond five - each VPN Edge Gateway is counted as an individual Gateway.

While the license is added on the management server, the machines that participate in licensing are selected using the Reporter GUI Client. The machines are not selected by selecting the checkmark for the SmartDashboard object in a host typical to other Check Point products.

For Management HA, if the Eventia reporter's license is on one of the SmartCenters, you can make changes in the Eventia Reporter GUI only if the licensed management is active. If the licensed management is inactive, Eventia Reporter continues working, but no change can be made through the Eventia Reporter GUI. However, if both managements have a license, this limitation does not exist.

Obtain licenses from the User Center. The licenses required by Eventia Reporter depend on the configuration.

The license for the Reporting Module should contain:• CPMP-EVR-5-NGX - 1 Eventia Reporter Server for a single SmartCenter,

5 devices; version: NGX• CPMP-EVR-25-NGX - 1 Eventia Reporter Server for multiple SmartCenters,

25 devices; 5 SmartCenters/CMAs; version: NGX• CPMP-EVR-50-NGX - 1 Eventia Reporter Server for multiple SmartCenters,

50 devices 10 SmartCenters/CMAs; version: NGX• CPMP-EVR-100-NGX - 1 Eventia Reporter Server for multiple SmartCenters,

100 devices 25 SmartCenters/CMAs; version: NGX

Note - Additional licenses should be purchased according to the number of cluster members.

234

Introduction


Debugging Eventia Reporter

In This Section

Introduction

To solve Eventia Reporter problems, your Support representative needs all the relevant information about the problem and its environment. For each type of problem, the Support representative asks for specific records and files.

Sending this information as soon as the support call is opened makes the handling of the ticket more efficient, and ensures that the problem is resolved as quickly as possible. The files can also be of use when employing your own troubleshooting.

This section lists the information that Check Point Support asks you to gather for each type of problem. Send files to [email protected].

Log Consolidator

The consolidator can run multiple sessions. A session consists of the reading logs from a single Log Server. Each session is a separate process and is differentiated from other sessions by the server's IP address. The log file for the session is also kept in a separate directory: $RTDIR/log_consolidator_engine/IPAddress/lc_rt.log• The consolidator supports tderror and generates the error messages in lc_rt.log.• If there is a crash on Windows, the consolidator might present a cryptic error

message: Log Consolidator terminated because of exception (unknown type).When this happens, it is useful to run the consolidator after setting the Registry key ConvertMsvcStructuredExceptions to true.

Introduction page 235Log Consolidator page 235SVRServer page 237My SQL page 237Log Consolidator Commands page 238SVRServer Commands page 240DBTableStat page 241GeneratorApp page 241


mailto:[email protected]



The following commands perform the necessary changes in the registry key:

To set the registry key to on:cpprod_util CPPROD_SetValue "Reporting Module" "ConvertMsvcStructuredExceptions" 1 true 1

To set the registry key to off:cpprod_util CPPROD_SetValue "Reporting Module" "ConvertMsvcStructuredExceptions" 1 false 1

• Database problems affect the Log Consolidator. Check the database error log as well.

• A consolidation session can be executed manually in two scenarios:• On a specific log file, execute a consolidation session from a command line.

Once the sessions ends, the process aborts.log_consolidator -R -s ServerIP -x Yes -t Specified_Log -l xyz.log -a Begin_of_Log-c Full_Level

-R = run the consolidator-s ServerIP = IP address of the Log Server-x Yes = exit after stopping-t Specified_Log = read the specific file-l xyz.log = the specific file to be read is $FWDIR/log/xyz.log-a Begin_of_Log = start from the beginning of the file (as opposed to newly created logs at the end of fw.log or from a saved point in the file (marker)).-c Full_Level = high debugging level (Debug_Level is the highest level of debugging (every field of every log is printed))

• For debugging, run the current session in a command line:

1 Open the command prompt in $RTDIR/log_consolidator_engine/bin to specify the full path for the executable: $RTDIR/log_consolidator_engine/bin/log_consolidator

This is done because the log_consolidator is not in the path.

2 Stop the current session: rmdstop –lc

Note - Besides Full_Level, which is the highest debug level, the following settings can be applied:

-c No_Log is 0

-c Partial_Level is 1

-c Debug_Level is 3 (Thisyields the most common items)

-c High_Level is 4

-c Max_Level is 5. This gives all the information, but should be run only for short period of time since it gives a lot of data.

236

SVRServer


3 Run: log_consolidator –R –s ServerIP [–g customer] [-c Debug_Level]

SVRServer• The SVRServer is the program that controls the Reporter environment. If there are

problems with connectivity to the management server or the GUI, it is noted when the server starts up. These errors are logged in the file: $RTDIR/log/SVRServer.log.

• Additional debug information is generated using TDERROR.

My SQL• The database's error log is located in: $RTDIR/Database/data/database.err.

Sometimes a problem in the system occurs due to a database problem, and this file should be checked.

• The database's configuration file is located in $RTDIR/Database/conf, and is named my.cnf (Unix) or my.ini (Windows). It consists of a set of name=value lines or set-variable name = value for numeric values.

• Configuration update is performed by using the UpdateMySQLConfig command (documented in the User Guide).

• The log directory: $RTDIR/Database/log contains database journal logs to recover after a crash. If the database's configuration has changed, these files might need to be deleted; otherwise, the database does not run. UpdateMySQLConfig deletes these files automatically.

Note - Generator errors are also added to the same log file.




Log Consolidator Commands

To get more information regarding the Log Consolidator, run the following commands from command line.

To show the Log Consolidator Engine version and build number

Usage

log_consolidator -V

To send commands to the Log Consolidator Engine

Usage

log_consolidator -C -m [ start | stop | terminate | exit] -s LogServerIP [-g PV1Customer] [-r Port]

-C send a command to the to the Log Consolidator session as specified by LogServerIP and PV1Customer.

-m command; can be one of the following commands:• start - resume a stopped Log Consolidator Engine session with the last

configuration.• stop - shutdown a started Log Consolidator Engine session and write all

pending information to the database.• terminate - force the Log Consolidator Engine to terminate the consolidation

immediately and discard pending information.• exit - close the main Log Consolidator Engine process and discard pending

information.

-s the IP address of the Log Server to read logs from.

-g (optional) the name of the Provider-1 customer for which the current session is running.

Note - All the following commands can be also retrieved from Eventia Reporter.

238

Log Consolidator Commands


To Get log file information from the Log Server

Usage

log_consolidator -L -s LogServerIP [-g PV1Customer] [-r log_consolidator Port]

The results are written to $RTDIR/conf/<session>/logs_info.conf.

To run the Log Consolidator Engine on an external file from the command line

Usage

log_consolidator -R -e Yes -s <Log_Server_IP> -x Yes -o No -t Specified_Log -l <File_Name.log> -a Begin_of_Log -b <TABLE_NAME>

-R Run the Log Consolidator Engine process for a specific consolidation session.

-s The log Server IP address for reading logs.

-g (optional) The name of the Provider-1 customer for which this session is running.

<Log_Server_IP> - The IP address of the Log Server to read logs from.

<File_Name.log> - Name of log file.

<TABLE_NAME> - name of database table in which log file information is stored.

log_consolidator is located in the directory $RTDIR/log_consolidator/bin.

To get a consolidation session's status information

Usage

log_consolidator -M -s LogServerIP [-g PV1Customer] [-r log_consolidator Port]

Note - This command might help troubleshooting when there are problems with connectivity to the Log Server.

Note - Invoke this command only for external files - files that are not listed in .logtrack anymore.

Note - since log_consolidator supports only one open session per log server, before running the script you must stop and remove an active consolidation session from the list (Management > Consolidation > Sessions page).




To check if a consolidation session's process is currently running

Usage

log_consolidator -X -s LogServerIP [-g PV1Customer]

You can also use the following command to see the status of all running processes:cpwd_admin list

SVRServer Commands

To run the server

rmdstop –server: stops the server and the current SVRServer runs in debug. This is the only way to see the Generator’s tderrors.

To show the Log SVRServer version and build number

Usage

SVRServer ver

To start the Log Consolidator engine

Usage

SVRServer start [log_consolidator]

To kill the Log Consolidator or the Database

Usage

SVRServer kill [log_consolidator | database]

To terminate a specific Log Consolidator session

Usage

SVRServer term_session [log consolidation session ID]

To Start/Stop Eventia Reporter processes

Usage

rmdstart/rmdstop [-lc] [-server]

-lc = start/stop the Log Consolidator

-server = start/stop the Reporter Server

The Database is started when one of the reporter processes begins, and shuts down after all reporter processes terminate.

240

DBTableStat


DBTableStat

Description

This utility provides a daily summary of the number of log records that match the consolidation rules, and the number of consolidated records that were stored in the specified database table. The format of the output is a comma-separated value. The execution time of this utility depends on the amount of records in the Eventia Reporter table.

Usage

DBTableStat [-t TableName] [-o OutputFile]

Syntax

-t specify database table name, default: CONNECTIONS

-o specify output file name, default: table_stat.csv

GeneratorApp

Description

This command generates a report for Eventia Reporter. Both command line parameters are required.GeneratorApp [Directory/""] {ReportID}

Syntax

Directory - The result directory (that is, the location at which the result is placed).

ReportID - The Report ID required for command line generations. The Report ID must be enclosed within curly braces {}. For a list of all Report IDs see Appendix B "Predefined Reports" in the Eventia Reporter User Guide.

Example

Use "" for automatic directory computation. In such a case, the directory should be as follows:<Result location>/<Report Name>/<Generation Date and Time>




svr_webupload_config

Description

This utility is used to configure the Eventia Reporter web upload script. For the complete upload procedure and additional information refer to the section "How to upload reports to a web server" in the Eventia Reporter User Guide.

Usage

svr_webupload_config [-i perl_int_loc]

[-p rep_dir_root]

Syntax

-i specifies the Perl interpreter location

-p specifies the path for the reports virtual directory

242

GeneratorApp


Known Limitations• Management HA:

• The add-on should be installed on both SmartCenters.• Eventia Reporter should be installed on a third machine.• SIC should be made to the active SmartCenter server. After the first connection

is established, Eventia Reporter caches the relevant management information, and therefore can connect to the secondary SmartCenter server once it becomes active.

• The Eventia Reporter GUI must be connected to the active SmartCenter server. If a failover occurs, the Eventia Reporter GUI disconnects (and then the user can reconnect to the active SmartCenter server), the Eventia Reporter Server is disconnected, but immediately connects to the active one.

• Eventia Reporter GUI operations cause the non-active SmartCenter server to appear as lagging, and require a manual sync at the SmartDashboard GUI. Note that generation and automatic server operations, like scheduled generations and automatic maintenance, do not cause the non-active SmartCenter server to appear as lagging. Rather, all status history operations appear only in the SmartCenter server that was active during that phase. This is because there is no sync for the history table.

• Provider-1 limitations:• The administrator cannot configure a consolidation policy, but uses the

out-of-the-box consolidation policy only.• In this setup you cannot add IP for origin filtering.• The configuration of Provider-1 and Eventia Reporter is intended for a limited

number of CMAs, which fits enterprise solution and not MSP. It is important to either disable DNS, or limit the number of threads, and enable the internal DNS feature.

• The command rmdstop does not stop the processes immediately, although the prompt returns immediately. It can take about 1-2 minutes, especially for consolidation sessions, until the processes finally stop. This can be problematic before uninstall and before applying a hotfix.To avoid problems, you can run rmdstop and check in the cpwd_admin list whether the svr and lc_* processes have stopped.There were some cases where while uninstalling Eventia Reporter from Windows, a file would be locked. In case you skip this, RTDIR is not removed.

• Export/import limitations: a clean database cannot be imported since there are dictionary tables that are not exported.


Common Questions/Issues


Common Questions/IssuesIssue:

The Log Consolidator stops and the following message is displayed in the log:Database space check failed. There might not be enough disk space, or failed to obtain database capacity information.

Answer:• In Eventia Reporter’s Database Maintenance properties, there is a Database capacity

line, that reads Z% (X.X GB out of Y.Y GB).• The size of the Database capacity is defined in the mysql configuration file.• The default size is 40 GB, but if the available space on the device is less, it affects

the maximum database size reported (since the database cannot really grow to 40 GB).

• You can modify this value by using the UpdateMySQLConfig tool. This tool is documented in the Administrator Guide.

Issue:

The meaning of the following error message in the SVRServer.log file:Database operation failed, Error: Failed to delete records from table CON_SV_DB2, Error: DELETE FROM CON_SV_DB2 WHERE START_DATE<='2005-2-18'The table 'CON_SV_DB2' is full.

Answer:• Automatic maintenance is supposed to assure that the database does not reach its

maximum capacity.• Sometimes, when the database reaches a very high value, it does not have enough

space to delete. This is because transactional databases need space for a possible rollback.

• Such cases are solved by increasing the database size, or activating auto maintenance after changing the high/low watermarks to assure that small portions would be deleted. For example, 95 low - 100 high percentage, or by specifying the last days. This assures that only one or few days would be deleted at a time.

• There is also an option to run a the executable RepDBManager.

RepDBManager example:RepDBManagr delete -t con_sv_db2 -d 2005-02-17

This deletes dates before 17-2-2005 from table sv_db2. You must add con_ prefix in the command line.

To delete dates between 2005-02-17 and 2005-02-28, and the auto maintenance fails with an error specifying that the table is full, run:

244

GeneratorApp


RepDBManagr delete -t con_sv_db2 -d 2005-02-17RepDBManagr delete -t con_sv_db2 -d 2005-02-18...RepDBManagr delete -t con_sv_db2 -d 2005-02-28

In order to see a list of all tables with dates, run:RepDBManager content -s

For customers that have a lot of daily traffic, the default of 70 - 80 watermark percentage might cause problems, since the next cleanup will occur when there is too much data.

In such cases, it is recommended to change the watermark to 75 - 76.

Issue:

The meaning of the following error in SVRServer.log and rc_lt.log:[SVRServer] Error: failed to to get password for connection RT_Database, reason: Could not find path to database socket

Answer:

The message refers to file $RTDIR/Database/mysql.sock. It is the communication socket for MySQL server that applications use to access the database. Make sure that this file exists. Also, look at $RTDIR/Database/my.cnf and verify that it has a line that refers to the socket path in the following format:

socket=pathToMySQL.sock

Another reason for the file to be missing and for this error is that the mysqld (MySQL server) is not running.

Verify that this .exe is running. If it is not, check in /var/$RTDIR/Database/data/database.err to see whether it contains information regarding the cause of the problem.

Issue:

Detecting a large amount of NBT drops [Netbios] traffic originating from the Eventia Reporter server. Once stopping all Check Point related services on the Eventia Reporter server - the traffic stops.

Answer:

The log_consolidator is trying to resolve IP to names using the gethostbyaddr system API. The default behavior is that 50 threads try to resolve simultaneously.




The DNS resolution can be turned off through the Management tab > Consolidation

Settings. Set the source and destination to have only Object Database instead of Object database and DNS.

To improve the performance, you can disable DNS or enable it on an internal addresses only.

To set feature on:cpprod_util CPPROD_SetValue "Reporting Module" dns_internal_only 1 true 1

To set feature off:cpprod_util CPPROD_SetValue "Reporting Module" dns_internal_only 1 false 1

Issue:

Enabling the Network Activity report option in Express Reports.

Answer:

In order to enable Express Reports, the following should be done on Firewall modules:

1 In the gateway Network Object Properties there are SmartView Monitor properties.There are three SmartView Monitor history options:• Check Point system counters - this option is checked by default• Traffic connections - this option has a performance impact on the module, and it

is not selected by default.• Traffic throughput (bytes per second) - this option has a performance impact on

the module (more than traffic connections), and it is not selected by default.The Network Activity report requires changing the default options to ones that want to have this express report, and their module can stand the performance penalty.If you change these options, you need to reinstall the policy on the module for the changes to take effect.

Note - You need to stop the consolidation session first.

246

GeneratorApp


2 In the Check Point Products List, verify that SmartView Monitor is selected.If you change options, you need to reinstall the policy on the module for the changes to take effect.

Issue:

Error message in Eventia Reporter: Failed to get default parameters from server/database when attempting to consolidate logs.

Answer:

This error is issued by the Eventia Reporter Client when it asks the server to get log information from the relevant Log Server, but the operation fails (usually due to lack of communication between Eventia Reporter and the Log Server).

<Reporting Installation Dir>/log_consolidator_engine/<LogServerIP>/ lc_rt.log can sometimes provide more information concerning this problem.

Common cases for lack of communication between Eventia Reporter and the Log Servers:• The Log Server is down.• The database was not installed on the Log Server after the reporter host was

defined. This is needed to satisfy the sic policy on the Log Server machine.• Firewall prevents Eventia Reporter from accessing the Log Server on lea port.

Question:

When generating SecureClient User Activity reports, the Top SecureClient Users by Login

Duration reports include SNX logins. However, other reports, such as List of All

SecureClient Users Login do not include SNX logins, returning a no data available for this

table message. Should SNX data be present in SecureClient User Activity reports? And if so, why some reports are generated correctly while others are not?

Answer:

In order to show the SNX login in the List of All SecureClient Login report, you can modify the Info Filter field to include also:

*reason: SSL Network Extender connected to gateway*

Note - SmartView Monitor must be installed on the module in order to generate a Network Activity report.

Note - By default, the report only has *reason: connected to gateway*, which gives only the SecureClient login.




Related remark:

Top SecureClient Users by Number of Policy Server Logins, SecureClient by Date, SecureClient

by Day of the Week, and SecureClient by Hour of the day show the number of logins related to the PolicyServer login.

If you want to see SecureClient and SNX logins instead, you can modify the filters of the relevant sections to match the filters of List of All SecureClient Login.

There is a possibility to export only records, older than a specified date by running:RepDBManager export -t <table_name>-f<dir_name>[-d<yyyy-mm-dd>].

This might be useful when creating a table, which contains records between specified dates. For example, if you want to create a table that contains records between 2005-9-20 and 2005-10-20 you can run:

RepDBManager export -t connections -f<export_dir> -d 2005-10-20 RepDBManager import -t new_table_name -f

<export_dir\timestamp\>connections.tbl

RepDBManager content -s - this prints a list of all non-empty tables while scanning all imported tables (the new table is titled CON_new_table_name), and deletes records older than 2005-09-20.RepDBManager delete -t CON_new_table_name -d 2005-09-20

Issue:

TDERROR_ALL_ALL has many error flags.

Answer:

Specify the following. The first three are relevant for the consolidator and reporter servers, while the last two are relevant only for the generator.• set TDERROR_ALL_SVRServer=5• set TDERROR_ALL_ReportingRepository=5• set TDERROR_ALL_ReportingIS=5• set TDERROR_ALL_Generator=5• set TDERROR_ALL_GenManager=5

248


CHAPTER 21

Eventia Analyzer

In This Chapter:

Login

Login page 249db_sync page 250Analyzer server page 250Correlation unit page 251syslog page 252

Problem Reason for failure Resolution

GUI states that there is no valid license.

CA needs to be established.

• Verify that SIC has been installed.• Verify in the GUI login client that

the server address is the Eventia Analyzer Server’s address and not Smart Center’s.

249

db_sync


db_sync

Analyzer server


No objects are seen in the Network Objects window

db_sync might have not begun

Run cpstop and cpstart on the Analyzer Server.

A particular object is not seen in the Network Objects window

db_sync might not have completed

Wait about 10-15 minutes. The progress of db_sync can be seen by viewing the file $FWDIR/conf/sem_network_

objects.C. As long as the file is growing, db_sync is still adding objects.

More detailed debugging is required

Issues due to SIC, CPMI, or dbsync

Turn on TDERROR from the command line:cpwd_admin stop -name CPSEMDexport TDERROR_ALL_DBSYNC=5export TDERROR_ALL_CPMIDBCLIENT=5export OPSEC_DEBUG_LEVEL=3cpsemdOutput is located in: $FWDIR/log/cpsemd.elg


Events are not received. Configuration Issues • Verify that the correlation unit and the log servers are set.

• Verify that the event policy is installed.

250


Correlation unitProblem Reason for failure Resolution

The Overview pane reports that the Correlation Unit cannot read logs from the log server.

A user might have changed fwopsec.conf so it does not accept LEA connections from port 18184 with authentication.

On the log server, verify that the file $FWDIR/conf/fwopsec.conf has the following default settings for lea_server:# lea_server auth_port 18184# lea_server port 0If these settings have been deliberately changed in order to read Check Point logs with another tool, find another free port to use with the auth_port method and configure this new port on Eventia in the following way:

• In Eventia GUI go to the Policy tab, then General Settings > Objects > Network Objects and double-click the Eventia object in order to see its details. In this screen, you can configure the new LEA port.

• If your current settings for the lea_server are not needed, revert back to the default settings by commenting out the two lea_server lines and performing:cpstopcpstart


The Correlation Unit is not identified properly on the log server.

• Install database on SmartCenter.• Install policy on the log server.


Implied rule problem in R60; R60a did not allow LEA communication between the Correlation Unit and the Log Server.

Add a rule to allow LEA communication originating from the Correlation Unit to the Log Server

Chapter 21 Eventia Analyzer 251

syslog


syslog


General LEA debugging Activate LEA debugging from the log server:fw debug fwd on OPSEC_DEBUG_LEVEL=3Attempt the connection and look in: $FWDIR/log/fwd.elg/fw debug fwd off



Messages are not seen in the Tracker

The wrong machine is being viewed (sanity check).

Verify that the machine that you are connecting to through SmartView Tracker is the same machine that had the accept syslog messages property enabled in SmartDashboard, and is the machine that syslog messages are being sent to.

syslogs can be seen in the Log Tracker, but they are not parsed

The syslogs might have been sent to a standard Check Point log server, rather than the Eventia log server that includes the advanced Free Text Parser policy.

Either redirect syslogs to the log server on Eventia Analyzer server, or Eventia Correlation Unit, or copy the advance Free Text Parser policy from the Eventia machines to the log server.

The syslog daemon is not running

The syslog daemon is not set in SmartDashboard

Enable the accept syslog messages in the Eventia object’s Smart Dashboard and perform cpstop and cpstart on the Analyzer Server. If a Correlation Unit was configured for this machine in Eventia Analyzer, see the next entry.

252


The syslog daemon is not running. It is not seen in the output to ps as syslog 514 all on Unix or in the Task Manager on Windows.

If the syslog server is a correlation unit as well, the Analyzer server holds a private copy of the correlation unit, so it cannot see the synchronized updates.

1. Remove the Correlation Unit definition for the syslog object in the Eventia Analyzer Client.

2. Modify the definition of the object in SmartDashboard by disabling the accept syslog messages property and saving the object. Then enable it again and save the object.

3. Run cpstop and cpstart.4. Reset the Correlation Unit

definition.

The syslog daemon is not running. It is not seen in the output to ps as syslog 514 all on Unix or in the Task Manager on Windows.

Only after the syslog daemon is synchronized and updated in $FWDIR/conf/sem_ network_objects.C, the Analyzer is restarted

Verify that the property Enable_SyslogD (true) is set for the Analyzer Server/Correlation Unit that reads syslogs. Then run cpstop and cpstart.

Messages are not parsed by the log server. The syslog contents are all in the field default_device_message, but no expected fields (source, dest) are populated

The machine that runs the syslog daemon might not have the files necessary to parse the syslog messages. This is particularly true in case of SmartCenter servers.

Set the Analyzer Server or Correlation Unit to run the syslog daemon or copy the files from $FWDIR/conf/syslog to the corresponding folder on SmartCenter.

Messages are not parsed by the log server. The syslog contents are all in the field default_device_message, but no expected fields (source, dest) are populated

The definition files are not defined correctly by the customer for the particular configuration.

Save a copy of the log file and open a problem ticket.

Eventia Analyzer does not receive events from the syslogs

The patterns in syslog traffic do not match any event definition.

Not every syslog is meant to generate an event.


Chapter 21 Eventia Analyzer 253

syslog


254


Section 5:Licensing


CHAPTER 23

Licensing

In This Chapter

Introduction - the license_upgrade toolThe license_upgrade tool allows you to:• View the status of the currently installed licenses. You can also view the licenses

in the SmartUpdate license repository on a SmartCenter Server (or a CMA, for Provider-1).

• Simulate a license upgrade process.• Perform a license upgrade process.

During the license upgrade, all eligible licenses are gathered and sent in SSL encrypted format to the User Center. Upgraded licenses are returned from the User center, and automatically installed. The license upgrade process adds only NGX licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses, or licenses that pertain to IP addresses no longer used) remain untouched.

Introduction - the license_upgrade tool page 257clic page 258Debugging License Commands on Windows page 258Debug License Commands on Unix/Linux page 259License Upgrade Tool page 260

Note - The descriptions in this chapter are relevant to upgrade procedures only.

257

clic


When running on a SmartCenter Server (or a CMA, for Provider-1), the license upgrade tool also handles licenses in the SmartUpdate license repository. After using the tool, SmartUpdate is used to attach the new NGX licenses in the license repository to the gateways.

For more information about the license_upgrade tool, see page 22 of the NGX Upgrade Guide.

clicA new CLI command was added: clic. It is the same as NGX's cprlic, except that it can communicate with all versions supported by NGX. The clic command is used to remotely bind licenses of various modules with versions older than NGX. In addition, a command was added to clic: clic bind. This command binds NGX licenses to NGX objects.

Debugging License Commands on Windows1 Open two command windows in Windows.

2 In both windows, set the following variables:set OPSEC_DEBUG_LEVEL=9

set TDERROR_ALL_ALL=5

3 If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start it (cpstart), and then kill fwm.

4 On one of the shell windows, run the following:Fwm m -d 2>fwm_debug.txt

5 On the other shell window run the clic command you wish to debug.Example: clic put <object_name> -l <license_file> >& clic_put_debug.txt

Once the clic command has completed its operation, the debug output file becomes available.


258


Debug License Commands on Unix/Linux1 Open the shell console.

2 Set the following variables:setenv OPSEC_DEBUG_LEVEL=9setenv TDERROR_ALL_ALL=5

3 If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start it (cpstart), and then kill fwm.

4 On one of the shell windows, run the following:Fwm m -d 2>fwm_debug.txt

5 On the other shell window run the clic command you wish to debug.Example: clic put <object_name> -l <license_file> >& clic_put_debug.txt

Once the clic command has completed its operation, the debug output file becomes available.


Chapter 23 Licensing 259

License Upgrade Tool


License Upgrade Tool1 The License Upgrade Tool can run as a wizard or from CLI.

The CLI available actions are:• upgrade: upgrades licenses from the User Center.• simulate: simulates upgrade option without changing the license files.• import: upgrades licenses from the cache file (without connecting to UC).• export: gathers licenses from the license file into a seperate file (for off-line

machines).• status: checks the machine for licenses that need to be upgraded (without

connecting to UC).Any action performed by the License Upgrade Tool can be executed in debug mode by using the -D flag.Example: license_upgrade -D import -c <cache_file>

2 After each action is manually applied, it is possible to retrieve the return code of the executed function.• On Unix/Linux: issue the command: echo $status.• On Windows: run a batch file that includes these lines:

license_upgrade.exe %*echo %errorlevel%

Execute the batch file with the command you would like to perform. For example: lic_batch.bat -c cache_file. The result is the license_upgrade output and its return code.

Return code values

Return code Value Description

LDT_OK 0 Operation status is OKLDT_ERROR 2 General errorLDT_ERR_MALLOC 3 Could not allocate memoryLDT_BAD_ARGS 4 Function received invalid/bad argumentsLDT_INCORRECT_USER_PASSWORD 5 Incorrect user name for operationLDT_COULD_NOT_RESOLVE_HOST 7 Could not resolve hostLDT_COULD_NOT_CONNECT 8 Connect failedLDT_HTTP_RETURNED_ERROR 9 If server returned error code >= 400

260

Return code values


LDT_LOCAL_CERT_PROBLEM 10 Problem with local certificateLDT_SSL_PEER_CERTIFICATE 11 The remote server's certificate is illegalLDT_FILE_NOT_FOUND 12 Could not find file on data objectLDT_LOCKED 15 FDT is locked by on-going transferLDT_BAD_SIG 17 Does not match expected CPSignatureLDT_INVALID_REQ 18 Invalid request business faultLDT_PARTIAL_VALID 19 Part of the licenses are validLDT_NOT_VALID 20 None of the licenses are validLDT_EMPTY_VALID 21 No licenses simulateLDT_COULD_NOT_GET_DATA 23 Could not get dataLDT_NO_LOCAL_LICS 24 None of the licenses correspond to the local hostLDT_TIMEOUT 25 Operation has timed outLDT_CPRLIC_ERR 26 Problem executing cprlicLDT_CPRLIC_CONN_ERR 27 connection failure while executing cprlicLDT_CPRLIC_ATTCH 28 Still needs to attach licensesLDT_TEST_FULL 30 All source licenses where replacedLDT_TEST_ERROR 31 General errorLDT_TEST_NONE 32 None of the source licenses where replacedLDT_TEST_PART 34 Part of the source licenses where replacedLDT_TEST_EMPTY 35 No licenses at allLDT_FTCH_NONE 42 None of the licenses where fetchedLDT_FTCH_PART 44 Part of the licenses where fetchedLDT_FTCH_EMPTY 45 No licenses at all to fetchLDT_DEL_EXP_NONE 46 None of the expired licenses were deletedLDT_DEL_EXP_PART 47 Part of the expired licenses were deleted

Return code Value Description

Chapter 23 Licensing 261

License Upgrade Tool


Logs Files generated by the License Upgrade Tool• $CPDIR/conf/lic_cache.C - contains all the licenses that were sent to the UC for

upgrade and the result received from the UC. These can be NGX licenses, error messages, licenses that cannot be upgraded (similar to an evaluation license).

• $CPDIR/log/license_upgrade.log - contains logs of the last action performed by the tool.

• $CPDIR/log/license_upgrade_status.log - as a result of the status check made by the tool, this file logs the current status of the licenses on the machine.

Provider-1 License Upgrade Tool

A default log file is created at $MDSDIR/log/pv1_license_uparage_debug.elg. This log holds all the debug information of the P-1 License Upgrade tool.

If needed, license_upgrade can be used on a specific CMA in order to debug any issues.

For additional information, see Troubleshooting License Upgrade on page 37 of the NGX Upgrade Guide.

Note - The cache file accumulates good results only.

Note - File is not accumulative; it contains a log of the last action only!

262


Index

Cclic 258cprlic 41, 258

Ddebugging

firewall NGX 5VPN-1 Pro 17, 19

Ffailover

ClusterXL 102, 103Eventia Reported 243

FTP connection 73FTP Security Server 7, 98fw monitor 21

buffering 25NAT 73SecureRemote 159Security Servers 86SNX Network Mode 199VoIP 128Web Intelligence 57

fwddebugging 5

GGateway connection

Legacy 153Standard 153Visitor Mode 153

HH.323 126High Availability

CCP 112ClusterXL 102fw module 7ICA 146

hooking 194

IIKEView 155

LLegacy 153licensing, commands debugging 41Lightweight Directory Access

Protocol (LDAP) 61

MMAC address 111Mail Dequeuer (MDQ) 90MDQ 97MGCP 126

NNAT 4

rules 39Secutiry Server 79SIC 29Traversal for SecureClient 148VoIP 128

NAT Traversal 149Main Mode Flow 151solution 149

Network Address Translation (NAT) 71

Nortel 34

Oobjects_5_0.C 48Open Security Extension (OSE) 33

QQuick UFP 82

Rrouters, Cisco 36routers, Nortel 34

SSCCP 126Secure Internal Communications

(SIC) 27Security Servers

debugging 6SIC

troubleshooting 27SIP 126SMTP

debugging security issues 96improvements 92Security Servers 90Troubleshooting Security

Servers 94

263


TTCP Resource 80TFTP 38

UUFP 82

264

ATRG_NGX

Documents

Transcript of ATRG_NGX