Atrg NGX

Advanced Technical Reference Guide
NGX (R60)
For additional technical information about Check Point products, consult Check Points SecureKnowledge at:
https://secureknowledge.checkpoint.com/
May 11, 2006
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
VPN Accelerator Card, VPN Edge, VPN-1 Pro, VPN1 Pro SecureClient, VPN-1 Pro SecuRemote, VPN1 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
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-toAddress Mapping, UserAuthority, VPN
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrusts 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, info@CheckPoint.com International 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 `ÀS 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 `ÀS 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 (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson (ellson@graphviz.org). 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 READMEJPEG.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, <daniel@haxx.se>.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 group@php.net. 4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. 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 `ÀS 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 group@php.net. 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 (tjh@cryptsoft.com). Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il> 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 copyright 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 <ph10@cam.ac.uk> 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.
Table Of Contents
Preface
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Who Should use this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Links to SecureKnowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Section 1: SmartCenter Chapter 1 Debugging and Monitoring

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Debugging Firewall NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Debugging fwd and fwm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Debugging Security Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Debugging Kernel Modules Using fw ctl debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Debugging VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 fw module Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 vpn Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 fg (QoS) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 uag (User Authority) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 rtm (SmartView Monitor) Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 strmod Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Debugging cpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Debugging VPN-1 Pro, DTPS, and DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Debugging VPN-1 Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Debugging dtps (Desktop Policy Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Debugging dtls (Desktop Log Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Debugging GUI to SmartCenter Server Communication . . . . . . . . . . . . . . . . . . . . . . . . .18 Monitoring VPN-1 Pro NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 cpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 cpwd_admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 cpinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 fw monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Basic Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Additional Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Chapter 2
Secure Internal Communications

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Troubleshooting SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Table of Contents i
Debugging SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Resetting 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 Extension

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Nortel (Bay) Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Configuring an SNMP Password on Nortel (Bay) Router . . . . . . . . . . . . . . . . . . . . . . . . 34 Further Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Cisco Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Cisco Router Version 9 and 11 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Common Issues and Resolutions (Cisco) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Debugging Cisco Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Allowing TFTP ACL Policy Installation from SmartCenter Server . . . . . . . . . . . . . . . . 38 Creating and Installing a Policy using a Command Line . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 4
SmartUpdate
Debugging Licensing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Debugging Licensing Commands On Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Debugging Licensing Commands On UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Debugging Communications Between SmartUpdate GUI Client and SmartCenter Server . 43 To Debug Attach and Detach Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 To Debug Import Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Adding a License to the SmartCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Remote Installation Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Pre-NGX Packages (BC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 NGX Packages and Beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 5
SmartMap
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Problems and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapter 6
Web Intelligence
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Application Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Monitor only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 The ActiveStreaming Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Web Intelligence Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ii
Debugging and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Enhanced Debugging Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Running Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Some debugging tips and tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Known Issues with Web Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Chapter 7
LDAP Servers and SmartDirectory

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 New Features in VPN-1 Pro NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Introduction to SmartDashboard User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 SmartDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 LDAP Schema in NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Modifying the Netscape Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Troubleshooting LDAP Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 LDAP Troubleshooting Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Modifying the Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Updating the Registry Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Delegating Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Adding New Attributes to the Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Issues with Active Directory and NGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Section 2: VPN-1 Pro/Express Chapter 9 Network Address Translation

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Original Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Reply Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Translated Packets and the Connection Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Debugging NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 NAT Related Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Chapter 10
Security Servers
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Editing security server default messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Calculating CPU and Memory Used for Security Servers . . . . . . . . . . . . . . . . . . . . . . . .78 Transparent Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 What Does Folding Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 TCP Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Checking Data Content Using TCP Resource for CVP Servers . . . . . . . . . . . . . . . . . . . .80 Screening URLs Using TCP Resource for UFP Servers . . . . . . . . . . . . . . . . . . . . . . . . .81 HTTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 VPN-1 Pro HTTP Security Server and HTTP 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Table of Contents iii
Enhanced UFP Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Chunk Transport Encoding with Content Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Partially and Fully Automatic HTTP Client Authentication on Issues . . . . . . . . . . . . . . 84 Rule Order for Content Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Troubleshooting security server performance issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Signature-Based URL Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 SMTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 SMTP E-Mail Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 The SMTP Security Server Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Improvements in SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Troubleshooting SMTP-Security Server Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Debugging SMTP Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 FTP Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Bidirectional FTP Data Connections not Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 PWD Command not Enabled on FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Adding Support for FTP Security Server Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Session Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapter 11
ClusterXL
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 ClusterXL Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Debugging Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Kernel Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 fwha_enable_if_probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 fwha_monitor_if_link_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 fwha_restrict_mc_sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 fwha_send_gratuitous_arp_var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 fw_allow_connection_traffic_drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 fw_allow_simultaneous_ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 fwtcpstr_reject_synced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 fwconn_merge_all_syncs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 The CPHA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 CPHA State Update Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Debugging CPHA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 ClusterXL Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Chapter 12
Voice Over IP (VoIP)

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 mgcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 skinny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 MSNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 H.232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Using the Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 All Protocols Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
iv
SCCP (Skinny) Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 MGCP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 MSN over SIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 SIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 H.323 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Section 3: VPN-1 Pro and Desktop Security Chapter 14 Internal Certificate Authority (ICA)
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Initialization and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 PKI and PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Recovery and Renewal with OPSEC Certified CA . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Recovery and Renewal with Entrust CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138 Internal CA Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 InternalCA.C File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 Administrator Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Benefits of the Internal CA Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 Batch Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 Internal CA High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Chapter 15
SecuRemote/SecureClient
NAT Traversal for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 The NAT Traversal Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 Connecting to the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Verifying the IKE Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 Office Mode - IP Assignment from a RADIUS Server for SecureClient . . . . . . . . . . . . . .161 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 GUI Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 Office Mode - DHCP Enhancements for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Configuring the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 General Information and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 Office Mode per site for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Why do we need this feature? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Enabling the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Office Mode per IP Range for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Turning on the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Table of Contents v
MSI Package for SecureClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 What is MSI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Supporting old InstallShield Package Abilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Improvements in the MSI Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 MEP and Interface Resolving Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Interface Resolving Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Resolving Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Manually Defined VPN List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 MEP Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 General Information and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Kernel Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Link Selection and Visitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Section 4: Additional Products Chapter 17 SNX

Application Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Basic Hooking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Debug Logs - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 StaProxy & Sta logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Debug Log - Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Network Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Troubleshooting procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Chapter 18
InterSpect
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Latest features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Memory Management Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 fw ctl pstat utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Unified Memory Allocation Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Kernel Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Fail Open NICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Performance and Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Acceleration Basic Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Debugging SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Performance Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Policy Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Bridge Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Dynamic List Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Cooperative Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Troubleshooting SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Splat Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
vi
Chapter 19
Connectra
Debug Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Debugging the CVPND Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Apache debugging processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227 Debugging the Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 Debugging File Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 Using the TraceLogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Debugging Web Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Chapter 20
Eventia Reporter
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 Eventia Reporter Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 Log Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 Eventia Reporter Client Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 Eventia Reporter Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 Licensing Eventia Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Debugging Eventia Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Log Consolidator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 SVRServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 My SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Log Consolidator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238 SVRServer Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 DBTableStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 GeneratorApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Common Questions/Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Chapter 21
Eventia Analyzer
Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 db_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Analyzer server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Correlation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251 syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
Section 5: Licensing Chapter 23 Licensing

Introduction - the license_upgrade tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 clic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Debugging License Commands on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Debug License Commands on Unix/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259 License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 Return code values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Table of Contents vii
Logs Files generated by the License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Provider-1 License Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
viii
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
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. 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. 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. Check the causes, one by one. Make sure you initialize your environment setting before testing. Go from the most likely cause to the least. 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.
Section 1: SmartCenter
C HA PT ER
Debugging and Monitoring

In This Chapter
Introduction Debugging Firewall NGX Debugging VPN-1 Pro, DTPS, and DTLS Monitoring VPN-1 Pro NGX fw monitor page 4 page 5 page 17 page 19 page 21
Introduction
Introduction
VPN-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.
Debugging fwd and fwm
Debugging Firewall NGX

This 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 Debugging Security Servers Debugging Kernel Modules Using fw ctl debug Debugging VoIP fw module Debug Options vpn Debug Options fg (QoS) Debug Options uag (User Authority) Debug Options rtm (SmartView Monitor) Debug Options strmod Debug Options Debugging cpd page 5 page 6 page 7 page 10 page 11 page 12 page 13 page 14 page 14 page 15 page 16
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 5
Chapter 1
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

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.
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

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
module (VPN) Kernel debugging options: driver err packet policy sas rdp clear cipher
vpn init sr comp xl counters mspi cphwd ref vin cluster nat l2tp warn
module (QoS) Kernel debugging options: driver error chain install tcp memory sched
fg time policy url dns rtm dom auth log conn drops dropsv rates timers chainq llq general verbose automatch autosched fwrate Chapter 1 Debugging and Monitoring 7
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
uag 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]
FW CTL debug options

Option -h -buf [buffer size] -x -m <module> +|<options|all|0> Explanation
Display usage for running kernel module in debug mode. If kernel module is specified, show the options for the module. Assign buffer size (in kilobytes) for the kernel debug. min buffer size = 128 KB; max = 32,768 KB. Merge objects.C file Assign the module to be debugged. Add or remove a debug option. 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 Debug fw Kernel Module Memory 1 2 3 Assign the minimum buffer size - 128 KB:
fw ctl debug -buf
Assign the debug option memory for the Firewall module:

fw ctl debug -m fw memory
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
Chapter 1
To Combine two Kernel Modules 1 2 3 4 5 6 Assign the minimum buffer size of 128 KB:
fw ctl debug -buf <value>
Assign the memory option for the Firewall module (for example):
fw ctl debug -m fw <option>
Assign the memory option for the VPN module (for example):
fw ctl debug -m vpn <option>
Verify that the chosen <option> is assigned to the Firewall module (-m):
fw ctl debug -m fw
Verify that the chosen <option> is assigned to the VPN module (-m):
fw ctl debug -m vpn
Start writing debug information to file_name:

fw ctl kdebug -f > <file_name>
Note - If running this command on a Windows platform, put a 2 before the redirect sign: 2>
<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.
10
fw module Debug Options
fw module Debug Options

Option Error Warning Cookie Crypt Domain Ex Driver Filter Hold If Install Ioctl Kbuf Ld Log Machine Memory Misc Packet Q Tcpseq Xlate Xltrc Conn Synatk Media Align Balance Explanation
Default output Warnings can be suppressed, but are still printed by default, except on SecuRemote/SecureClient. Cookie issues Encryption issues Domain resolution issues Table expiration (time-out) Kernel attachment Policy installation, SAM, fw monitor, boot-time Policy Held packets Network interface
fw ctl
install and uninstall
IOCTLs Kernel buffers Dynamic tables Logging Virtual machine operations Memory allocations Miscellaneous issues (especially licensing) Actions on packets (especially KFUNCs called by INSPECT) Message queues TCP sequence number manipulation NAT (including dynamic NAT) NAT for complex services (such as FTP) Connection table issues SYNdefender ARP, non-IP packets H.323 Load balancing
11
Chapter 1
Option Chain Bridge Tcpstr Scv
Explanation
Cookie chain and chain modules Currently unused TCP streaming SecureClient Verification
vpn Debug Options

Option Driver Err Packet Policy Sas Rdp Clear Cipher Init SecuRemote Mem Luna Counters Explanation
Issues related to driver attachment Errors that should not happen Events that can happen for every packet, unless covered by more specific options Events that happen only for a special packet in a connection, usually related to Policy decisions or logs/traps Keys and SA information printing Handling of RDP packets Dump of cleartext packet contents Dump of ciphertext packet contents Issues relating to the initialization of the VPN module SecuRemote server-specific events Hardware-buffer management Events that happen when using the Luna card Status counters
12
fg (QoS) Debug Options
fg (QoS) Debug Options

Option Driver Error Chain Install Tcp Memory Sched Time Policy url Dns Rtm Dom Auth Log Conn Drops Dropsv Rates Chainq Explanation
Driver activation and attachment to the kernel Different error messages; option turned on by default Tracing each packet through QoS points in the cookie chain Policy installation and building internal data structure TCP streaming mechanism Failed memory allocation Basic scheduling information Currently unused Classification information URL and URI for Quality of Service (QoS) classification mechanism DNS classification mechanism Failures in information gathering from SmartView Monitor module (currently unused) Authenticated QoS feature debug information Logging information Connection information and identification Dropped packets due to WFRED Policy Same function as drops argument, with additional debug information IQ Engine behavior and status Holding and releasing packets during critical actions (Policy install/uninstall)
Chapter 1
13
uag (User Authority) Debug Options

Option Driver Error Uag_forward_ip Uag_api_client Explanation
Informative messages about the UAG, such as IOCTL, connection, NAT Displays error messages (when turned on) NULL pointer (currently unused)
rtm (SmartView Monitor) Debug Options

Option Driver Err Topo Policy Init Chain Explanation
Displays general driver information (e.g., loading/unloading) Default arguments (always on by default) Displays critical errors Displays information about how the SmartView Monitor calculates network topography by itself Displays fw load/unload messages (The SmartView Monitor received the Firewall callback.) (rarely used) 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 RTM ioctl printouts Displays information about SmartView Monitor importing functions from other modules (Firewall, QoS) Displays information about how the End-to-End (E2E) modifies E2ECP protocol packets Displays information about SmartView Monitor monitoring
Ioctl Import Special Rtm
14
strmod Debug Options
Additional SmartView Monitor Debug Arguments (for NG FP1 and Higher)

Option Rtmpkt Netmasks Kviews Sort Sort_stat Explanation
Displays per-packet information while SmartView Monitor is monitoring (a lot of output) Displays information about how the SmartView Monitor handles netmasks; useful when monitoring network objects Kernel-view debugging (when opening/closing a GUI or command-line client) Debugging the SmartView Monitor top X monitoring sorting Displays sorting statistics; useful for debugging algorithm effectiveness
strmod Debug Options

Option Msg Msgerr If Iferr Fpack Fpnak Okack Errack State Open Openerr Filter Ipmsg Ipctl Ofterr Oftab Explanation
Messages in the stream queues Problems with handling messages from stream queues Interface and Qdata information Problems with interface Qdata ACK from data link on fastpath No ACK from data link on fastpath OK ACK from data link Error ACK from data link Data-link attachment state Opening or closing devices/queues Problems opening or closing devices/queues Streams module filter (such as fastpath) (unused) IP control commands Problems with Oftabs Oftabs information (oftabs hold interface data)
Chapter 1
15
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
Note - On UNIX and Linux platforms write setenv instead of set, and no = is needed.
Logs are automatically redirected to $CPDIR\log\cpd.elg.
16
Debugging VPN-1 Pro
Debugging VPN-1 Pro, DTPS, and DTLS

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

Option vpn debug < on | off | ikeon | ikeoff > vpn crl_zap vpn drv < on | off | stat > vpn ver [-k] vpn accel < on | off | stat [-l] > vpn crlview vpn pkcs11 < add | remove | test | print> vpn debug trunc Explanation
Prints debug messages to VPN-1 Pro log files Erases all Certificate Revocation Lists (CRL) from cache Attaches vpn driver to fw driver Displays VPN-1 Pro version Operations on VPN-1 Pro accelerator card Debugging tool for CRLs Configuring PKCS11 device 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.
Logs for these commands are automatically redirected to: $FWDIR/log/vpnd.elg
Chapter 1
17
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.
Note - This step replaces the command fwpolicy -d.
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 2
18
Run the fw debug fwm command. Run tail -f on the fwm.elg file before trying to connect with the GUI Client.
cpstat
Monitoring VPN-1 Pro NGX

This section presents step-by-step instructions for using each of the following monitoring utilities:
cpstat cpwd_admin cpinfo
In This Section
cpstat cpwd_admin cpinfo page 19 page 19 page 21
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.
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.
Usage
cpstat [-h host][-p port][-f flavour][-d] entity
or
cpstat [-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.
Chapter 1
19
Monitoring VPN-1 Pro NGX
Usage
cpwd_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 FWD
cpwd_admin start -name FWD -path /opt/CPfw1-50/bin/fw -command fw d
Stop CPD with command

cpwd_admin stop -name CPD -path /opt/CPshared/5.0/bin/cpd_admin -command cpd_admin stop
Stop FWD with command

cpwd_admin stop -name FWD -path /opt/CPfw1-50/bin/fw -command fw kill fwd
Kill <PID> brutally

cpwd_admin stop -name <PID>
Print status of processes

cpwd_admin list (PID that Watch Dog is tracking)
Stop CPWD
cpwd_admin kill (Watch Dog stop tracking on PID)
Check if CPWD is running

cpwd_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 (support@ts.checkpoint.com) for analysis.
Note - The cpinfo command replaces the fwinfo command in VPN-1 Pro 4.1.
Run the command as follows:

cpinfo > <file_name>
fw 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.
fw monitor
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
Basic Use Additional Options Advanced Topics page 22 page 23 page 24
Chapter 1
21
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 -h -d/-D -m Explanation
Displays a usage string Prints debug messages (two different debug levels) 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. Prints packet data. Specifies the starting offset to print and the number of bytes to print 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. 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). Prints the connections UUID (unique ID) Prints the connections session UUID (for FTP data connections, prints the control connections UUID) When compiling the inspect script, includes tcpip.def. This allows the use of TCP/IP macros in the script. 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. 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. Monitors position (See Advanced Topics on page 24.)
-x offset, length -l length
-o filename
-u -s -t -i
ci count, -co count
ip
Chapter 1
23
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 modules purpose Alias (shown in parenthesis) A short name that can be used with the p parameter. 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.
fw monitor
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. Theres 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.
Chapter 1
25
fw monitor
26
C HA PT ER

In This Chapter
Introduction Configuration Troubleshooting SIC Known SIC Issues page 27 page 28 page 29 page 31
Introduction
Secure 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.
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
Configuration
FIGURE 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 SIC
To 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
29
Troubleshooting SIC
Debugging SIC
On the Security Gateway, cpd provides SIC-related information to the following files: Windows
C:\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

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

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 Gateways certificate, and changes the SIC status to Not initialized. 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 Gateways 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 2 3 4 5 Delete the Firewall object. On the relevant Firewall Security Gateway, use the cpconfig configuration tool to initialize SIC again for the newly created object. Enter a new one-time password. In SmartDashboard, create a new Firewall Security Gateway object with a new name. Initialize SIC for the newly defined Firewall Security Gateway object.
Chapter 2
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 2 3 4 On the Security Gateway, use cpconfig to initialize SIC, by typing a new one-time password. In SmartDashboard and the object, reset SIC.
Communications
window of the Security Gateway
Initialize SIC by typing the same one-time password as used at the Security Gateway. To verify SIC, click
Test SIC Status.
32
C HA PT ER

In This Chapter
Introduction Nortel (Bay) Routers Cisco Routers General Information page 33 page 34 page 36 page 38
Introduction
The 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.
33
Nortel (Bay) Routers
Nortel (Bay) Routers

When 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 2 3 4 5 6 Select the router you would like to configure. There is a small window that lists all routers the Site Manager knows about. From the Site Manager Menu, select Tools > Configuration Manager > Dynamic. This opens a Configuration Manager window, which lets you configure a specific router. 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. On the configuration Manager, select Protocols > IP > SNMP Communities. This opens a window called SNMP Community List. On the SNMP Community List window, select Community > Add Community to add your own community and give it read/write permissions. 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. Exit the Managers and SNMP Community List windows. Do not erase the Public default community yet. In the Configuration Manager, save your definition in a file, preferably with a .cfg suffix (File > Save As).
7 8
34
Further Security Considerations
In SmartDashboard 1 2 3 4 5 6 Select In the In the Click

Manage > Network Objects. Network Objects
window click
New > OSE Device Nortel
OSE Device Properties SNMP Info...
window, select
from the
Type
menu.
In the SNMP Information window, change the values of both Read and Write fields to the new community defined previously, using Nortels Site Manager. Make rules which have either routers or the specific router, in the Install On field.
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.
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. 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.
Chapter 3
35
Cisco Routers
Cisco Routers
In This Section
Cisco Router Version 9 and 11 Differences Common Issues and Resolutions (Cisco) Debugging Cisco Routers page 36 page 36 page 36
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 routers 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
36
Debugging Cisco Routers
Syntax
router_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.
Chapter 3
37
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
Note - rhost might not exist under /root, and may need to be created. Create the /tftpboot directory.
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 hosts 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.
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 2 3 4 5 Launch SmartDashboard. Create a new Policy Package for the OSE device (ACL Policy). Press
CTRL+S
to save the Policy.
On the SmartCenter Server, under $FWDIR/conf, issue the following command:

fwm gen -cisco <Policy file>.W > <file name>.cl
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 7
Save the changes. Once the *.cl file is edited, issue the following command:
router_load -cisco <router name/IP> *.cl password <your password> enablepassword <your enable password>
Chapter 3
39
General Information
40
C HA PT ER
SmartUpdate
In This Chapter
Debugging Licensing Commands page 41
Debugging Communications Between SmartUpdate GUI Client and SmartCenter Server page 43 Remote Installation Debugging page 44
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 2 3 All functions are executed by the SmartCenter Server (fwm). Both fwm and the licensing command itself must be debugged in different shells. Debug output can be directed either to a file or to the screen.
41
Debugging Licensing Commands
Debugging Licensing Commands On Windows

1 2 Open two command windows. In both windows, set the following variables:
set OPSEC_DEBUG_LEVEL=3 set TDERROR_DEBUG_LEVEL=3
3 4 5
If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start the Firewall (cpstart) then kill fwm. In one of the shell windows type the following:
fw m -d 2> fwm_debug.txt
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 2 Open two shell consoles. In both consoles, set the following variables:
setenv OPSEC_DEBUG_LEVEL 3 setenv TDERROR_DEBUG_LEVEL 3
3 4 5
If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start the Firewall (cpstart) then kill fwm. Type the following command in one of the shell windows:
fwm -d >& fwm_debug.txt
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. 6 Stop the fwm -d command by typing CTRL+C. This kills the fwm process, so it needs to be restarted.
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.
Note - The debug output is related only to operations taking place between the SmartUpdate client and the SmartCenter Server.
In This Section
To Debug Attach and Detach Operations To Debug Import Operations Adding a License to the SmartCenter Server page 43 page 43 page 44
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. Open the SmartUpdate client, and perform the Attach/Detach operation. The file __CPDebugOutput.txt, containing debug output, is created in the directory:
C:\Program Files\CheckPoint\Management Clients\5.0\PROGRAM\
2 3
To Debug Import Operations

1 2 3 4 5 Open a registry editor (regedit32) and go to:
$HKEY_LOCAL _MACHINE\Software\CheckPoint\Connection\5.0
Add a new string value: Debug = 1 Close the registry editor. Open the SmartUpdate client, and Import a License. The file __CPMIreply.txt containing debug output is created under:
C:\Program Files\CheckPoint\Management Clients\5.0\PROGRAM\
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 2 3 4 5 6 Open the Check Point Configuration Tool (cpconfig). Choose the
Licenses
tab.
Choose Fetch From File, and browse to the location of the license file received from the License Center. Select Open. A message appears, stating that one license was found suitable for that module. Click
OK.
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
Note - CPRID logs do not apply to older packages.
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
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.
Note - The cpms script runs with different parameters for installation, un-installation, and verification.
- 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
/opt/CPInstLog/cpget.elg
46
C HA PT ER
SmartMap
In This Chapter
Introduction Configuration Troubleshooting page 47 page 48 page 49
Introduction
SmartMap 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.
47
Configuration
Configuration
When 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 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 SmartDashboard.
SmartMap
File > Save
in
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
Troubleshooting
When troubleshooting SmartMap issues, remember that the Topology map and its capabilities are a reflection of the definitions in objects_5_0.C. 1 2 Compare object-node names between the objects_graph.mdl file under the Nodes paragraph, and object name in the objects_5_0.C file. 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
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
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. Log into SmartDashboard in Demo mode. Check the
Demo
4 5
box located under
Server.
50
C HA PT ER
Web Intelligence
In This Chapter
Introduction The ActiveStreaming Mechanism Licensing Web Intelligence Logs Debugging and monitoring Known Issues with Web Intelligence page 52 page 54 page 55 page 55 page 56 page 57
51
Introduction
Introduction
Web 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 Mechanism

The 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
Note - The decision as to which streaming to use is on a per connection base.
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
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 Logs

Web 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).
Chapter 6
Web Intelligence
55
Debugging and monitoring
Debugging and monitoring

In This Section
Enhanced Debugging Capabilities Running Debug Some debugging tips and tricks page 56 page 56 page 57
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
56
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 Intelligence

Error 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 module 0 - Disables Active Streaming on the enforcement module To change kernel global parameters, refer to
sk25826.
2 3 4
After changing the value, run cpstop, followed by cpstart at the command line. To view the current value of the cpas_enabled parameter, type the following command at the Gateway console:
fw ctl get int cpas_enabled
sk27151
For more information please refer to
Chapter 6
Web Intelligence
57
Error 2:
Illegal header format detected Malformed HTTP version in request
(Error Code WSE0020001)
Possible causes: 1 2 The request contained an illegal HTTP version; the version must be indicated by a number (for example, 1.1 or 1.0). 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. 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. 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.
3 4
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 (2): No workaround exists; the HTTP request cannot be parsed correctly. Cause (3): 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
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.
Chapter 6
Web Intelligence
59
60
C HA PT ER

In This Chapter
Introduction Introduction to SmartDashboard User Management SmartDirectory Troubleshooting LDAP Issues Modifying the Active Directory Schema Issues with Active Directory and NGX page 61 page 62 page 63 page 64 page 65 page 66
Introduction
This 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
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 Management

Account 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.
SmartDirectory
SmartDirectory 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
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 Issues

LDAP 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. 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. In Netscape LDAP there are two files located under \admin-serv\logs directory, called access and error logs.
64
Updating the Registry Settings
4 5 6 7 8
Check the slapd.conf file on the LDAP server, which contains definitions and parameters for the LDAP server. Check connections between VPN-1 Pro and LDAP, run monitors, and check connectivity without SSL. Check HyperBolic Schema on LDAP server. Extend the schema again, if necessary. Check for error logs in SmartView Tracker. 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=*
Run the ldapcompare utility.
Modifying the Active Directory Schema

The 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 2 3 4 Display the Users and Computers Control console. 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. Add the administrator, or another user from the System Administrators group, to the list of users who can control the directory. Reboot the machine.
Chapter 7
65
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

Issue 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 2 3 4 Install Microsoft Enterprise CA in the same Active Directory domain. In the Default Domain Controllers Policy console (of the Group Policy snap-in), select Computer Configuration > Windows Settings > Security Settings > Public Key Policies. Right-click Select
Automatic Certificate Request Settings,
and select
New > Automatic
Certificate Request.
A wizard appears. and follow the instructions.
Domain Controller,
Note - If your Windows server does not support strong encryption, install Microsoft's Strong Encryption Pack.
In the Encryption tab of LDAP Account Unit object's properties, specify both Min and Max encryption strength.
Strong
for
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>
Chapter 7
67
68
Section 2: VPN-1 Pro/Express
C HA PT ER
Network Address Translation

In This Chapter
Introduction Translated Packets and the Connection Table Debugging NAT Issues NAT Traversal page 71 page 73 page 73 page 75
Introduction
In 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 Gateways 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.
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 2 3 4 5 The packet arrives at the inbound interface and passes the Security Policy rules. If accepted, the packet is admitted into the connection table. The packet is matched against NAT rules for the destination. If a match is found, the packet is translated. The packet arrives at the Security Gateway TCP/IP stack, and is routed to the outbound interface.
Note - The packet is translated, so it is routed correctly without any need to add a static route on the Security Gateway.
6 7 8
The packet goes through the outbound interface, and is matched against the NAT rules for the source. If a match is found for translating the source, NAT takes place. 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 2 3 The packet arrives at the inbound interface of the Security Gateway. Since the packet is found in the connections table, it is granted admission by the Security Policy. 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. The packet arrives at the Security Gateway TCP/IP stack, and is routed to the outbound interface. 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.
4 5
72
Reply Packet
The packet leaves the Security Gateway.
Translated Packets and the Connection Table

A 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 Issues

To 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
73
Debugging NAT Issues
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 4 5
Start a connection that reproduces the problem. Stop fw monitor. 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 Accept Server 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 failed FW: fw_xlate_update_packet: fw_xlate_update_length failed FW: fw_xlate_anticipate_cookie: fw_xlate_update_packet failed
NAT Traversal
NAT Traversal is supported according to NAT Traversal RFC 3947.
Chapter 9
75
NAT Traversal
76
C HA PT ER
10
Security Servers
In This Chapter
Introduction Transparent Server Connection TCP Resources HTTP Security Server SMTP Security Server FTP Security Server page 77 page 79 page 80 page 82 page 90 page 98
Introduction
The 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
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 2 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. 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 Connection

When 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.
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.
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
Note - To edit objects_5_0.C, use the dbedit utility. See SecureKnowledge solution skI3301 for instructions.
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 servers special port. Performing NAT on the Security Gateway address is called "folding."
Chapter 10
Security Servers
79
TCP Resources
TCP Resources
It 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 2 3 4 5 6 Create a new TCP resource. From the SmartDashboard menu, select Resource, and click New TCP.
Manage >
Configure the new TCP resource to use a CVP server, and configure the server's details. In a rule Service column, select the desired TCP service.
Add with Resource
to add the new TCP resource to

Enable for TCP Resource
In the TCP Service Properties Advanced tab verify that the checkbox is selected. Stop the Firewall.
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 8
Restart the Firewall. 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 2 3 4 5 Create a new TCP resource. From the Resource, and click New TCP.
SmartDashboard
menu, select
Manage >
Configure the TCP resource using a UFP server, and configure the server's details. In a rule Service column, select the desired TCP service.
Add with Resource
to add the new TCP resource to

Enable for TCP Resource
In the TCP Service Properties Advanced tab, verify that the checkbox is selected. Install the Policy.
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.
Chapter 10
Security Servers
81
HTTP Security Server

In This Section
VPN-1 Pro HTTP Security Server and HTTP 1.1 Enhanced UFP Performance Chunk Transport Encoding with Content Inspection Rule Order for Content Security Troubleshooting security server performance issues Signature-Based URL Filtering page 82 page 82 page 83 page 85 page 85 page 88
Partially and Fully Automatic HTTP Client Authentication on Issues page 84
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 2 3 4 The user daemon sends the URL to the UFP server. The client's request is sent to the Web server before the UFP responds. The user daemon receives the answer and sends it to the kernel. The server's response arrives, and is sent to the client. No changes are needed on the UFP server itself.
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.
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.
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 - Use the dbedit utility to edit objects_5_0.C.
Chapter 10
Security Servers
83
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 servers. 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.
Chapter 10
Security Servers
85
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 2 Separate VPN-1 Pro and the CVP servers. 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. 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. 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
Chapter 10
Security Servers
87
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 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.
Info
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 2 3 4 5 Close SmartDashboard. On the SmartCenter Server, use dbedit to change the following property:
Fwurl_filter_pattern (.ida?)
Edit the default .ida? to the pattern desired. Open SmartDashboard and create a new URI resource. In the Optimize URL Blocking. Configure a new rule:
General
tab, select
Install the Policy.
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)
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)
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)
Chapter 10
Security Servers
89
SMTP Security Server

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

FIGURE 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.
90
The SMTP Security Server Process
The SMTP Security Server Process

FIGURE 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. 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. The SMTP security server receives the connection and checks the appropriate resource of the rule to determine how to handle the connection (accept/drop). The asmtpd daemon performs a separate rule match for every recipient. After performing all the necessary actions, the message is transferred to the spool directory, and waits there for the mail dequeuer. 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. 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.
3 4 5 6
Chapter 10
Security Servers
91
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. 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:
Chapter 10
Security Servers
93
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

SecureKnowledge solution ID 1 2 3
10022.0.1775714.2480161
SMTP security server problems might arise in three places: Connection between the e-mail client and the SMTP security server Connection between the mail dequeuer and the anti-virus (CVP) server 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. 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 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 UNIX If this entry does not exist, add the following line to the fwauthd.conf file:
25 fwssd in.asmtpd wait 0
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 SecureKnowledge solution ID

10022.0.1775726.2480161
Troubleshoot the connection between the mail dequeuer and the anti-virus server as follows: 1 2 Make sure VPN-1 Pro can Ping the anti-virus (CVP) server. 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. 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. 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. 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.
3 4 5
Chapter 10
Security Servers
95
Mail-Dequeuer Connection to Final e-mail Server Fails SecureKnowledge solution ID

10022.0.1775733.2480161
Troubleshoot the connection between the mail dequeuer and the final e-mail server as follows: 1 2 Verify VPN-1 Pro can Ping the final e-mail server. 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.. 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. SMTP Security Server To debug the SMTP security server, run the following commands: 1 2 Issue the fwstop command, or fw kill fwd. On UNIX run:
fw debug in.asmtpd
on FWASMTPD_DEBUG 3 on FWASMTPD_DEBUG=3
On Windows run:
fw debug in.asmtpd
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 resolving

fw 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 2 Issue the fwstop command, or fw kill fwd. 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
Run fwstart or fwd.
Chapter 10
Security Servers
97
FTP Security Server
FTP Security Server

The 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
Note - SITE commands are allowed to pass during login through a proxy in the authentication process (sk26372).
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.
98
PWD Command not Enabled on FTP Server
PWD Command not Enabled on FTP Server

SecureKnowledge solution ID
3.0.143507.2194044
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, LIST, NLST, RNTO, XMD5, ACCT, MACB, NOOP, SITE, XMKD, ALLO, MAIL, PASS, SIZE, XPWD, APPE, BYE, BYTE, CDUP, MDTM, MKD, MLFL, MODE, PASV, PORT, PWD, QUIT, SOCK, STOR, STOU, STRU, XRMD. CWD, DELE, FIND, FW1C, MRCP, MRSQ, MSAM, MSND, REIN, REST, RETR, RMD, SYST, TYPE, USER, XCUP, HELP, MSOM, RNFR, XCWD,
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.
Chapter 10
Security Servers
99
FTP Security Server
100
C HA PT ER
11
ClusterXL
In This Chapter
Introduction ClusterXL Configuration Issues Debugging Flags Kernel Flags High Availability page 102 page 103 page 103 page 104 page 110
101
Introduction
Introduction
ClusterXL 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 Issues

For information about ClusterXL configuration issues, and basic troubleshooting procedures, see the Check Point ClusterXL NGX (R60) Guide.
Debugging Flags
Debugging 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
Note - There is also the sync flag which is in the fw topic and shows debug that is related to sync only.
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
Chapter 11
ClusterXL
103
Kernel Flags
Kernel Flags
For information on setting kernel flags so that the new value survives a reboot, refer to Sk20364.
In This Section:
fwha_enable_if_probing fwha_monitor_if_link_state fwha_restrict_mc_sockets fwha_send_gratuitous_arp_var fw_allow_connection_traffic_drop fw_allow_simultaneous_ping fwtcpstr_reject_synced fwconn_merge_all_syncs page 104 page 105 page 106 page 106 page 107 page 108 page 109 page 109
fwha_enable_if_probing
Determines whether ICMP probing is enabled.
1 0
- turn the feature on (default) - 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. 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. 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
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. With this report from the secondary, the primary concludes the issue is with its own interface, and moves to the "Down/Dead" status. The secondary issues gratuitous ARPs for both the physical, and cluster address per IP segment, and moves to the "Active/Active-Attention" state.
5 6
fwha_monitor_if_link_state
Determines whether the MILS feature is enabled or disabled.
1 0
- turn the feature on - 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 clusters state to Active/Down. For more details see
sk31336.
Chapter 11
ClusterXL
105
Kernel Flags
fwha_restrict_mc_sockets
Determines if a multicast socket is open.
1 0
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.
1 0
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.
1 0
When the Parameter is Turned On 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. Lets 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. When the Parameter is Turned Off Allow this ACK packet to pass, or any packet that the connection has not yet established.
Chapter 11
ClusterXL
107
Kernel Flags
fw_allow_simultaneous_ping
Enables pinging the Virtual IP of the cluster regardless of failover events.
1 0
When the Parameter is Turned Off 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 A --> H
(assuming A is the first member to handle it)
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. When the Parameter is Turned On 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
1 0
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.
1 0
When the Parameter is Turned Off 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 the Parameter is Turned On 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).
Chapter 11
ClusterXL
109
High Availability
High Availability
In This Section:
Introduction The CPHA Protocol CPHA State Update Mechanism Debugging CPHA Issues ClusterXL Configuration Issues page 110 page 115 page 117 page 118 page 120
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.
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 /etc/etheraddr <interface name>
Solaris Windows Linux
registry: HKEY_LOCAL_MACHINE\SYSTEM\Current control set\Services\Interface name\Parameters\Network address

/etc/sysconfig/network-scripts/ifcfg-<interface_name>
Chapter 11
ClusterXL
111
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 machines 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 bytes 6 0.00468 OLD-BROADCAST -> 10.0.0.0 IP D=10.0.0.0 S=0.0.0.0 LEN=52, ID=0 6 0.00468 OLD-BROADCAST -> 10.0.0.0 UDP D=8116 S=8116 LEN=32 0: 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.
Chapter 11
ClusterXL
113
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 bytes 7 0.00013 OLD-BROADCAST -> 10.0.0.0 IP D=10.0.0.0 S=0.0.0.0 LEN=64, ID=0 7 0.00013 OLD-BROADCAST -> 10.0.0.0 UDP D=8116 S=8116 LEN=44 0: 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.
Chapter 11 ClusterXL 115
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 bytes 2 0.04832 OLD-BROADCAST -> arpanet IP D=10.0.0.0 S=0.0.0.0 LEN=64, ID=0 2 0.04832 OLD-BROADCAST -> arpanet UDP D=8116 S=8116 LEN=44 0: 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.
Chapter 11
ClusterXL
117
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 Packets

FIGURE 11-5 General Analysis Matrix for CPHA Packets
Chapter 11
ClusterXL
119
High Availability

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.
Chapter 11
ClusterXL
121
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
Chapter 11
ClusterXL
123
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
C HA PT ER
12

In This Chapter
Introduction Debug Commands Using the Debug page 126 page 127 page 128
125
Introduction
Introduction
VPN-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 Commands
The 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.
SIP
fw ctl debug -buf 16000 fw ctl debug + sip fw ctl kdebug -f > file.dbg
mgcp
fw ctl debug -buf 16000 fw ctl debug +mgcp fw ctl kdebug -f > file.dbg
skinny
fw ctl debug -buf 16000 fw ctl debug -m CPAS skinny fw ctl kdebug -f > file.dbg
MSNMS
fw ctl debug -buf 16000 fw ctl debug + msnms sip fw ctl kdebug -f > file.dbg
H.232
fw ctl debug 0 fw ctl debug -buf 16000 fw ctl debug -m h323 all fw ctl kdebug -f > file.dbg
Chapter 12
127
Using the Debug
Using the Debug

1 2 Run one of the above debug commands, depending on the scenario. 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 4
Replicate the scenario that is being investigated. After replicating the issue, stop the debug.
In This Section
All Protocols Messages SCCP (Skinny) Messages MGCP Messages MSN over SIP Messages SIP Messages H.323 Messages page 129 page 129 page 130 page 130 page 131 page 132
128
All Protocols Messages
All Protocols Messages

Log Message Illegal redirect X.X.X.X-> X.X.X.X Cause Resolution
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. Increase the number in Smart Defense Or: Deselect the Enable VOIP DOS Protection checkbox.
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.
SCCP (Skinny) Messages

Log Message Unknown SCCP message type Cause Resolution
The specific SCCP protocol is not supported by the Firewall. A message between the Call Manager and the Gateway should be NATed, but contains the real IP address.
Contact Check Point Technical Support. NAT for SCCP service is not supported by VPN-1 Pro. NAT should not be applied on the Call Manager and its related endpoints
Connection contains real IP of NATed address
Chapter 12
129
Using the Debug
MGCP Messages
Log Message Unallowed MGCP datagram, command blocked broadcast/multicast addresses are not accepted (client)" / (server) Connection contains real IP of NATed address Cause Resolution
In SmartDefense, this message is not in the list of allowed commands. In SmartDefense, you can allow rtp in multicast mode. A message between the Call Manager and the gateway should be NATed, but contains the real IP address.
Add the command to the allowed commands list. Deselect the

Drop multicast
RTP connections
option in
SmartDefense. NAT for SCCP service is not supported by VPN-1 Pro. NAT should not be applied on the Call Manager and its related endpoints
MSN over SIP Messages

Log Message File Transfer is not allowed by the security policy Cause Resolution
1. The service
MSN_Messenger_File_ Transfer is not allowed
1. Deselect Block File Transfer in SmartDefense. 2. Add the

MSN_Messenger_File_ Transfer to the rule base.
in the rule base. 2. In SmartDefense under MSN over SIP, the Block file transfer option is checked.
Application Sharing is not allowed by the security policy Whiteboard is not allowed by the security policy Remote Assistance is not allowed by the security policy
In SmartDefense under MSN over SIP, the Block application sharing option is checked.
over SIP,
Deselect Block Application Sharing in SmartDefense. Deselect Block Whiteboard in SmartDefense.
In SmartDefense under MSN the Block Whiteboard is checked.
over SIP,
In SmartDefense under MSN Deselect Block Remote the Block Remote Assistance in SmartDefense. Assistance option is checked.
130
SIP Messages
Log Message Instant Messaging is not allowed by the security policy
Cause
Resolution
In SmartDefense under MSN 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 Deselect Blocked calls using a under SIP, the Blocked calls proxy or a redirect server in SmartDefense. using a proxy or a redirect server option is not checked.
SIP Messages
Log Message NOTIFY message out of state Cause Resolution
This message can appear for Contact Technical Support numerous messages, not services after you collect the only NOTIFY. It usually relevant SIP debug. indicates a problem in the SIP state machine. This log is usually issued when trying to use bi-directional SIP connections. A real IP appeared instead of the NATed IP. This is issued when the firewall expects a certain field in the SIP packet, but the field is missing. This message appears when the destination tries to reinvent a call. In the rule base, add
sip_dynamic_ports
Violated unidirectional connection
service (in the UDP services list) to the corresponding SIP rule.
Connection contains real IP of NATed address Malformed SIP datagram, invalid SIP headers
Contact Technical services after you collect the relevant SIP and NAT debug. Contact Technical services after you collect the relevant SIP debug. Deselect
Block the destination
Enforcing major security - reinvents rejected
from re-inviting calls.
Chapter 12
131
Using the Debug
Log Message Reinvents exceeds the limit
Cause
Resolution
In SmartDefense under Increase the number of Application intelligence, in the Maximum invitations per call. VOIP section under SIP, the
Maximum invitations per call
option has been exceeded.
The allowed maximum is 4.
H.323 Messages
Log Message Received Unregistration request without prior registration Cause Resolution
When the table is empty and the phone executes an Unregistration request.
h323_registration
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. Due to a configuration problem in the network, the Firewall did not see the setup message. Possible routing problem. Verify that the destination/source number are in E.164 format.
Invalid H.225 session. Not initialized with Setup Message
This message appears when H.225 are seen without a setup message.
ACF/GRQ/GCF/LRQ/LCF without a prior ARQ
Confirm to unknown request Malformed RAS message. No source phone number found
seen
The Firewall supports the phone number in an E.164 format.
132
Section 3: VPN-1 Pro and Desktop Security
C HA PT ER
14
Internal Certificate Authority (ICA)

In This Chapter
Introduction Implementation Internal CA Management Tool Internal CA High Availability page 135 page 136 page 139 page 146
Introduction
A 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.
135
Implementation
Implementation
In This Section
Requirements Initialization and Configuration PKI and PKCS Recovery and Renewal with OPSEC Certified CA Recovery and Renewal with Entrust CA page 136 page 136 page 137 page 137 page 138
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.
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:
Note - Automatic renewal is available in addition to PKCS#11.
1 2 3 4 5
Open the In the
VPN
tab of the relevant Network Object. field, press

Add...
Certificate List
The
Certificate Properties
window displays.
Enter the Certificate Nickname. The nickname is only an identifier, and has no bearing on the certificate content. Choose the OPSEC Certified CA from which you would like to get the certificate. 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.
Note - Store Keys On Module can be done with SW as well as Hardware.
Click
Generate...
The
Generate Certificate Properties
window appears.
137
Chapter 14
Implementation
7 8 9
Enter the desired Distinguished Name (DN). Please note that the final DN in the certificate is subject to the CA administrator decision. If for some reason the Subject Alternate Name extension should appear in the certificate and contain the DN, check the Define Alternate Name box. 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.
View.
10 Once the Certificate Request is ready, click window appears with the encoding.
The
Certificate Request View
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. Click the In the
VPN
2 3 4 5 6 7
tab of the relevant network object. field, press

Add...
Certificate List
The
Certificate Properties
window displays.
Enter the Certificate Nickname. The nickname is only an identifier, and has no bearing on the certificate content. Choose the Entrust CA from which you would like to get the certificate. The CA object must be previously defined. Click Generate... The Generate Keys and Get Entrust Certificate window appears. Ensure the Generate Mode is set to Initialize. 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 Tool

The 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/
Chapter 14
139
In This Section
Configuration Information Command Line InternalCA.C File Administrator Login Benefits of the Internal CA Management Tool Batch Operations page 140 page 142 page 142 page 143 page 144 page 145
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. 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. 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.
140
Configuration Information
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")
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
Chapter 14
141
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" ... ] Parameter on off -p -no_ssl -a administrator DN -u user DN -d Meaning
Starts the Internal CA Management Tool (opens the 18265 port) Stops the Internal CA Management Tool (closes the 18265 port) Specifies the CA management port; changed by running cpca with the -m option Configures the server to use clear HTTP, rather than HTTPS Sets the DNs of the Administrators Sets the DNs of the users (lower permissions) Turns on debugging 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.
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 2 Initialization: A registration code is created for the user. When this is done, the certificate state is pending. Registration: When the user completes the registration process in the remote client (SecuRemote/SecureClient) using the registration code, the certificate becomes valid.
Chapter 14
143
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,dc=com mail=user_1@company.com uid=user_1 givenName=user_1 objectClass=top objectClass=person objectClass=organizationalPerson objectClass=inetorgperson sn=user cn=User One userPassword={crypt}xxxx/xxxxx creatorsName=cn=directory manager modifiersName=cn=directory manager createTimestamp=20020429143957Z modifyTimestamp=20020429143957Z <blank_line> uid=
Chapter 14
145
Internal CA High Availability
Internal CA High Availability

The 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
C HA PT ER
15
In This Chapter
NAT Traversal for SecureClient Office Mode - IP Assignment from a RADIUS Server for SecureClient Office Mode - DHCP Enhancements for SecureClient Office Mode per site for SecureClient Office Mode per IP Range for SecureClient MSI Package for SecureClient MEP and Interface Resolving Enhancements General Information and Tips page 148 page 157 page 167 page 170 page 172 page 176 page 180 page 189
147
NAT Traversal for SecureClient

Overview
Encapsulation
Until version R56, SecureClients located behind NAT devices used the UDP 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
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
Chapter 15
151
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 2 3 IKE negotiation starts over TCP port 500. In case the TCP handshake fails, the Client tries starting the IKE negotiation again, this time using UDP port 500. 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. 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. In case IKE was performed over UDP: In MM packet 5 and 6 the peers change the port of the packets. 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.
Chapter 15 SecuRemote/SecureClient 153
5 6
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
Chapter 15
155
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
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.
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
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.
Chapter 15
157
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.
Chapter 15
159
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.
Note - Only RADIUS users are authorized to get an OM address from the RADIUS server; others receive the OM address using other methods.
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 2 The Client connects to the Gateway. During the Connect operation, the RADIUS user authenticates himself to the Gateway. In the Authentication stage the RADIUS Server assign an IP address to the Gateway.
Chapter 15
161
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. An IP lease time duration is defined for the assigned OM IP. The Client asks to renew this OM address each x time, according to the configured lease time. 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.
4 5 6
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.
Note - The messages sent to the RADIUS server about locking the address are accounting-start and accounting-stop.
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.
162
Functionality
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.
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
Chapter 15
163
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 objects 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 objects 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 objects 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 servers configuration is taken from here.
Chapter 15
165
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 SecureClient

DHCP 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).
Note - Unlike other features, this feature applies only to SecureClient.
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
Chapter 15
167
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 attributes 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 ipconfig
ipconfig /setclassid "Local Area Connection" <any string>
For example:
ipconfig /setclassid "Local Area Connection" kuku
FIGURE 15-19 Adding classid with ipconfig
Chapter 15
169
Office Mode per site for SecureClient
Office Mode per site for SecureClient

After 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 Clients 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 Configuration
FIGURE 15-20 MEP configuration
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.
OM per site
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.
Chapter 15
171
Office Mode per IP Range for SecureClient

This 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 Managements 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.
Chapter 15
173
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?
Chapter 15
175
MSI Package for SecureClient

Since 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:
Products Versions Remarks
SecureClient 4.1 SecuRemote 4.1 SecureClient NGX SecuRemote NGX SecureClient R56 SecuRemote R56 Compact View R56 SecureClient MSI SecuRemote MSI Compact View MSI
4199 and 4200 NGX, FP1, FP2, FP3, R54, R55 R56
SecureClient performs part of the upgrade process (updating userc.c).
When upgrading from Compact View, the installation automatically upgrades to Compact View; no user intervention is required. Future versions are MSI-based.
NGX and future versions
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 MB Because a major concern is to keep the SecureClient package small, MSI installation has the ability to be divided into smaller packages.
Chapter 15
177
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.
Chapter 15
179
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 SecureClients 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 Gateways 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 Gateways 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 Gateways 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)
Chapter 15
181
Single IP VPN
- 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 Managements 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
- 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)
- receives the OneTimeProb / ongoingProb value
When the probing mechanism is configured, the Client resolves the Gateways 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.
Chapter 15
183
Manually Defined VPN List

Until version R55, RDP packets were sent to all the interfaces defined in the Gateways 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 Gateways 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 Gateways 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 Gateways 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.
Chapter 15
185
Link Selection GUI Configuration Link Selection configuration is done per Gateway. A tab called within the Gateway object properties Topology tab.
FIGURE 15-25 Link Selection tree node Link Selection
resides
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
Chapter 15
187
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 tables 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.
Note - In case this IP is not routable, the Client fails to connect to the Site.
If the
Allocated IP Address
Gateway),
is configured to All IPs (in Visitor Mode Settings per 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.
Chapter 15
189
If the configured resolving mechanism is Probing mechanism, the Client selects the Gateways Main IP as the resolved interface (Dynamic Interface Resolving is not supported in Visitor mode).
Note - If this IP is not routable - the Client fails to connect to the Site.
If Main IP / Single IP is configured, the Client connects to the Gateway according to this IP.
190
Section 4: Additional Products
C HA PT ER
17
SNX
In This Chapter
Application Mode Network Mode page 193 page 199
Application Mode
In This Section
Basic Hooking Debug Logs - Client StaProxy & Sta logs Debug Log - Server Proxy Configuration Connectivity Issues page 194 page 196 page 197 page 197 page 197 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.
Note - SNX Application Mode does not support UDP traffic.
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
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
Control Panel -> System -> Advanced tab -> Environment Variables.
Add the variable in
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.
199
Chapter 17
SNX
Network Mode
TABLE 17-1
Check if you can find the issue in following troubleshooting table:

SNX Network Mode - Troubleshooting Table Resolution
Issue
All user's packets destined directly to the external SSL Network Extender Gateway are not encrypted by the SSL Network Extender. 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.
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.
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
TABLE 17-1
Issue
The SSL Network Extender does not function properly when the following conditions are met: The client computer has
SecuRemote/ SecureClient
To resolve this, disable the overlapping site in 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
Chapter 17
SNX
201
Network Mode
TABLE 17-1
Issue
The SSL Network Extender does not function properly when the following conditions are met: The client computer has
SecuRemote/ SecureClient
To resolve this, verify that the flag

allow_clear_traffic_while_disconnected
is set to true
(the default value).
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 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.
Other possibilities are to activate debugging on either client or server, and examine the relevant log files.
202
Server side
vpn 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\paramet ers\dbg_level to 5 net 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 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.
restart) 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
C HA PT ER
18
InterSpect
In This Chapter
Introduction Latest features Memory Management Troubleshooting Kernel Debugging Fail Open NICs Performance and Acceleration Policy Troubleshooting Cooperative Enforcement Known Issues page 206 page 207 page 209 page 210 page 212 page 214 page 219 page 221 page 223
205
Introduction
Introduction
InterSpect 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
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.
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
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 pstat Hash kernel memory (hmem) statistics: Total memory allocated: 10485760 bytes in 2558 4KB blocks using 2 pools Initial memory allocated: 6291456 bytes (Hash memory extended by 4194304 bytes) Memory allocation limit: 42991616 bytes using 10 pools Total memory bytes used: 135328 unused: 10350432 (98.71%) peak: 160616 Total memory blocks used: 55 unused: 2503 (97%) peak: 63 Allocations: 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: 16115540 Blocking memory bytes used: 153552 peak: 167956 Non-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.
Chapter 18
InterSpect
209
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: 7287680 Allocations: 111424 alloc, 0 failed alloc, 108689 free, 0 failed free External Allocations: 0 for packets, 0 for SXL Memory used for internal structures: 10940 bytes Total 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 Debugging
The 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.
#fw ctl debug 0 #fw ctl debug -buf 8150 #fw ctl debug -m fw tcpstr cifs drop #fw ctl kdebug -f >& filename.ctl &
A kernel debug example:
To reset all kernel debug values, run:

# fw ctl debug 0
Chapter 18
InterSpect
211
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 NICs

InterSpect 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
Usage
failopen [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 print Task: "RotateLogs" Command: /sbin/cp_logrotate Arguments: Interval: 100 Active: true RunAtStart: true Task: "BypassWD" Command: /bin/failopen bypass_wd_refresh Arguments: Interval: 8 Active: true RunAtStart: true Task: "Sim_Affinity" Command: sim Arguments: affinity -c Interval: 60 Active: true RunAtStart: 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.
Chapter 18
InterSpect
213
Performance and Acceleration

Performance is measured in several aspects: Packet Rate - How many packets InterSpect can forward per second Throughput - How many bits per second InterSpect can forward
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.
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.
214
Acceleration Basic Functionality
To display acceleration statistics, use fwaccel stats, for example:

# fwaccel Name conns created temporary conns nat conns accel bytes ESP enc pkts ESP dec pkts ESP other err espudp enc err espudp dec err AH enc pkts AH dec pkts AH other err free memory current total conns conns from templates delayed TCP conns delayed nonTCP conns F2F bytes enc bytes pattern match
stats:
Value 823585 801365 235 4215685421 0 0 0 0 0 0 0 0 0 256 765239 9 0 1074122 0 0 Name conns deleted templates accel packets F2F packets ESP enc err ESP dec err espudp enc pkts espudp dec pkts espudp other err AH enc err AH dec err memory used acct update interval TCP violations TCP conns non TCP conns F2F conns crypt conns dec bytes dropped pkts Value 325745 26584 658521365 17196 0 0 0 0 0 0 0 0 30 0 196 190 0 0 0 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.
To display the acceleration status:

# fwaccel stat Accelerator Status: on Templates: enabled Accelerator Features: Accounting, NAT, Cryptography, Routing, HasClock, Templates, Synchronous, IdleDetection, Sequencing, TcpStateDetect, AutoExpire, DelayedNotif, TcpStateDetectV2, CPLS, WireMode
Chapter 18
InterSpect
215
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 Source 10.10.10.1 SPort * Destination 20.20.20.2 DPort 23 PR 6 Flags ..... LCT 3 DLY 60 C2S i/f eth1 /eth2 S2C i/f eth2 /eth1
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
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/conf Active : Forward Packets : Installed Inbound : Installed Outbound : Random Initialized : Vlan Support : Bridge hook used : yes yes yes Attached in inbound direction yes Attached in inbound direction yes Crypto random buffer yes yes : : : : : : : : : : : : 0x00000816 Configuration flags 30 512 0 0 20 599800 0 512 300 0 0 2 Counters 2 0 1 1 0 0
Flags Accounting Update Interval Conn Refresh Interval SA Sync Notification Interval UDP Encapsulation Port TCP Auto-Expire Timeout Connection Limit TmplQuota Enabled TmplQuota Quota (rate) TmplQuota Drop Dduration TmplQuota Monitor only TmplQuota Dropped pkts
Total Number of conns : Number of F2F conns : Number of Crypt conns : Number of TCP conns : Number of Non-TCP conns : Number of Delayed TCP conns : Number of Delayed Non-TCP conns:
Chapter 18
InterSpect
217
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.
Chapter 18
InterSpect
219
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 Enforcement
The 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 2 3 4 In the Integrity Server Web UI, go to
System Configuration > Certificate.
In the list of Integrity certificates, locate InterSpect certificate by its DN. Delete the InterSpect certificate. 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.
Chapter 18
InterSpect
221
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.elg
Note 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 Issues
Enabling 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. 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=s olution&id=sk31471
Chapter 18
InterSpect
223
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.
https://secureknowledge.checkpoint.com/SecureKnowledge/login.do?OriginalAction=s olution&id=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) available for all NICS
Tcpdump:
# tcpdump -i eth0 # tcpdump -i br0
224
C HA PT ER
19
Connectra
In This Chapter
Debug Information Using the TraceLogger page 226 page 229
225
Debug Information
Debug Information
To access the debug output files: 1 2 3 Type: >echo admin > /etc/scpusers. Use either pscp or WinSCP to connect your desktop to Connectra using administrator credentials. 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 Apache debugging processes Debugging the Portal Debugging File Shares page 226 page 227 page 228 page 228
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.
226
Apache debugging processes
Apache debugging processes

Activating httpd debug output 1 2 Edit: $CVPNDIR/conf/httpd.conf. 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. Type cvpnrestart to restart Apache with the new debug settings.
The debug output appears in $CVPNDIR/log/httpd.log. Canceling httpd debug output 1 2 Change the line described in step 2 above back to emerg. Type: >cvpnrestart.
Activating packet dumps in the Apache debug output file 1 2 3 Set the debug level described in step 2 above to debug. Type: >setenv LOGHEXDUMP 1. Type: >cprestart.
Note - Make sure not to type cvpnrestart.
Disabling packet dumps 1 2 Type: >unsetenv LOGHEXDUMP. Type: >cprestart.

Note - Make sure not to type cvpnrestart.
Chapter 19
Connectra
227
Debug Information
Debugging the Portal

Debugging the servers 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. Type: >cvpnrestart.
Note - Make sure not to type cprestart.
Debugging the client-sides JavaScript code Execute one of the following instructions: In Internet Explorer, set the Tools > Options > Advanced > every script error option. Use Mozillas JavaScript console.
display a notification about
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 2 3 Backup the original soft link >mv $CVPNDIR/bin/Mount $CVPNDIR/bin/MountLast. Make a new link pointing to the SMB implementation >ln -s $CVPNDIR/bin/MountSmb $CVPNDIR/bin/Mount. Type: >cvpnrestart.
228
Debugging Web Intelligence
Using the TraceLogger

The 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 2 Edit: $CVPNDIR/conf/httpd.conf Remove the comments from the lines beginning with:
LoadModule trace_logger
and
CvpnTraceLogMaxByte
Type: >cvpnrestart.
The debug output appears in the $CVPNDIR/log/trace_log/ directory. Disabling the TraceLogger 1 2 Change the line described in step 2 above, back to a comment. Type: >cvpnrestart.
Debugging Web Intelligence

Activating Web Intelligence debug output 1 2 3 4 Edit: $CVPNDIR/conf/httpd.conf. Copy the line beginning with: #CvpnWsDebugSubjects. Uncomment one of the copies, and remove all irrelevant debug subjects. Type: >cvpnrestart.
The debug output appears in $CVPNDIR/log/mod_ws.log, and in $CVPNDIR/log/mod_ws_boa.log. Disabling Web Intelligence debug output 1 2 Change the line described in step 3 above back to a comment. Type: >cvpnrestart.
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
C HA PT ER
20
Eventia Reporter
In This Chapter
Introduction Eventia Reporter Architecture Licensing Eventia Reporter Debugging Eventia Reporter Known Limitations Common Questions/Issues page 231 page 232 page 234 page 235 page 243 page 244
Introduction
The 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.
231
Eventia Reporter Architecture
Eventia Reporter Architecture

This 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 Data Retrieval Eventia Reporter Client Components Eventia Reporter Server Components page 232 page 232 page 232 page 233
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.
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.
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.
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 Reporter

Licenses 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.
Note - Additional licenses should be purchased according to the number of cluster members.
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
234
Introduction
Debugging Eventia Reporter

In This Section
Introduction Log Consolidator SVRServer My SQL Log Consolidator Commands SVRServer Commands DBTableStat GeneratorApp page 235 page 235 page 237 page 237 page 238 page 240 page 241 page 241
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 support@ts.checkpoint.com.
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.
Chapter 20
Eventia Reporter
235
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
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.
= run the consolidator ServerIP = IP address of the Log Server Yes = exit after stopping Specified_Log = read the specific file xyz.log = the specific file to be read is $FWDIR/log/xyz.log 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:
-R -s -x -t -l -a
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
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.
Note - Generator errors are also added to the same log file.
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.
Chapter 20
Eventia Reporter
237
Log Consolidator Commands

To get more information regarding the Log Consolidator, run the following commands from command line.
Note - All the following commands can be also retrieved from Eventia Reporter.
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 LogServerIP and PV1Customer. -m
Log Consolidator session as specified by
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. the IP address of the Log Server to read logs from.
-s -g
(optional) the name of the Provider-1 customer for which the current session is running.
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.

Note - This command might help troubleshooting when there are problems with connectivity to the Log Server.
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 -s -g
Run the Log Consolidator Engine process for a specific consolidation session. The log Server IP address for reading logs. (optional) The name of the Provider-1 customer for which this session is running. - The IP address of the Log Server to read logs from. - Name of log file.
<Log_Server_IP> <File_Name.log> <TABLE_NAME>
- name of database table in which log file information is stored.
Note - Invoke this command only for external files - files that are not listed in .logtrack anymore.
log_consolidator
is located in the directory $RTDIR/log_consolidator/bin.
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 get a consolidation session's status information

Usage log_consolidator -M -s LogServerIP [-g PV1Customer] [-r log_consolidator Port]
Chapter 20
Eventia Reporter
239
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 Generators 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 = start/stop the Reporter Server
-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 -o
specify database table name, default: CONNECTIONS 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 ReportID
- The result directory (that is, the location at which the result is placed).
- 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>
Chapter 20
Eventia Reporter
241
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 -p
specifies the Perl interpreter location 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.
Chapter 20
Eventia Reporter
243
Common Questions/Issues
Issue: 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 Reporters 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-17 RepDBManagr 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.
Chapter 20
Eventia Reporter
245
Settings.
The DNS resolution can be turned off through the Management tab > Consolidation Set the source and destination to have only Object Database instead of Object database and DNS.
Note - You need to stop the consolidation session first.
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.
246
GeneratorApp
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.
Note - SmartView Monitor must be installed on the module in order to generate a Network Activity report.
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 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?
Duration
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 - By default, the report only has *reason: connected to gateway*, which gives only the SecureClient login.
Chapter 20
Eventia Reporter
247
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
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 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
C HA PT ER
21
Eventia Analyzer
In This Chapter:
Login db_sync Analyzer server Correlation unit syslog page 249 page 250 page 250 page 251 page 252
Login
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 Servers address and not Smart Centers.
249
db_sync
db_sync
No objects are seen in the Network Objects window A particular object is not seen in the Network Objects window
might have not begun

db_sync db_sync
Run cpstop and cpstart on the Analyzer Server. 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
might not have completed
objects. More detailed debugging is required

CPMI,
Issues due to SIC, or dbsync
Turn on TDERROR from the command line:

cpwd_admin stop -name CPSEMD export TDERROR_ALL_DBSYNC=5 export TDERROR_ALL_CPMIDBCLIENT=5 export OPSEC_DEBUG_LEVEL=3 cpsemd
Output is located in:
$FWDIR/log/cpsemd.elg
Analyzer server
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 unit
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 has the following default settings for lea_server:
$FWDIR/conf/fwopsec.conf
If 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:
cpstop cpstart
# lea_server auth_port 18184 # lea_server port 0
The Overview pane reports that the Correlation Unit cannot read logs from the log server. The Overview pane reports that the Correlation Unit cannot read logs from the log server.
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 Add a rule to allow LEA R60; R60a did not allow communication originating from the LEA communication Correlation Unit to the Log Server between the Correlation Unit and the Log Server.
Chapter 21
Eventia Analyzer
251
syslog
Problem
Reason for failure
Resolution
The Overview pane reports that the Correlation Unit cannot read logs from the log server.
General LEA debugging Activate LEA debugging from the log server:
fw debug fwd on OPSEC_DEBUG_LEVEL=3 $FWDIR/log/fwd.elg/ fw debug fwd off
Attempt the connection and look in:
syslog
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. 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.
syslogs can be seen in the The syslogs might have Log Tracker, but they are been sent to a standard not parsed Check Point log server, rather than the Eventia log server that includes the advanced Free Text Parser policy.
The syslog daemon is not running
The syslog daemon is not set in SmartDashboard
Enable the accept syslog messages in the Eventia objects 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
Problem
Reason for failure
Resolution
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 1. Remove the Correlation Unit correlation unit as well, definition for the syslog object in the Eventia Analyzer Client. the Analyzer server holds a private copy of 2. Modify the definition of the object in SmartDashboard by disabling the the correlation unit, so it accept syslog messages property and cannot see the saving the object. Then enable it synchronized updates. again and save the object. 3. Run cpstop and cpstart. 4. Reset the Correlation Unit definition. is set for the Analyzer Server/Correlation Unit that $FWDIR/conf/sem_ reads syslogs. Then run cpstop and network_objects.C, the cpstart. Analyzer is restarted
Enable_SyslogD (true)
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. Messages are not parsed by the log server. The syslog contents are all in the field
Only after the syslog daemon is synchronized and updated in
Verify that the property
The machine that runs the syslog daemon might not have the files necessary to parse the default_device_message, syslog messages. This but no expected fields is particularly true in (source, dest) are populated 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,
The definition files are Save a copy of the log file and open a not defined correctly by problem ticket. the customer for the particular configuration.
but no expected fields (source, dest) are populated 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
C HA PT ER
23
Licensing
In This Chapter
Introduction - the license_upgrade tool clic Debugging License Commands on Windows Debug License Commands on Unix/Linux License Upgrade Tool page 257 page 258 page 258 page 259 page 260
Note - The descriptions in this chapter are relevant to upgrade procedures only.
Introduction - the license_upgrade tool

The 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.
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.
clic
A 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 Windows

1 2 Open two command windows in Windows. In both windows, set the following variables:
set OPSEC_DEBUG_LEVEL=9 set TDERROR_ALL_ALL=5
3 4 5
If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start it (cpstart), and then kill fwm. On one of the shell windows, run the following:
Fwm m -d 2>fwm_debug.txt
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. 6 Stop the fwm -d command by typing CTRL+C. This kills the fwm process, so it needs to be restarted.
258
Debug License Commands on Unix/Linux

1 2 Open the shell console. Set the following variables:
setenv OPSEC_DEBUG_LEVEL=9 setenv TDERROR_ALL_ALL=5
3 4 5
If the Firewall is active, kill the fwm process (fw kill fwm); if the Firewall is inactive, start it (cpstart), and then kill fwm. On one of the shell windows, run the following:
Fwm m -d 2>fwm_debug.txt
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. 6 Stop the fwm -d command by typing CTRL+C. This kills the fwm process, so it needs to be restarted.
Chapter 23
Licensing
259
License Upgrade Tool

1 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> 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: 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.
license_upgrade.exe %* echo %errorlevel%
Return code values

Return code LDT_OK LDT_ERROR LDT_ERR_MALLOC LDT_BAD_ARGS LDT_INCORRECT_USER_PASSWORD LDT_COULD_NOT_RESOLVE_HOST LDT_COULD_NOT_CONNECT LDT_HTTP_RETURNED_ERROR Value Description
0 2 3 4 5 7 8 9
Operation status is OK General error Could not allocate memory Function received invalid/bad arguments Incorrect user name for operation Could not resolve host Connect failed If server returned error code >= 400
260
Return code values
Return code LDT_LOCAL_CERT_PROBLEM LDT_SSL_PEER_CERTIFICATE LDT_FILE_NOT_FOUND LDT_LOCKED LDT_BAD_SIG LDT_INVALID_REQ LDT_PARTIAL_VALID LDT_NOT_VALID LDT_EMPTY_VALID LDT_COULD_NOT_GET_DATA LDT_NO_LOCAL_LICS LDT_TIMEOUT LDT_CPRLIC_ERR LDT_CPRLIC_CONN_ERR LDT_CPRLIC_ATTCH LDT_TEST_FULL LDT_TEST_ERROR LDT_TEST_NONE LDT_TEST_PART LDT_TEST_EMPTY LDT_FTCH_NONE LDT_FTCH_PART LDT_FTCH_EMPTY LDT_DEL_EXP_NONE LDT_DEL_EXP_PART
Value
Description
10 11 12 15 17 18 19 20 21 23 24 25 26 27 28 30 31 32 34 35 42 44 45 46 47
Problem with local certificate The remote server's certificate is illegal Could not find file on data object FDT is locked by on-going transfer Does not match expected CPSignature Invalid request business fault Part of the licenses are valid None of the licenses are valid No licenses simulate Could not get data None of the licenses correspond to the local host Operation has timed out Problem executing cprlic connection failure while executing cprlic Still needs to attach licenses All source licenses where replaced General error None of the source licenses where replaced Part of the source licenses where replaced No licenses at all None of the licenses where fetched Part of the licenses where fetched No licenses at all to fetch None of the expired licenses were deleted Part of the expired licenses were deleted
Chapter 23
Licensing
261
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).
Note - The cache file accumulates good results only.
$CPDIR/log/license_upgrade.log
- contains logs of the last action performed by
the tool.
Note - File is not accumulative; it contains a log of the last action only!
- as a result of the status check made by the tool, this file logs the current status of the licenses on the machine.
$CPDIR/log/license_upgrade_status.log
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.
262
Index
C
clic 258 cprlic 41, 258
H
H.323 126 High Availability CCP 112 ClusterXL 102 fw module 7 ICA 146 hooking 194
NAT Traversal 149 Main Mode Flow 151 solution 149 Network Address Translation (NAT) 71 Nortel 34
D
debugging firewall NGX 5 VPN-1 Pro 17, 19
O
objects_5_0.C 48 Open Security Extension (OSE) 33
I
IKEView 155
F
failover ClusterXL 102, 103 Eventia Reported 243 FTP connection 73 FTP Security Server 7, 98 fw monitor 21 buffering 25 NAT 73 SecureRemote 159 Security Servers 86 SNX Network Mode 199 VoIP 128 Web Intelligence 57 fwd debugging 5
Q
Quick UFP 82
L
Legacy 153 licensing, commands debugging 41 Lightweight Directory Access Protocol (LDAP) 61
R
routers, Cisco 36 routers, Nortel 34
M
MAC address 111 Mail Dequeuer (MDQ) 90 MDQ 97 MGCP 126
S
SCCP 126 Secure Internal Communications (SIC) 27 Security Servers debugging 6 SIC troubleshooting 27 SIP 126 SMTP debugging security issues 96 improvements 92 Security Servers 90 Troubleshooting Security Servers 94
G
Gateway connection Legacy 153 Standard 153 Visitor Mode 153
N
NAT 4 rules 39 Secutiry Server 79 SIC 29 Traversal for SecureClient 148 VoIP 128
263
T
TCP Resource 80 TFTP 38
U
UFP 82
264

Atrg NGX

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Atrg NGX

Hochgeladen von

Copyright:

Verfügbare Formate

Advanced Technical Reference Guide

May 11, 2006

2003-2006 Check Point Software Technologies Ltd.

Check Point Software Technologies Ltd.

Section 1: SmartCenter Chapter 1 Debugging and Monitoring

Secure Internal Communications

Open Security Extension

LDAP Servers and SmartDirectory

Section 2: VPN-1 Pro/Express Chapter 9 Network Address Translation

Table of Contents iii

Voice Over IP (VoIP)

Section 4: Additional Products Chapter 17 SNX

Section 5: Licensing Chapter 23 Licensing

Table of Contents vii

Who Should use this Guide

Debugging and Monitoring

Debugging fwd and fwm

Debugging Firewall NGX

Debugging fwd and fwm

To stop writing debug information:

Debugging and Monitoring

Debugging Firewall NGX

To stop writing debug information:

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

Debugging Security Servers

Debugging Kernel Modules Using fw ctl debug

To stop writing debug information for FTP security server:

To stop writing debug information:

Debugging Kernel Modules Using fw ctl debug

Debugging Firewall NGX

Debugging Kernel Modules Using fw ctl debug

FW CTL debug options

Assign the debug option memory for the Firewall module:

Windows in the 4NT shell and UNIX:

Disable/clear all debug options:

Clean kernel debug buffer:

Debugging and Monitoring

Debugging Firewall NGX

Start writing debug information to file_name:

Clean kernel debug buffer:

To remove the second option for the module (-m) fw:

fw module Debug Options

fw module Debug Options

install and uninstall

Debugging and Monitoring

Debugging Firewall NGX

Option Chain Bridge Tcpstr Scv

vpn Debug Options

fg (QoS) Debug Options

fg (QoS) Debug Options

Debugging and Monitoring

Debugging Firewall NGX

uag (User Authority) Debug Options

rtm (SmartView Monitor) Debug Options

Ioctl Import Special Rtm

strmod Debug Options

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

strmod Debug Options

Debugging and Monitoring

Debugging Firewall NGX

To disable the CPD debug, issue:

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

Debugging VPN-1 Pro