Checkpoint R77 vsx  course
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Checkpoint R77 vsx course

on

  • 1,546 views

 

Statistics

Views

Total Views
1,546
Views on SlideShare
1,546
Embed Views
0

Actions

Likes
4
Downloads
195
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Checkpoint R77 vsx course Presentation Transcript

  • 1. ©2014 Check Point Software Technologies Ltd. | R77 VSX Course
  • 2. 22©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77VSX Introduction vsx_utill Gaia VS CTX & New Features (SNMP, Jumbo Frames)11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 3. ©2014 Check Point Software Technologies Ltd. | R77 Introduction
  • 4. 44©2014 Check Point Software Technologies Ltd. | | Agenda What is VSX and why should I consider it? VSX introduction How to integrate a VSX infrastructure into my enterprise network? VSX Virtual Devices Is management of a VSX infrastructure complex? VSX Management Is my VSX infrastructure robust, scalable and fast? VSX Clustering What’s new in Gizmo Gizmo vs R67 What is a User Space VSX? VSX Gizmo
  • 5. 55©2014 Check Point Software Technologies Ltd. | | Why Virtualization? Hardware Cost Savings Simplified Security Management Simplified Security Provisioning Better availability and scalability
  • 6. 66©2014 Check Point Software Technologies Ltd. | | VSX – Virtual System Extension  A VSX is a Gateway running several separate firewalls each protecting a different network (customer).  A VSX is a Gateway with the ability to virtualize physical network components into one physical gateway. What is VSX
  • 7. 77©2014 Check Point Software Technologies Ltd. | | What do we Virtualize?  Networking (IP, Routing table, IP stack)  INSPECT filter (and tables)  Kernel tables  Configuration (global) parameters  Policy (rules, anti-spoofing, etc.)  SIC entities  File handling  CP Registry  And more…
  • 8. 88©2014 Check Point Software Technologies Ltd. | | Virtual Routing and Firewalling  VSX establishes a Virtual Network Environment consists of multiple virtual devices Virtual System (VS) Firewall Module Virtual System In Bridge Mode IP Router Virtual Cable (warp link) Network Cable Firewall Module In Bridge Mode Virtual Router (VR) SwitchVirtual Switch (V-SW)
  • 9. 99©2014 Check Point Software Technologies Ltd. | | Virtual Devices  Virtualizing Check Point’s Firewall  Each Virtual System is a unique routing and security domain  Each Virtual System has its own separate FW properties. Virtual System (VS)
  • 10. 1010©2014 Check Point Software Technologies Ltd. | | Virtual System (VS) Each VS functions as a stand-alone, independent FW gateway Interfaces list IP Addresses Routing table ARP table Dynamic Routing Configuration Etc. Interfaces list IP Addresses Routing table ARP table Dynamic Routing Configuration Etc. State Table Security & VPN Policies Configuration Parameters Logging Configuration State Table Security & VPN Policies Configuration Parameters Logging Configuration FW VPN SSL VPN AUTH (Client & Session) Layer 3 Layer 2 Dynamic Routing Secure XL Cluster XL VSX virtual devices: Firewall objects Virtual System
  • 11. 1111©2014 Check Point Software Technologies Ltd. | | Layer 2 Virtual Devices  Firewall capabilities of a Virtual System, Except NAT &VPN  Easier configuration of Virtual Systems.  Does not segment an existing network.  Needs anti-spoofing to be manually defined. Virtual System in Bridge Mode (VSB)
  • 12. 1212©2014 Check Point Software Technologies Ltd. | | Layer 2 Virtual Devices  L-2 connectivity between Virtual Systems, and to a shared interface.  Maintains a forwarding table with a list of MAC addresses and their associated ports.  Simplifies configuration of connected Virtual Systems. Virtual Switch (VSW)
  • 13. 1313©2014 Check Point Software Technologies Ltd. | | Virtual Devices  independent routing domains within a VSX Gateway  Designed to route traffic between interfaces connected to it.  Protects itself from traffic directed to or originating from it.  All other packets are forwarded according to the route table entries. Virtual Router (VR)
  • 14. 1414©2014 Check Point Software Technologies Ltd. | | warp Interfaces  Regular Interfaces  Physical interfaces  Virtual interfaces - VLANS  VSX Gateway introduces a new type of interfaces  warp links – interface between component of the VSX gateway Eth0 (VLAN Trunk interface) Eth0.100Eth0.101 Eth1 (physical interface) Wrp Interface
  • 15. 1717©2014 Check Point Software Technologies Ltd. | | Example: Physical Network Layout Internet
  • 16. 1818©2014 Check Point Software Technologies Ltd. | | Example: VSX Deployment Internet VS X Switch VSX
  • 17. 1919©2014 Check Point Software Technologies Ltd. | | VSX management 3-tier management architecture with either SmartCenter or Provider-1 CLI Management: vsx_util # vsx_util vsls # vsx_util redistribute_vsls # vsx_util reconfigure # vsx_util add_member SMART Consoles SmartCenter Provider-1 VSX Gateways
  • 18. 2020©2014 Check Point Software Technologies Ltd. | | VSX management Provider-1 focus Main DMS manages the VSX infrastructure Target DMSs manage one or more Virtual Devices Multiple concurrent administrators Granular permissions Separate object databases
  • 19. 2121©2014 Check Point Software Technologies Ltd. | | VSX - What’s New in R76-R77 1. VSX Merged to Maintain 2. Supports most software blades 3. Runs on Gaia 4. VSs Infrastructure Segregation 5. User Mode FW (FWK) 6. High performance and capacity (64bit & CoreXL) 7. Support Jumbo Frames 8. Dynamic routing (routed) 9. Source based routing 10. SNMP per VS 11. Improved CPU and memory monitoring (per VS) 12. Conversion between GW and VS 13. OSU – zero downtime upgrade 14. IPv6 support was added (New in R76 vs R75.40VS)
  • 20. 2222©2014 Check Point Software Technologies Ltd. | | VSX - What’s New in R77.10 • Gaia OS improved with resolved issues. • Mobile Access support for IPv6, VSX • Integrated Appliance Hardware Diagnostic Tool. • QoS support for SecureXL and CoreXL is included and disabled by default. • Routing stability fixes and enhancements. • Acceleration enhancements. • VPN enhancements.
  • 21. 2323©2014 Check Point Software Technologies Ltd. | | Software Blades R77 supports Software Blade Architecture on every Virtual System  Supporting Software Blades including Firewall, VPN, Intrusion Prevention (IPS), Identity Awareness, Application Control, URL Filtering, *Anti-virus and Anti-bot.  Administrators have the flexibility to configure any Software Blades with any security policy to any Virtual System. * Anti-virus and Anti-bot – will be added in the near future.
  • 22. 2424©2014 Check Point Software Technologies Ltd. | | Virtualization and segregation R67 R77 Resilience Kernel panic effects all VSs, and takes minutes to recover An FWK dying effects one VS, and takes seconds to recover. Segregation All memory shared between VSs and instances. A bug on one VS can cause a memory corruption on another VS. Separate address spaces for each FWK. Excellent segregation. CPU monitoring per VS. Resource Control. Not completely accurate (due to wasted lock time), and not standard. Standard OS tools (top). RAM monitoring per VS. Currently no method. Will require a lot of code changes. Standard OS tools (ps) RAM limiting per VS Not possible. Will require exact accounting of consumption per VS. Can be easily done. Changing of CP global kernel parameters Not possible today on a per VS basis. Global parameters shared for all VSs. Can be easily done, per VS.
  • 23. 2525©2014 Check Point Software Technologies Ltd. | | VSX (R67) architecture NIC Fw kernel virtualized Ppack virtualized NIC fwd cpd cplogd VPN kernel virtualized Trap example – logs From fw kernel to cplogd Ioctls ex. – policy install From cpd to fw kernel UM KM vpnd vpnd vpnd 1. All kernel code had “inside virtualization” • Tables per VS • Parameters per VS or global 2. Most of the UM processes were virtualized (fwd/cpd/cplogd) 3. Some were per VS (vpnd)
  • 24. 2626©2014 Check Point Software Technologies Ltd. | | R77 VSX architecture NIC Ppack virtualized NIC UM KM Firewall dispatcher 1. Fwk is the fw’s kernel code compiled to a dll 2. PPK remains virtualized 3. I/S to simulate traps and ioctls, over TCP between fwd/cpd and fwk - fwasync_rpc VS fwd cpd vpnd fwk VS fwd cpd vpnd fwk VS fwd cpd vpnd fwk Ioctls ex. – policy install From cpd to fwk Trap example – logs From fwk to fwd
  • 25. 2727©2014 Check Point Software Technologies Ltd. | | CoreXL per VS - 1  You can use CoreXL to increase the performance of the VSX Gateway. You can also assign each instance to a specific CPU core using fw ctl affinity command.  You can configure multiple instances for each of the Virtual Systems  Each firewall instance that you create uses additional system memory.  Downside, a Virtual System with five instances would use approximately the same amount of memory as five separate Virtual Systems.
  • 26. 2828©2014 Check Point Software Technologies Ltd. | | CoreXL per VS - 2  Firewall instances are configured differently on VSX Gateway (VS0), and on Virtual Systems.  VSX Gateway - Use the CLI to configure the number of instances.  Other Virtual Systems - Use SmartDashboard to configure the number of instances.
  • 27. 2929©2014 Check Point Software Technologies Ltd. | | Jumbo Frames Support  VSX in R77supports Jumbo Frames, up to 9,000 MTU on virtual devices: 1. Virtual System 2. Virtual Switch 3. Virtual Router 4. Virtual System in Bridge Mode  Configuring the MTU on Bond interfaces  Configuring the MTU on Warp interfaces  Configuring the MTU on VLAN’s interfaces
  • 28. 3030©2014 Check Point Software Technologies Ltd. | | SNMP per VS  There are two modes of SNMP monitoring that you can use with VSX : • Default mode - only monitors VS0 • VS mode - supports SNMP monitoring per VS  The per-VS monitoring such as : - Interface state and statistics - Policy name - Policy date
  • 29. 3131©2014 Check Point Software Technologies Ltd. | | Memory Resource control overview Memory Resource control (“fw vsx mstat”) gives the user overview information about:  Memory consumption of the system  Memory consumption per virtual device
  • 30. 3232©2014 Check Point Software Technologies Ltd. | | VSX Memory Resource Control Examples  fw vsx mstat unit B -vs 2-7 sort 3 VSX Memory Status ================= Memory Total: 1045659648 Bytes Memory Free: 242528256 Bytes Swap Total: 2146787328 Bytes Swap Free: 2146607104 Bytes Swap-in rate: 0 Bytes VSID | Memory Consumption ======+==================== 3 | 45741252 Bytes 2 | 44537028 Bytes 6 | 44360900 Bytes  fw vsx mstat debug VSX Memory Status ================= Memory Total: 1021152.00 KB Memory Free: 235680.00 KB Swap Total: 2096472.00 KB Swap Free: 2096296.00 KB Swap-in rate: 0.47 KB VSID | Private_Clean | Private_Dirty | DispatcherGConn | DispatcherHTab | SecureXL ======+====================+====================+====================+====================+==================== 0 | 13336.00 KB | 121856.00 KB | 0.00 KB | 0.00 KB | 2850.00 KB 1 | 968.00 KB | 39724.00 KB | 0.00 KB | 0.00 KB | 2833.54 KB 2 | 968.00 KB | 39692.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 3 | 777.00 KB | 41060.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 4 | 968.00 KB | 39512.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 5 | 777.00 KB | 39600.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 6 | 977.00 KB | 39512.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 7 | 784.00 KB | 39516.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB 8 | 3008.00 KB | 88592.00 KB | 0.00 KB | 0.00 KB | 2833.19 KB
  • 31. 3333©2014 Check Point Software Technologies Ltd. | | VSX CLISH commands  Several new commands were introduced in R75.40VS such as switching context, assign resources to specific VSs, and more : >set virtual-system <vsid> >add rba role adminRole virtual-system-access 1…  All commands related to interfaces or routes configuration are disabled in CLISH – along with everything else controlled from Smart Dashboard
  • 32. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 1
  • 33. ©2014 Check Point Software Technologies Ltd. | VSX R77 Networking
  • 34. 3636©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity &Memory RC Debug & Troubleshooting 17:00
  • 35. 3737©2014 Check Point Software Technologies Ltd. | | VSX features  Overlapping IP space support  Inter-VS Routing  Unnumbered Interfaces  Routes Propagation  NAT in VSX  Source-Based Routing
  • 36. 3838©2014 Check Point Software Technologies Ltd. | | Overlapping IP space support  Each Virtual Device Provides end to end separation of Network and Security Infrastructure.  VSX supports protected networks with overlapping IP spaces.  VSX facilitates connectivity of overlapping IP spaces. Customer D 10.10.10.0/24 Internet Customer A 10.10.10.0/24 MPLS Core Customer B 10.10.10.0/24 Customer C 10.10.10.0/24
  • 37. 3939©2014 Check Point Software Technologies Ltd. | | Inter-VS Routing  Both Web and Application Servers require services from the Database servers. – Each service requires different security handling.  Each VS handles the specific security requirements of the segment.  Virtual Switches and Routers facilitate inter VS connectivity. 802.1q 802.1q Virtual Switch Virtual Router Application Servers Database Servers Web Servers
  • 38. 4040©2014 Check Point Software Technologies Ltd. | | Unnumbered interfaces Unnumbered interfaces – In order to reduce the number of IPs used in a VSX configuration, a Virtual System, when connected to a Virtual Router, can use the same IP for multiple interfaces. 192.168.1.1 The external VS interface’s IP acts as a next hop for the VR 200.128.4.1192.150.2.1172.169.1.1 Warp Links P-T-P connections Internal Interface 172.169.1.1 192.150.2.1 200.128.4.1 Unnumbered interfaces borrow an IP address from one of the VS’s interfaces 192.168.1.1 Reducing the system’s overall IP addresses
  • 39. 4141©2014 Check Point Software Technologies Ltd. | | Unnumbered Interface Limitations Limitations The following limitations apply to Unnumbered Interfaces:  Unnumbered interfaces must connect to a Virtual Router.  You can only "borrow" an individual interface IP address once.  In order to use VPN or Hide NAT, the borrowed address must be routable.
  • 40. 4242©2014 Check Point Software Technologies Ltd. | | Virtual Switch Virtual Router  NOT Dynamic Routing  Routes can be propagated to adjacent Virtual Devices.  update Virtual Devices routing tables with minimal effort.  Requires the VS to be connected to VR or VSW Routes Propagation
  • 41. 4343©2014 Check Point Software Technologies Ltd. | | Propagating routes to Virtual Router  If a Virtual System is connected to a Virtual Router, the routes are propagated from the VS to the VR in the following way: Propagated route on the VR: Destination: SUBNET Next Hop: GW Destination: SUBNET Next Hop: wrpj interface connecting VR to the VS Route on the VS:
  • 42. 4444©2014 Check Point Software Technologies Ltd. | | Propagating routes through Virtual Switch  If several Virtual Systems are connected to a Virtual Switch, the routes are propagated from one VS to the other VSs in the following way: Original route on the VS: Propagated route on other VSs: Destination: SUBNET Next Hop: GW Destination: SUBNET Next Hop: IP of wrp interface connecting the propagator VS to the VSW.
  • 43. 4545©2014 Check Point Software Technologies Ltd. | | Propagating manual route Propagating automatic route Routes Propagation Simple & Easy configuration through the Interface properties of the VS
  • 44. 4646©2014 Check Point Software Technologies Ltd. | | Network Address Translation in VSX  Virtual Systems support NAT  Hide  Static  Some configuration required when connected to VR Virtual Router
  • 45. 4747©2014 Check Point Software Technologies Ltd. | | Network Address Translation in VSX  NATed addresses ranges should be defined on a Virtual System in the Topology page > NAT Addresses... dialog.  The ranges are converted to routes and automatically propagated.
  • 46. 4848©2014 Check Point Software Technologies Ltd. | | Network Address Translation in VSX  Virtual System connected to a Virtual Switch.  Same behavior as regular interfaces 192.168.8.9 192.168.8.9 4.0.0.9 4.0.0.9 Virtual Switch 4.0.0.1 4.0.0.2 192.168.8.1 192.168.8.1 192.168.8.9
  • 47. 4949©2014 Check Point Software Technologies Ltd. | | Source-Based Routing  Source-Based Routing: • VSX includes advanced routing capabilities (policy based routing), which enable the definition of source-based routing rules on Virtual Routers. • Advanced routing enables routing according to source IP address or a combination of source and destination IP addresses. • Advanced routing rules take precedence over ordinary routing decisions (both static and dynamic).
  • 48. 5050©2014 Check Point Software Technologies Ltd. | | 192.168.50.4 192.168.35.4 10.1.1.2/24 10.50.50.2/24 10.100.100.2/24 Internet VSX Gateway Source-Based Routing  Useful in cases where no VLAN tagging is used.  Each VS is connected to Internal Virtual Router.  VR forwarding routing based on source IP address. EVR IVR VS1 VS2 VS3 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.3 192.168.1.2 192.168.1.1 192.168.35.1 192.168.50.1 Source-Based Routing
  • 49. 5252©2014 Check Point Software Technologies Ltd. | | Deployment scenarios  Inter-VS connectivity, without an external connection.  Source-based routing with Virtual Switches.  Allowing Customer to manage its security.  Non DMI Replacement.
  • 50. 5353©2014 Check Point Software Technologies Ltd. | | Inter-VS connectivity, without an external connection  Interconnect Virtual Systems  No shared interface  Only allowed with VSW Virtual Switch
  • 51. 5454©2014 Check Point Software Technologies Ltd. | | Source-based routing with Virtual Switches  Another way of using a single physical interface without VLAN tagging to connect to several protected networks is by connecting Virtual Systems using a Virtual Switch.  Source-based routing should be performed by external Router.  The Router uses source-based routing to forward traffic to the relevant Virtual System based on source IP address. 192.168.50.4 192.168.35.4 10.1.1.2/24 10.50.50.2/24 10.100.100.2/24 Internet VSX Gateway VS1 VS2 VS3 192.168.50.1 192.168.50.2 192.168.50.3 192.168.35.3 192.168.35.2 192.168.35.1 Source-Based Routing
  • 52. 5555©2014 Check Point Software Technologies Ltd. | | Allowing Customer to manage its security #1  Customers want to manage their own security policy.  Configure routing on the VS, VSX and on the management.  Set Policy to allow CPMI and FW connections. Management P-1 Virtual Switch Internet VSX Management interface SmartDashboard VS
  • 53. 5656©2014 Check Point Software Technologies Ltd. | | Allowing Customer to manage its security #2  Another solution to the same problem…  The VSW is directly connected to the mgmt network.  Configure routing on the VS and the management server.  Policy changes are required only on the VS. . Virtual Switch Internet VSX SmartDashboard VS Management P-1 Management interface
  • 54. 5757©2014 Check Point Software Technologies Ltd. | | Non DMI Replacement  Check Point recommends no to use Non-DMI deployments  Above is a more elegant solution for this need. Internet VSX Management interface Dedicated Management Interface External Interface Internet VSX Management + External interface Non Dedicated Management Interface
  • 55. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 2,3
  • 56. ©2014 Check Point Software Technologies Ltd. | VSX CoreXL and CPU affinity
  • 57. 6060©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF)11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity &Memory RC Debug & Troubleshooting 17:00
  • 58. 6161©2014 Check Point Software Technologies Ltd. | | CoreXL CoreXL architecture  Parallelise security gateway kernel  Leverage modern processor architectures  Suited to medium path
  • 59. 6262©2014 Check Point Software Technologies Ltd. | | Security Gateway CoreXL  Firewall kernel Replication  Firewall kernel is replicated multiple times. Each runs on one processing core.  Each instance is independent FW-1 kernel.  Instances can run concurrently – don’t share a global lock.  Dispatcher  New component introduced in CoreXL.  Receives packets and forwards them to the kernel instances.  Acts as a load balancer. The dispatching is based on a hash of the source IP, Destination IP, Destination port and IP protocol (4-tuple)  The dispatcher must maintain core stickiness per connection
  • 60. 6363©2014 Check Point Software Technologies Ltd. | | CoreXL - First Packet Flow Dispatcher fw0 fw1 fw2conn table conn table conn table global conn table WT WT WT Lookup. Not found Arbitrary Decision Record Conn QueueQueueQueue PKT 2
  • 61. 6464©2014 Check Point Software Technologies Ltd. | | CoreXL - Second Packet Flow Dispatcher fw0 fw1 fw2conn table conn table conn table global conn table WT WT WT Lookup. Found QueueQueueQueue 2 PKT
  • 62. 6565©2014 Check Point Software Technologies Ltd. | | CoreXL - Parallel Processing Dispatcher fw0 fw1 fw2conn table conn table conn table QueueQueueQueue global conn table 0 1 2 WT WTWT PKTPKTPKT
  • 63. 6666©2014 Check Point Software Technologies Ltd. | | CoreXL Core #7Core #6 Core #3Core #2 Core #5Core #4 Core #1 Dispatcher Core #0 eth1 eth0 PPAK Dispatcher PPAK fw5Medium Path Queue fw4Medium Path Queue fw1Medium Path Queue fw0Medium Path Queue fw3Medium Path Queue fw2Medium Path Queue  Accelerated Path Cores are allocated via Interface IRQ Affinity  Secure Network Dispatcher queues packets to firewall instances running Firewall and Medium Paths SND SND
  • 64. 6767©2014 Check Point Software Technologies Ltd. | | Performance Pack Dispatcher Core #0 Core #4 Medium Path FW Path Queue Accelerated Path – No Template Performance Pack Dispatcher Core #1 eth0 eth1 CCore #... Medium Path FW Path Queue Core #... Medium Path FW Path Queue Syn SynAck + subsequent S2C packets Subsequent C2S packets
  • 65. 6868©2014 Check Point Software Technologies Ltd. | | Performance Pack Dispatcher Core #0 Core #4 Medium Path FW Path Queue Accelerated Path – With Template Performance Pack Dispatcher Core #1 eth0 eth1 CCore #... Medium Path FW Path Queue Core #... Medium Path FW Path Queue Syn + subsequent C2S packets SynAck + subsequent S2C packets
  • 66. 6969©2014 Check Point Software Technologies Ltd. | | Performance Pack Secure Dispatcher Core #0 Core #4 Medium Path FW Path Queue Medium Path – IPS Traffic Performance Pack Secure Dispatcher Core #1 eth0 eth1 CCore #... Medium Path FW Path Queue Core #... Medium Path FW Path Queue Syn + subsequent C2S packets SynAck + subsequent S2C packets
  • 67. 7070©2014 Check Point Software Technologies Ltd. | | VSX CoreXL VSX CoreXL  Same idea as applied for SG is applied to VSX CoreXL.  Main difference, instance in FWK (fw kernel equivalent) are executed by UM threads.  VSX CoreXL can be applied for any existing VS simultaneously with different number of instances.
  • 68. 7272©2014 Check Point Software Technologies Ltd. | | VSX CoreXL configuration  CoreXL configuration for VS0 is done using cpconfig This program will let you re-configure your Check Point products configuration. Configuration Options: ---------------------- (1) Licenses and contracts (2) SNMP Extension (3) PKCS#11 Token (4) Random Pool (5) Secure Internal Communication (6) Enable cluster membership for this gateway (7) Disable Check Point SecureXL (8) Configure Check Point CoreXL (9) Automatic start of Check Point Products (10) Exit Enter your choice (1-10) :  CoreXL for VS which is not VS0 is done using SmartDashboard Note: changing CoreXL configuration (num of instances) will require downtime of the VS (VS0 or other).
  • 69. 7373©2014 Check Point Software Technologies Ltd. | | VSX Affinity Usage  Setting Affinity – Interface Affinity: fw ctl affinity -s -i <interface> <cpuids | all> – VS affinity (VS,VR,VSW): fw ctl affinity -s -d [-vsid <ranges>] -cpu <ranges> – Process affinity - fw ctl affinity -s -d -pname <process name> [-vsid <ranges>] -cpu <ranges> – pid Affinity - fw ctl affinity -s -p <pid> <cpuids | all> – FWK instance affinity - fw ctl affinity -s -d -inst <ranges> -cpu <ranges> – All FWKs affinity - fw ctl affinity -s -d -fwkall <num of CPUs> Note: If vsid flag is omitted, the current context will be used.  Listing Affinity – Configured affinity - fw ctl affinity -l – Extended Affinity - fw ctl affinity -l -x [-vsid <ranges>] [-cpu <ranges>] [-flags e|k|t|n] – Flags: – e don't print exception processes – k don't print kernel threads – t print also all process threads – n print process name instead of /proc/<pid>/cmdline – h print CPU mask in hex format
  • 70. 7474©2014 Check Point Software Technologies Ltd. | | Usage Examples  Setting affinity examples – fw ctl affinity -s -d -fwkall 3 – fw ctl affinity -i eth0 0 3 7 – fw ctl affinity -s -d -inst 0 2 4 -cpu 5 – fw ctl affinity -s -d -pname cpd -vsid 0-12 -cpu 7 – fw ctl affinity -s -d -vsid 0-2 4 6-8 -cpu 0-2 4  Listing Affinity example – fw ctl affinity -l Output: eth0: CPU 1 VS_0 FWK_INSTANCE_0: CPU 0 1 2 VS_0 fwk: CPU 2 3 VS_1 FWK_INSTANCE_0: CPU 0 VS_1 FWK_INSTANCE_1: CPU 1 VS_1 FWK_INSTANCE_2: CPU 2 VS_1 fwk: CPU 2 3 VS_2 cpd: CPU 1 2 3 VS_2 fwk: CPU 2 3 VS_3 fwd: CPU 1 3 VS_3 fwk: CPU 0 3
  • 71. 7575©2014 Check Point Software Technologies Ltd. | | Usage Examples (cont)  Extended Affinity List example – fw ctl affinity –l –x –vsid 1 –flags tnek Output: ------------------------------------------------------- |PID |VSID | CPU |SRC|V|KT |EXC| NAME ------------------------------------------------------- | 4835 | 1 | all | | | | | routed | 21094 | 1 | all | | | | | fwk_wd | 21096 | 1 | all | | | | | cpd | 21241 | 1 | all | | | | | |---cpd | 21244 | 1 | all | | | | | |---cpd | 21245 | 1 | all | | | | | |---cpd | 21107 | 1 | all | | | | | mpdaemon | 21115 | 1 | 2 3 | P | | | | fwk1_dev | 21116 | 1 | 0 | I | | | | |---fwk1_0 | 21117 | 1 | 1 | I | | | | |---fwk1_1 | 21118 | 1 | 2 | I | | | | |---fwk1_2 | 21119 | 1 | 2 3 | P | | | | |---fwk1_3 | 21401 | 1 | all | | | | | fw | 21411 | 1 | all | | | | | |---fw | 21412 | 1 | all | | | | | |---fw | 21413 | 1 | all | | | | | |---fw -------------------------------------------------------
  • 72. 7676©2014 Check Point Software Technologies Ltd. | | CoreXL with Affinity Example  Command used for viewing fwk setup in the following example – fw ctl affinity –l –x –vsid 1 –flags tn | grep fwk | grep –v fwk_  Before Setting CoreXL | 21115 | 1 | 2 3 | P | | | | fwk1_dev | 21116 | 1 | 0 | I | | | | |---fwk1_0  After Setting CoreXL (Used SDB to configure 4 instances) | 21115 | 1 | 2 3 | P | | | | fwk1_dev | 21116 | 1 | 2 3 | P | | | | |---fwk1_0 | 21117 | 1 | 2 3 | P | | | | |---fwk1_1 | 21118 | 1 | 2 3 | P | | | | |---fwk1_2 | 21119 | 1 | 2 3 | P | | | | |---fwk1_3  Set affinity for instance 0 (fw ctl affinity –s –d –inst 0 –cpu 0) | 21115 | 1 | 2 3 | P | | | | fwk1_dev | 21116 | 1 | 0 | I | | | | |---fwk1_0 | 21117 | 1 | 2 3 | P | | | | |---fwk1_1 | 21118 | 1 | 2 3 | P | | | | |---fwk1_2 | 21119 | 1 | 2 3 | P | | | | |---fwk1_3  Set affinity for instance 2 and 3 (fw ctl affinity –s –d –inst 2 3 –cpu 1 2) | 21115 | 1 | 2 3 | P | | | | fwk1_dev | 21116 | 1 | 0 | I | | | | |---fwk1_0 | 21117 | 1 | 2 3 | P | | | | |---fwk1_1 | 21118 | 1 | 1 2 | I | | | | |---fwk1_2 | 21119 | 1 | 1 2 | I | | | | |---fwk1_3
  • 73. ©2014 Check Point Software Technologies Ltd. | VSX R77 Virtual System Load Sharing
  • 74. 7878©2014 Check Point Software Technologies Ltd. | | Agenda  Genesis  Motivation  Architecture  State Synchronization  Virtual System Load Sharing Fail over  Performance  Summary
  • 75. 7979©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Genesis Member 2 A S S S S S VS1 VS2 VS3 •First there was HA S S S S A A
  • 76. 8080©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 10:00 R77 VSX Introduction vsx_utill RC & QoS Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 77. 8181©2014 Check Point Software Technologies Ltd. | | 1 2 3 4 5 6 71 2 3 4 5 6 7 Motivation  Improve VSX cluster performance (synchronization traffic limits scalability).  Provide cost-effective Load Sharing in VSX, using the VS as the basis for Load Sharing. Performance Number of Cluster Members Standard Cluster VSLS Cluster
  • 78. 8282©2014 Check Point Software Technologies Ltd. | | Architecture  Each VS behaves as a FW-1 cluster.  ClusterXL HA is used (gratuitous ARP).  VSX machines are connected to the outside world using standard L2 switches. member 1 member 2 member 3 L2 switch L2 switch
  • 79. 8383©2014 Check Point Software Technologies Ltd. | | Architecture Virtual Systems are distributed between Cluster members. member 1 member 2 member 3 VS1 VS2 VS3
  • 80. 8484©2014 Check Point Software Technologies Ltd. | | Architecture Virtual Systems are distributed between Cluster members. member 1 member 2 member 3 VS1 VS2 VS3 A A A A Active VS
  • 81. 8585©2014 Check Point Software Technologies Ltd. | | Architecture Virtual Systems are distributed between Cluster members. member 1 member 2 member 3 VS1 VS2 VS3 A S A S S A A Active VS S Standby VS
  • 82. 8686©2014 Check Point Software Technologies Ltd. | | Architecture Virtual Systems are distributed between Cluster members. member 1 member 2 member 3 VS1 VS2 VS3 A S A S S A A Active VS S Backup VS Standby VS
  • 83. 8787©2014 Check Point Software Technologies Ltd. | | Architecture Each cluster member has some of the VSs, but not all of them. member 1 member 2 member 3 VS1 VS2 VS3 A S A S S A A Active VS S Standby VS Backup VS
  • 84. 8888©2014 Check Point Software Technologies Ltd. | | Architecture Each VS is installed on some of the members, but not all of them. member 1 member 2 member 3 VS1 VS2 VS3 A S A S S A A Active VS S Standby VS Backup VS
  • 85. 8989©2014 Check Point Software Technologies Ltd. | | Architecture Backup Virtual Systems do not consume system resources. member 1 member 2 member 3 VS1 VS2 VS3 A S A S S A A Active VS S Standby VS Backup VS
  • 86. 9090©2014 Check Point Software Technologies Ltd. | | State Synchronization
  • 87. 9191©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSX Member 2 A S S S S S VS1 VS2 VS3 S S S S A A Broadcast is more efficient when the VSs are installed on all the members
  • 88. 9292©2014 Check Point Software Technologies Ltd. | | The Mode of Cluster Control Protocol (CCP) in VSX cluster In VSX cluster: VSX NGX / VSX NGX R65 / VSX NGX R67 / VSX NGX R68: The only possible mode of CCP is Broadcast. R75.40VS / R76 and above: CCP mode over Sync Network is Broadcast for all Virtual Systems. CCP mode over non-Sync Networks is Multicast. In VSLS configuration, when instances of Virtual Systems are not running on all cluster members (e.g., only 2 VSs were configured on a VSX cluster that has 4 cluster members), the Delta Sync packets generated by a Virtual System, are sent in Unicast only to those members that run the instance of the same Virtual System. On 61000 appliance (starting in R75.40VS for 61000), the 'asg_sync_manager' - option '8) Enable / Disable unicast sync' - enables the user to define its required synchronization level - the user can enable / disableUnicast sync (correction layer will be enabled / disabled accordingly) and return to legacy synchronization scheme (synchronize connections to all SGMs).
  • 89. 9393©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Connection is created on VS1 Broadcast in VSX for Sync Network Member 2 A S S S S S VS1 VS2 VS3 S S S S A A
  • 90. 9494©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSX Member 2 A S S S S S VS1 VS2 VS3 Sync is sent to all members via broadcast S S S S A A
  • 91. 9595©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSX Member 2 A S S S S S VS1 VS2 VS3 Sync is sent to all members via broadcast S S S S A A
  • 92. 9696©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Connection is created on VS1 Broadcast Sync in VSLS Member 2 A S A S A S VS1 VS2 VS3
  • 93. 9797©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSLS Member 2 A S A S A S VS1 VS2 VS3 Sync is sent to all members via broadcast
  • 94. 9898©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSLS Member 2 A S A S A S VS1 VS2 VS3 Sync is sent to all members via broadcast ??
  • 95. 9999©2014 Check Point Software Technologies Ltd. | | Member 1 Member 3 Member 4 Broadcast Sync in VSLS Member 2 A S A S A S VS1 VS2 VS3 ?? Members 3 and 4 discard the sync packet
  • 96. 100100©2014 Check Point Software Technologies Ltd. | | Virtual System Load Sharing Fail over
  • 97. 101101©2014 Check Point Software Technologies Ltd. | | Step 1 –distributed VSs Member 1 Member 2 Member 3 VS1 VS2 VS3 A S A S S A
  • 98. 102102©2014 Check Point Software Technologies Ltd. | | Step 2 –Machine Failure Member 2 Member 3 A S A A Member 1 VS1 VS2 VS3 S Member 1 fails, causing an immediate failover of VS1 to member 3. S S
  • 99. 103103©2014 Check Point Software Technologies Ltd. | | Step 3 – Machine recovered Member 1 Member 2 Member 3 VS1 VS2 VS3 A S A A S S Member 1 goes up again and the system performs full sync for VS1 and VS2. S S
  • 100. 104104©2014 Check Point Software Technologies Ltd. | | Step 4 – Load sharing restored Member 1 Member 2 Member 3 VS1 VS2 VS3 A S A A S S The system can now force VS1 to become active on member 1, so the load is shared equally between the machines. A S
  • 101. 105105©2014 Check Point Software Technologies Ltd. | | Performance
  • 102. 106106©2014 Check Point Software Technologies Ltd. | | Limitations  Virtual Routers are not supported.  Each Virtual Switch must have a physical or VLAN interface that provides connectivity between cluster members. When working with ClusterXL Virtual System Load Sharing (VSLS):
  • 103. 107107©2014 Check Point Software Technologies Ltd. | | Summary  VSLS currently provides the best performance and scalability.  Easy to administer and monitor.  Administrator needs not to be involved in failover process.  System intelligently provides the best performance and redundancy possible.
  • 104. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to Lab 4
  • 105. ©2014 Check Point Software Technologies Ltd. | R77 VSX Memory Resource Control
  • 106. 110110©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 10:00 R77 VSX Introduction vsx_utill RC & QoS Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 107. 111111©2014 Check Point Software Technologies Ltd. | | Memory Resource control overview Memory Resource control (“fw vsx mstat”) gives the user overview information about:  Memory consumption of the system  Memory consumption per virtual device
  • 108. 112112©2014 Check Point Software Technologies Ltd. | | Overview cont. “The memory consumption per VS is a sum of the following: Kernel Space  SIM (SecureXL) memory per VS allocations.  Dispatcher memory per VS allocations. User Space  Accumulations of clean pages (private) and dirty pages (private) per process for all processes per VS
  • 109. 113113©2014 Check Point Software Technologies Ltd. | | Overview cont. Global info given about system: • Total amount of physical memory • Free memory • Total amount of swap memory • Free swap memory • Swap rate (total number of kilobytes the system paged in from disk per second)
  • 110. 114114©2014 Check Point Software Technologies Ltd. | | VSX Memory Resource Control Usage  fw vsx mstat - Displays total memory consumption per virtual system • Flags • -vs - displays memory status for specific VSIDs • sort - sorts the virtual systems by their memory size • unit - change the displayed memory unit • swap - updates the swap-in sample rate in minutes  fw vsx mstat debug - Displays memory consumption debug info per VS.  fw vsx mstat enable - Enables this feature, requires a reboot.  fw vsx mstat disable - Disables this feature, affected immediately.  fw vsx mstat status - Displays feature status, (enabled/disabled).  fw vsx mstat help - Displays help.
  • 111. 115115©2014 Check Point Software Technologies Ltd. | | Monitoring Memory Resources [Expert@GIZA42G204:0]# fw vsx mstat sort all VSX Memory Status ================= Memory Total: 997.22 MB Memory Free: 232.52 MB Swap Total: 2047.34 MB Swap Free: 2047.16 MB Swap-in rate: 0.00 MB VSID | Memory Consumption ======+==================== 0 | 133.49 MB 8 | 92.41 MB 3 | 43.81 MB 2 | 42.47 MB 1 | 42.47 MB
  • 112. ©2014 Check Point Software Technologies Ltd. | The vsx_util VSX Management maintenance tool
  • 113. 117117©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 RR77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 114. 118118©2014 Check Point Software Technologies Ltd. | | vsx_util  vsx_util is a tool for performing VSX maintenance activities.  vsx_util is a CPMI client that connects to the Management server (Main DMS in case of Provider-1), just like SmartDashboard.  The Management machine from which vsx_util is run must be defined as a GUI client (just like SDB)  Not supported for the (very old) version of VSX NG AI and below.
  • 115. 119119©2014 Check Point Software Technologies Ltd. | | vsx_util reconfigure / add_member_reconf  Used to deploy an existing configuration on a freshly installed Gateway / Cluster Member  Useful after a machine hardware failure  Used also after upgrading module to a new version.
  • 116. 120120©2014 Check Point Software Technologies Ltd. | | vsx_util reconfigure – limitations and common errors  Limitations  The new module must have the same configuration as the reconfigured member (same number of interfaces, management IP etc.)  The module must be newly installed without any previous VSX configuration  Common Errors:  vsx_util reconfigure asks to re-install policy on the VSX and run the command again ► The message occurs when the reconfigure process cannot retrieve the name of the policy installed on the VSX Gateway/Cluster ► This might happen after the Management was upgraded using upgrade_import from a version older than R61 ► Workaround: copy $FWDIR/state/links.C from the original Management
  • 117. 121121©2014 Check Point Software Technologies Ltd. | | vsx_util add_member / remove_member  vsx_util add_member  Used to add a member to an existing VSX Cluster configuration  After running add_member, vsx_util add_member_reconf needs to be run to configure the new member with the VSX configuration  vsx_util remove_member  Used to remove a member from an existing VSX Cluster configuration  Can be performed only if the VSX Cluster has at least 3 members
  • 118. 122122©2014 Check Point Software Technologies Ltd. | | vsx_util change_private_net  Used to change the VSX Cluster Private Network on an existing Cluster configuration  Limitations:  The new Cluster Private Network must not be used anywhere behind the VSX Cluster/Gateway or it’s Virtual Systems  The new Cluster Private Network has to match the private network mask 255.255.252.0
  • 119. 123123©2014 Check Point Software Technologies Ltd. | | vsx_util change_mgmt_ip  Used to change the management IP address of VSX member/ gateway.  Limitations:  The IP address should stay in the same subnet.  Not supported in Non Dedicated Management Interface mode.
  • 120. 124124©2014 Check Point Software Technologies Ltd. | | vsx_util change_mgmt_subnet  Used to change the management IP of a VSX cluster/gateway to a new subnet.  Allows to change the VSX cluster management IP, VSX members management IP and the management subnet mask.  Limitations:  Not supported in Non Dedicated Management Interface mode.
  • 121. 125125©2014 Check Point Software Technologies Ltd. | | vsx_util vsls  Displays the current Virtual System Load Sharing (VSLS) configuration as it appears in the management database, and allows exporting to CSV.  The displayed configuration is the “desired” state. It does not necessarily reflect the actual configuration on the Cluster Members. – In case the Cluster Members encounter a certain problem, they might not enforce the “desired” VSLS configuration
  • 122. 126126©2014 Check Point Software Technologies Ltd. | | vsx_util vsls (was redistribute_vsls)  Distributes the Virtual Systems among the VSX Cluster Members.  vsx_util suggests the following options:  Automatically distribute the Virtual Systems over all Cluster Members in a way that all Cluster Members are equally loaded.  Have all Virtual Systems active on the same Cluster Member ► similar to ClusterXL mode High Availability, except for the fact that for each Virtual System there is only one Standby Cluster Member while the rest of the Cluster Members are backup  Manually configure the weight and members priority list for a specific Virtual System  Import priority and weight from a CSV.
  • 123. 127127©2014 Check Point Software Technologies Ltd. | | vsx_util vsls (was redistribute_vsls) – cont.  Notes:  A Virtual System is created with a default weight (10)  Changing the weight of a Virtual System will only have influence when the Priority List for a new Virtual System is calculated  For the new configured weight to take effect immediately, the Virtual Systems need to be redistributed automatically among all Cluster Members The redistribution is a rather heavy operation because it might trigger Virtual System Failovers from one Cluster Member to another
  • 124. 128128©2014 Check Point Software Technologies Ltd. | | vsx_util convert_cluster  Converts the ClusterXL mode to one of the following:  High Availability – All Virtual Systems are active on the same Cluster Member, the other members are in standby state  Virtual System Load Sharing – The active Virtual Systems are spread among all Cluster Members to equally balance the load over all Cluster Members ► Each Virtual System is active on one Cluster Member, Standby on another Cluster Member and in backup mode on the rest of the Cluster Members (not resources consuming)
  • 125. 129129©2014 Check Point Software Technologies Ltd. | | vsx_util view_vs_conf  Displays Virtual Device configuration on Management versus VSX gateways  Displays the interface configuration table and the routing table of the Virtual Device  Used to see if there is a configuration mismatch between what is defined on the management and the VSX gateways
  • 126. 130130©2014 Check Point Software Technologies Ltd. | | vsx_util change_interfaces  Used to replace between interfaces in an existing configuration  Management Only Mode:  Changes the management database only.  Very useful to convert from open server to CheckPoint appliance  Should only be used with freshly installed Gateway/Cluster members  New Configuration will be applied to the VSX members using vsx_util reconfigure.  Push configuration to VSX Gateway/Cluster members immediately mode:  Changes are applied to the VSX Gateway/Cluster members immediately  Very useful when adding new bond interfaces to an existing configuration  Displays a summary report with individual status per virtual device
  • 127. 131131©2014 Check Point Software Technologies Ltd. | | vsx_util show_interfaces  Displays information about interfaces configuration on the Management  Displays the type of interface, the virtual device it is connected to in the VSX, IP address and netmask  Output is displayed on screen and saved to interfacesconfig.csv file
  • 128. 132132©2014 Check Point Software Technologies Ltd. | | Resume capabilities  The following actions support resume:  reconfigure / add_member_reconf  upgrade  add_member  remove_member  change_private_net  change_mgmt_ip  change_mgmt_subnet  change_interfaces  vsx_util remembers the point of failure and when it is executed again, it will continue from there.
  • 129. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 5, 6
  • 130. ©2014 Check Point Software Technologies Ltd. | The vsx_util VSX Management maintenance tool
  • 131. 135135©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 RR77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 132. 136136©2014 Check Point Software Technologies Ltd. | | vsx_util  vsx_util is a tool for performing VSX maintenance activities.  vsx_util is a CPMI client that connects to the Management server (Main DMS in case of Provider-1), just like SmartDashboard.  The Management machine from which vsx_util is run must be defined as a GUI client (just like SDB)  Not supported for the (very old) version of VSX NG AI and below.
  • 133. 137137©2014 Check Point Software Technologies Ltd. | | vsx_util reconfigure / add_member_reconf  Used to deploy an existing configuration on a freshly installed Gateway / Cluster Member  Useful after a machine hardware failure  Used also after upgrading module to a new version.
  • 134. 138138©2014 Check Point Software Technologies Ltd. | | vsx_util reconfigure – limitations and common errors  Limitations  The new module must have the same configuration as the reconfigured member (same number of interfaces, management IP etc.)  The module must be newly installed without any previous VSX configuration  Common Errors:  vsx_util reconfigure asks to re-install policy on the VSX and run the command again ► The message occurs when the reconfigure process cannot retrieve the name of the policy installed on the VSX Gateway/Cluster ► This might happen after the Management was upgraded using upgrade_import from a version older than R61 ► Workaround: copy $FWDIR/state/links.C from the original Management
  • 135. 139139©2014 Check Point Software Technologies Ltd. | | vsx_util add_member / remove_member  vsx_util add_member  Used to add a member to an existing VSX Cluster configuration  After running add_member, vsx_util add_member_reconf needs to be run to configure the new member with the VSX configuration  vsx_util remove_member  Used to remove a member from an existing VSX Cluster configuration  Can be performed only if the VSX Cluster has at least 3 members
  • 136. 140140©2014 Check Point Software Technologies Ltd. | | vsx_util change_private_net  Used to change the VSX Cluster Private Network on an existing Cluster configuration  Limitations:  The new Cluster Private Network must not be used anywhere behind the VSX Cluster/Gateway or it’s Virtual Systems  The new Cluster Private Network has to match the private network mask 255.255.252.0
  • 137. 141141©2014 Check Point Software Technologies Ltd. | | vsx_util change_mgmt_ip  Used to change the management IP address of VSX member/ gateway.  Limitations:  The IP address should stay in the same subnet.  Not supported in Non Dedicated Management Interface mode.
  • 138. 142142©2014 Check Point Software Technologies Ltd. | | vsx_util change_mgmt_subnet  Used to change the management IP of a VSX cluster/gateway to a new subnet.  Allows to change the VSX cluster management IP, VSX members management IP and the management subnet mask.  Limitations:  Not supported in Non Dedicated Management Interface mode.
  • 139. 143143©2014 Check Point Software Technologies Ltd. | | vsx_util vsls  Displays the current Virtual System Load Sharing (VSLS) configuration as it appears in the management database, and allows exporting to CSV.  The displayed configuration is the “desired” state. It does not necessarily reflect the actual configuration on the Cluster Members. – In case the Cluster Members encounter a certain problem, they might not enforce the “desired” VSLS configuration
  • 140. 144144©2014 Check Point Software Technologies Ltd. | | vsx_util vsls (was redistribute_vsls)  Distributes the Virtual Systems among the VSX Cluster Members.  vsx_util suggests the following options:  Automatically distribute the Virtual Systems over all Cluster Members in a way that all Cluster Members are equally loaded.  Have all Virtual Systems active on the same Cluster Member ► similar to ClusterXL mode High Availability, except for the fact that for each Virtual System there is only one Standby Cluster Member while the rest of the Cluster Members are backup  Manually configure the weight and members priority list for a specific Virtual System  Import priority and weight from a CSV.
  • 141. 145145©2014 Check Point Software Technologies Ltd. | | vsx_util vsls (was redistribute_vsls) – cont.  Notes:  A Virtual System is created with a default weight (10)  Changing the weight of a Virtual System will only have influence when the Priority List for a new Virtual System is calculated  For the new configured weight to take effect immediately, the Virtual Systems need to be redistributed automatically among all Cluster Members The redistribution is a rather heavy operation because it might trigger Virtual System Failovers from one Cluster Member to another
  • 142. 146146©2014 Check Point Software Technologies Ltd. | | vsx_util convert_cluster  Converts the ClusterXL mode to one of the following:  High Availability – All Virtual Systems are active on the same Cluster Member, the other members are in standby state  Virtual System Load Sharing – The active Virtual Systems are spread among all Cluster Members to equally balance the load over all Cluster Members ► Each Virtual System is active on one Cluster Member, Standby on another Cluster Member and in backup mode on the rest of the Cluster Members (not resources consuming)
  • 143. 147147©2014 Check Point Software Technologies Ltd. | | vsx_util view_vs_conf  Displays Virtual Device configuration on Management versus VSX gateways  Displays the interface configuration table and the routing table of the Virtual Device  Used to see if there is a configuration mismatch between what is defined on the management and the VSX gateways
  • 144. 148148©2014 Check Point Software Technologies Ltd. | | vsx_util change_interfaces  Used to replace between interfaces in an existing configuration  Management Only Mode:  Changes the management database only.  Very useful to convert from open server to CheckPoint appliance  Should only be used with freshly installed Gateway/Cluster members  New Configuration will be applied to the VSX members using vsx_util reconfigure.  Push configuration to VSX Gateway/Cluster members immediately mode:  Changes are applied to the VSX Gateway/Cluster members immediately  Very useful when adding new bond interfaces to an existing configuration  Displays a summary report with individual status per virtual device
  • 145. 149149©2014 Check Point Software Technologies Ltd. | | vsx_util show_interfaces  Displays information about interfaces configuration on the Management  Displays the type of interface, the virtual device it is connected to in the VSX, IP address and netmask  Output is displayed on screen and saved to interfacesconfig.csv file
  • 146. 150150©2014 Check Point Software Technologies Ltd. | | Resume capabilities  The following actions support resume:  reconfigure / add_member_reconf  upgrade  add_member  remove_member  change_private_net  change_mgmt_ip  change_mgmt_subnet  change_interfaces  vsx_util remembers the point of failure and when it is executed again, it will continue from there.
  • 147. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 5, 6
  • 148. ©2014 Check Point Software Technologies Ltd. | VSX Management Implementation
  • 149. 153153©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 150. 154154©2014 Check Point Software Technologies Ltd. | | Management side implementation  General communication flow  Management database  Network Configuration Script  NCS files and their location  Provider-1 Forwarding Concept  SIC implementation  Cluster Private Network
  • 151. 155155©2014 Check Point Software Technologies Ltd. | | General Communication Flow  3-tier management architecture:  GUI - SmartDashboard  Management Server - Provider-1 or SmartCenter  VSX Gateway  Communications flow between the participants in a VSX setup: Management Server VSX GatewaySmartDashboard
  • 152. 156156©2014 Check Point Software Technologies Ltd. | | Management Models VSX can be managed in two ways:  SmartCenter management  Provider-1 management  Each domain management server (DMS) may manage one or more Virtual Devices
  • 153. 157157©2014 Check Point Software Technologies Ltd. | | Managing VSX from Provider-1  Virtual Devices can be managed by different DMSs.  The DMS where the VSX is defined is called the “Main DMS”.  DMSs where Virtual Devices are defined are called “Target DMSs”.  DMS is being “Target” or “Main” relatively to a specific VSX. VS A VS B DMS Mgr DMS A DMS B (Main) (Target) (Target)
  • 154. 158158©2014 Check Point Software Technologies Ltd. | | Management database  Each Virtual Device has 2 objects representing it:  network_object  vs_slot  Network object  Resides on the Target DMS  The object the user sees in SmartDashboard.  vs_slot objects  Reside on the Main DMS
  • 155. 159159©2014 Check Point Software Technologies Ltd. | | Management database vs_slot objects  Contain the list of interfaces belonging to a Virtual Device.  Contain the list of routes belonging to a Virtual Device.  Contain other VSX specific attributes. For instance, a reference to the VSX object to which the Virtual Device belongs.  The vs_slot objects are used in order to create the Virtual Devices and their networking properties on a VSX Gateway (Later will be explained how).  vs_slot objects are stored in the Check Point database in a table called vs_slot_objects.
  • 156. 160160©2014 Check Point Software Technologies Ltd. | | VSX Management  VSX related information is stored in the management  Initial configuration is fetched from the VSX gateway  After the VSX creation, any configuration change is done through the management.  It’s possible to push the VSX configuration, stored in the database, to a blank module.
  • 157. 161161©2014 Check Point Software Technologies Ltd. | | Management to Module communication  NCS (Network Configuration Script) files pass the VSX configuration from the management to the GW.  The files are generated on the management machine  The GW receives the configuration files, parses and executes them. Management Server VSX Gateway
  • 158. 162162©2014 Check Point Software Technologies Ltd. | | The NCS Example of NCS file  Creates a VS with 2 interfaces  One VLAN interface  The other leading to Virtual Switch  Adds routes #NCS Build 620001002 #local.vs for Virtual System VS5 on VSX GW EcuCluster created at Tue Mar,13 18: 58:12 2007 begin [mem1:]vs create vs 8 vr 8 name mem1_VS5 uid {0727F24C-D184-11DB-8CF0-0000 00004F4F} is_junction 0 is_bridge 0 cpu_usage 0.000000 main_ip sic_name CN=mem1 _VS5,O=peter.marie..pngba3 bw_limit 0 bw_guarantee 0 conn_limit 15000 masters _addresses 192.168.100.100,194.29.37.83 otp "5e54c2cf66dc45b61f712c12badc90dfcf6 ed1fb" cluster_name VS5 [mem2:]vs create vs 8 vr 8 name mem2_VS5 uid {0728215E-D184-11DB-8CF0-000000 004F4F} is_junction 0 is_bridge 0 cpu_usage 0.000000 main_ip sic_name CN=mem2 _VS5,O=peter.marie..pngba3 bw_limit 0 bw_guarantee 0 conn_limit 15000 masters_ad dresses 192.168.100.100,194.29.37.83 otp "b52e55829f28a63001f65cc94899de97f9fa77 9a" cluster_name VS5 [mem1:]vlan create tag 5 dev eth3 [mem1:]interface set dev eth3.5 address 192.168.196.1 netmask 255.255.255.240 mtu 1500 vr 8 cluster_ip 1.1.1.5 cluster_mask 255.255.255.0 [mem1:]warp create name_a wrp512 name_b wrpj512 mac_id_a 6 mac_id_b 7 [mem1:]interface set dev wrp512 address 192.168.196.17 netmask 255.255.255.24 0 mtu 1500 vr 8 cluster_ip 10.10.10.5 cluster_mask 255.255.255.0 [mem1:]interface set dev wrpj512 address 0.0.0.0 netmask 0.0.0.0 mtu 1500 vr 3 [mem1:]bridge attach name br3 dev wrpj512 [mem2:]vlan create tag 5 dev eth3 [mem2:]interface set dev eth3.5 address 192.168.196.2 netmask 255.255.255.240 mtu 1500 vr 8 cluster_ip 1.1.1.5 cluster_mask 255.255.255.0 [mem2:]warp create name_a wrp512 name_b wrpj512 mac_id_a 6 mac_id_b 7 [mem2:]interface set dev wrp512 address 192.168.196.18 netmask 255.255.255.240 mtu 1500 vr 8 cluster_ip 10.10.10.5 cluster_mask 255.255.255.0 [mem2:]interface set dev wrpj512 address 0.0.0.0 netmask 0.0.0.0 mtu 1500 vr 3 [mem2:]bridge attach name br3 dev wrpj512 [mem1:]route set dest 10.10.10.0 netmask 255.255.255.0 metric 0 dev wrp512 vr 8 [mem1:]route set dest 1.1.1.0 netmask 255.255.255.0 metric 0 dev eth3.5 vr 8 [mem2:]route set dest 10.10.10.0 netmask 255.255.255.0 metric 0 dev wrp512 vr 8 [mem2:]route set dest 1.1.1.0 netmask 255.255.255.0 metric 0 dev eth3.5 vr 8 end
  • 159. 163163©2014 Check Point Software Technologies Ltd. | | The NCS – file structure  3 files are passed to the VSX gateway after each configuration change done in SmartDashboard:  local.vs - NCS file, the last configuration change.  local.vsall - NCS file, contains the full configuration. This file is executed at system startup.  local.vskeep - contains the list of existing VSIDs.  These files are created based on vs_slot_objects table.
  • 160. 164164©2014 Check Point Software Technologies Ltd. | | Composition of local.vs  Each vs_slot object has 2 attributes containing interfaces lists:  “interfaces”  “interfaces_installed”  Each vs_slot object has 2 attributes containing routes lists:  “routes”  “routes_installed”  local.vs file is the product of comparing the two couples
  • 161. 165165©2014 Check Point Software Technologies Ltd. | | Composition of local.vsall and local.vskeep  a Virtual Device has 2 NCS files on the management:  VD_name.vsnew - NCS file containing interfaces  VD_name.vsrt - NCS file containing routes  Files are updated each time configuration is changed  local.vsall is a product of combining the files of all the Virtual Devices.  local.vskeep is created by going over vs_slot_objects table and writing all the Virtual Devices VSIDs to it.
  • 162. 166166©2014 Check Point Software Technologies Ltd. | | Files Location  On the management  * .vsnew and *.vsrt files are located in Main DMS. ► Under $FWDIR/conf/vs_repository/VSX_NAME directory  composed local.vs, local.vsall and local.vskeep files are put in a state directory, then sent to the VSX gateway. ► Under $FWDIR/state/VSX_NAME/VSX/ directory  On the VSX gateway  Received local.vs, local.vsall and local.vskeep files are first located under $FWDIR/state/__tmp/VSX/ directory.  If files processing succeeds, they are copied to $FWDIR/state/local/VSX/ directory.
  • 163. 167167©2014 Check Point Software Technologies Ltd. | | Provider-1 Forwarding Concept  Configuring Virtual Device in Provider-1  SmartDashboard is connected to the Target DMS.  Both Target and main DMSs needs updating  Command to Target DMS, is forwarded to the Main DMS (requires lock) Management Server VSX GatewaySmartDashboard Main DMS Target DMS
  • 164. 168168©2014 Check Point Software Technologies Ltd. | | SIC - Secure Internal Communication  SIC is a Check Point proprietary protocol developed to secure all communication amongst all Check Point's distributed components belonging to a single management domain.  Examples of "Internal Communications" are Management to Module communication (e.g. download a policy, send logs) and GUI client to Management server communications.  "Securing" the communications generally includes:  Authenticating that the peer is indeed who it claims to be  Clients: Ensuring that this is the same peer the client wished to communicate with  Servers: Ensuring that the peer is allowed to perform the actions it requests  Privacy and Integrity - Making sure that the data received is the data sent, and that no party other than the intended peer could read it
  • 165. 169169©2014 Check Point Software Technologies Ltd. | | SIC implementation  Single IP for SIC - a single IP Address is used for managing all the Virtual Devices on the VSX gateway.  Trust with the VSX gateway is established in the same way it is done for regular Firewall-1 object.  Trust with Virtual Devices is established in a special way, since they don’t have an IP Address to which the SIC certificate can be pushed.
  • 166. 170170©2014 Check Point Software Technologies Ltd. | | Trust Establishment with Virtual Device  SIC certificate for the Virtual Device is created by CA of the Target DMS.  After the device is created, SmartDashboard issues a command for pulling the new certificate.  Main DMS transfers the command to the VSX GW  VSX GW pulls the SIC certificate from the Target DMS. Management Server VSX GatewaySmartDashboard Main DMS Target DMS VS
  • 167. 171171©2014 Check Point Software Technologies Ltd. | | Trust Establishment with Virtual Device  SIC certificate for the Virtual Device is created by Certificate Authority of the Target DMS.  After the Virtual Device is created on the VSX gateway (as a result of local.vs file processing), SmartDashboard issues a command for pulling the newly created certificate. This command is forwarded to the Main DMS.  Main DMS transfers the command to the VSX gateway over the SIC channel established between them.  VSX gateway pulls the SIC certificate for the Virtual Device from the Target DMS. Management Server VSX GatewaySmartDashboard Main DMS Target DMS VS
  • 168. 172172©2014 Check Point Software Technologies Ltd. | | Cluster Private Network  unique IP address are required for each interface on each member.  These IP addresses are automatically allocated.  Cluster Private Network is defined on the VSX Cluster Object.  Default network: 192.168.196.0/22  Cluster Private Network can be changed:  In SmartDashboard before VS creation  At any stage using “vsx_util change_private_net”.
  • 169. 173173©2014 Check Point Software Technologies Ltd. | | Cluster Private Network  New interface on a Virtual Device, is assigned an IP Address from a cluster private network pool on all members.  IP Addresses must allow inter-VS routing and uniqueness on a given Virtual Device:  On a specific member - each IP is from a different subnet  Between members - all IPs are from the same subnet
  • 170. ©2014 Check Point Software Technologies Ltd. | VSX - R77 Gateway Implementation
  • 171. 175175©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 172. 176176©2014 Check Point Software Technologies Ltd. | | VSX Gateway side implementation  R77 New Architecture  Linux virtualization – VRF solution  VSX Packet Flow  FW-1 kernel virtualization  Acceleration  Files Structure  Registry Structure  Context Database  Virtual Device creation stages  Dynamic Routing  VSX Upgrade procedure
  • 173. 177177©2014 Check Point Software Technologies Ltd. | | VSX (R67) architecture NIC Fw kernel virtualized Ppack virtualized NIC fwd cpd cplogd VPN kernel virtualized Trap example – logs From fw kernel to cplogd Ioctls ex. – policy install From cpd to fw kernel UM KM vpnd vpnd vpnd 1. All kernel code had “inside virtualization” • Tables per VS • Parameters per VS or global 2. Most of the UM processes were virtualized (fwd/cpd/cplogd) 3. Some were per VS (vpnd)
  • 174. 178178©2014 Check Point Software Technologies Ltd. | | R77 VSX architecture NIC Ppack virtualized NIC UM KM Firewall dispatcher 1. Fwk is the fw’s kernel code compiled to a dll 2. PPK remains virtualized 3. I/S to simulate traps and ioctls, over TCP between fwd/cpd and fwk - fwasync_rpc VS fwd cpd vpnd fwk VS fwd cpd vpnd fwk VS fwd cpd vpnd fwk Ioctls ex. – policy install From cpd to fwk Trap example – logs From fwk to fwd
  • 175. 179179©2014 Check Point Software Technologies Ltd. | | FWK – User mode Firewall  FW-1 dispatcher is a driver, which sees the packets, and puts them in the processing queue of the right FWK.  FWK process does “kernel” processing. Has libfwk.so, libvpnk.so, librtmk.so loaded into it, multiple times if multiple instances are configured.  FWK is per VS, so all parameters, policy, tables, inspect code, etc. are obviously separate, without the need to change almost anything in the code.  Reads packets from queue, performs processing, and tells dispatcher if to pass/drop them.  Forked from FWK_FORKER, after a fork request arrives from FWK_WD (per VS)
  • 176. 180180©2014 Check Point Software Technologies Ltd. | | VRF – Linux CLI enhancements  “vsenv [vsid]” – changes context of expert shell – almost all commands (CP and OS) operate on this context.  In Gaia’s clish, “set virtual-system [vsid]”, which effects many commands, like routing
  • 177. 181181©2014 Check Point Software Technologies Ltd. | | VRFs and VSs VRF 0 VRF 1 VRF 2 VRF 3 VRF 4Linux kernel VS VR VS VSW CP drivers wrpj1 eth2.10 eth3 eth2.20 eth2.30 eth5 wrp1 wrp2 wrpj2 wrpj3 wrp3 VS eth2.5 The illustration above shows the connection between Linux VRFs and Check Point Virtual devices. A Virtual Devices is always tied to a VRF on the OS level, interfaces interconnect those VRFs.
  • 178. 182182©2014 Check Point Software Technologies Ltd. | | VSX Packet Flow  When a packet arrives, the VSX Gateway determines which Virtual Device should handle it. This process is called Context Determination.  Each interface has a VRF ID.  VRF ID on packet translated to VS ID when FW-1 processing begins.  Currently VRF ID = VS ID.
  • 179. 183183©2014 Check Point Software Technologies Ltd. | | VSX Packet Flow – Virtual Switch Packet arrives at a shared i/f connected to a VSW  The VSW determines which Virtual System should handle the packet  Based on the forwarding decision, the packet is sent to the relevant Virtual System  Broadcasts when no matching forwarding entry exists  The Virtual System WRP interface will only handle packets destined to its MAC address.
  • 180. 184184©2014 Check Point Software Technologies Ltd. | | VSX Packet Flow – Virtual Router Packet arrives at a shared i/f connected to a VR  If the targeted at the Virtual Router, the packet is matched against VR security policy and sent to its IP stack (if its policy permits).  Otherwise, the VR determines which VS should handle the packet by doing a route lookup it’s routing table.  The packet is then forwarded to the relevant Virtual System through a warp link.
  • 181. 190190©2014 Check Point Software Technologies Ltd. | | Performance Pack – Warp Jump Internet Inspection Routing  Is the VR a performance bottleneck? NO!  Only 1st packet is inspected by the VS and the VR.
  • 182. 191191©2014 Check Point Software Technologies Ltd. | | Performance Pack – Warp Jump Internet Inspection  following packets go directly from the Virtual System to the Physical interface.  The Virtual Router is skipped  We call it “Warp Jump”
  • 183. 192192©2014 Check Point Software Technologies Ltd. | | Files Structure  For the VSX (VS 0) the configuration files are located in the regular folders under $FWDIR/$CPDIR  Each Virtual System has its own $FWDIR and $CPDIR file structure (and some other DIRs), pointing to their CTX directories to VSX (VS 0) $FWDIR ($FWDIR/CTX/CTX[vsid])  “vsenv” sets $FWDIR/$CPDIR to the correct values – for example: VS 0 $FWDIR = /opt/CPsuite-R77/fw1 VS 1 $FWDIR = /opt/CPsuite-R77/fw1/CTX/CTX00001  Binaries and configuration files which are global and doesn’t change between different Virtual Systems will be symbolic links to the same file in VS 0
  • 184. 193193©2014 Check Point Software Technologies Ltd. | | Context Database and Registry Context Database  The ctxdb.C file (under $CPDIR/conf of VS0) contains an entry for each Virtual Device that holds Virtual Device’s specific configuration such as VRF, SIC name and more.  ctxdb.C is a global configuration file who is accessed by all Virtual Systems via symbolic link Registry  Each Virtual Device has its own registry, in the usual place of $CPDIR/registry/HKLM_registry.data
  • 185. 194194©2014 Check Point Software Technologies Ltd. | | Main Processes in VSX  CONFD, RAD, GEOD – single process, handle all VSs by internal virtualization  CPWD – single process, adapted to know about contexts, and to pass environment variables to spawned processes.  FWK, FWD, CPD, VPND, ROUTED, CPHAMCSET and many many others – process per VS, with little/no changes internally  FWK_FORKER, CPSICDEMUX, ROUTED manager – new processes, explained in next slide
  • 186. 195195©2014 Check Point Software Technologies Ltd. | | FWK_forker FWK_forker process is an instance of fwk process  Responsible to spawn fwk processes upon a request  Coming from fwk_wd process invoked in a given context
  • 187. 196196©2014 Check Point Software Technologies Ltd. | | Technology  CPSICDemux  New daemon called CPSICDemux was added to dispatch incoming SIC traffic between the various processes (ex. during install policy) of different VSs.
  • 188. 197197©2014 Check Point Software Technologies Ltd. | | CPSICDEMUX  Check Point SIC Demultiplexer runs in VSX context (VS 0), listens to many SIC ports (18191, 18192, 257, 256, etc.). New SIC connections from other member or from management arrives to cpsicdemux, starts SIC handshake, and then connection is passed to the correct CPD/FWD/etc. according to SIC name in the handshake.
  • 189. 199199©2014 Check Point Software Technologies Ltd. | | CPSICDEMUX
  • 190. 200200©2014 Check Point Software Technologies Ltd. | | ROUTED manager Routed manager  Runs in VSX context (VS 0)  Spawns routed instances per VS.  Handles connections from other members for route synchronization  Starts routed sync protocol negotiation, and then passes connection to correct routed based on vsid passed in negotiation.
  • 191. 201201©2014 Check Point Software Technologies Ltd. | | Dynamic Routing  Full layer-3 dynamic routing are supported in VSX, in Virtual Systems and Virtual Routers.  Supported protocols:  Unicast – OSPF,RIP-v2, BGPv4  Multicast - IGMP,PIM-SM,PIM-DM  Each Virtual Device on each VSX cluster member has to be configured separately since each Virtual Device has its own routing daemon. Read /etc/routed[vsid].conf  Done via Gaia’s standard clish commands, after running “set virtual- system [vsid]”
  • 192. 202202©2014 Check Point Software Technologies Ltd. | | Virtual Device creation stages The following stages are executed as part of Virtual Device creation:  License validation (Additive license).  Update context database with Virtual Device information $CPDIR/conf/ctxdb.C)  Create Virtual Device directories and soft-links: - $CPDIR/CTX/CTX00xxx/conf - $FWDIR/CTX/CTX00xxx/log, database, …  Create Virtual Device registry  Create initial policy for the VS  Create the OS VRF instance  Start VS processes – FWK, CPD, FWD, etc.  Pulls certificate for VS
  • 193. 203203©2014 Check Point Software Technologies Ltd. | | VSX Upgrade Procedure Upgrade steps VSX Gateway to R77: 1. Install R77 on the VSX Gateway 2. Reboot the VSX Gateway. 3. Close SmartDashboard. 4. Upgrade the VSX Gateways in the Security Management server. a) From the Security Management server CLI, run vsx_util upgrade. b) Do the on-screen instructions. 5. Push the configuration to the VSX Gateways. Do these steps for each VSX Gateway or cluster member. a) Run vsx_util reconfigure. b) Do the on-screen instructions. The existing security policy is installed and configured on the upgraded VSX Gateway and this message is shown: Reconfigure module operation completed successfully c) Reboot the VSX Gateway. 6. Install the necessary licenses.
  • 194. 204204©2014 Check Point Software Technologies Ltd. | | Optimal Service Upgrade  OSU provides a solution for upgrading a VSX cluster and Security Gateway cluster to R77 without losing connectivity  Two cluster members are used to maintain connectivity, while you upgrade all the other VSX cluster members
  • 195. 205205©2014 Check Point Software Technologies Ltd. | | Optimal Service Upgrade procedure 1. For R67.10 VSX Gateways - Install the Optimal Service Upgrade hotfix on a cluster member. 2. Disconnect all old cluster members from the network, except for one cluster member. 3. Install R77 on all the cluster members that are not connected to the network. 4. On the old cluster member, run 'cphaosu start' 5. Reconnect the SYNC interface of one new cluster member to the network. 6. Move traffic to the new cluster member that is connected to the network. Do these steps: a) Make sure the new cluster member is in ready state. b) Connect the other new cluster member interfaces to the network. c) On the new cluster member, run 'cphaosu start' d) On the old cluster member, run 'cphaosu stat' The network traffic statistics are shown. e) When the old cluster member does not have many connections, run 'cphaosu finish' 7. On the new cluster member, run 'cphaosu finish' 8. Disconnect the old cluster member from the network. 9. Reconnect the other new cluster members to the network one at a time. Do these steps on each cluster member: a) Run cphastop b) Connect the new cluster member to the network. c) Run cphastart 10. Upgrade the old cluster member and reconnect it to the network.
  • 196. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 7
  • 197. ©2014 Check Point Software Technologies Ltd. | VSX R77 Debug & Troubleshooting
  • 198. 208208©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF)11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 199. 209209©2014 Check Point Software Technologies Ltd. | | Management Debugging
  • 200. 210210©2014 Check Point Software Technologies Ltd. | | Debugging VSX - fwm  Process fwm is the Management server main process  All fwm debug messages are written to $FWDIR/log/fwm.elg  VSX provisioning module – vsxm is implemented as a COM object within the fwm process
  • 201. 211211©2014 Check Point Software Technologies Ltd. | | fwm debug – debug flags  TDERROR is an error logging infrastructure used for reporting debug messages  Messages are printed to console or to an error log file. Messages have topics and severity levels assigned to them.  There is a way to enable different debugging "filters" at runtime  VSX Debugging useful debug flags:  VSX provisioning and vsx_util: TDERROR_ALL_VSXM  Policy installation: TDERROR_ALL_INSTMGR
  • 202. 212212©2014 Check Point Software Technologies Ltd. | | fwm debugs – how to  How to turn debugs on:  Signal the fwm process to set its debugs on fw debug fwm on TDERROR_ALL_ALL=INFO  Set the debug flag and restart the process Export TDERROR_ALL_ALL=INFO Restart fwm process  Turning debugs off:  This should work: ► fw debug fwm TDERROR_ALL_ALL=0 ► fw debug fwm off  In case it doesn’t work - restarting the process will do the job
  • 203. 213213©2014 Check Point Software Technologies Ltd. | | Fwm debugs - cont  The debugs output will be written to the file: $FWDIR/log/fwm.elg  For Provider-1, the debugging has to be set in the DMS context. The debug output file will also exist per DMS.  VSX provisioning debugs will appear in main DMS  Policy installation debugs will appear in target DMS
  • 204. 214214©2014 Check Point Software Technologies Ltd. | | Policy installation CLI  Install policy from CLI:  fwm load <policy_name> target
  • 205. 216216©2014 Check Point Software Technologies Ltd. | | Debugging SIC  cpca – certificate authority process  fw debug cpca on TDERROR_ALL_ALL=5  Useful command line:  Revoking a certificate in the management ► cpca_client revoke_cert -n <sic_name>  An example for the SIC name for Virtual System VS1e on Member ec1: "cn=ec1_vs1e,o=DMS1..9jdypf"  To find the SIC name for a certain object: ► cpca_dbutil print $FWDIR/conf/InternalCA.db | grep <object_name>
  • 206. 217217©2014 Check Point Software Technologies Ltd. | | SmartView Monitor  SmartView Monitor  Various counters (Dropped, accepted, rejected…) available per VS  Real time monitoring (Top Connections , Users…) available per VS  SNMP  Chkpnt.mib available in the VSX module under $CPDIR/lib/snmp  OID for VSX queries 1.3.6.1.4.1.2620.1.16…  All VS are queried via the only management IP (of the VSX GW)
  • 207. 218218©2014 Check Point Software Technologies Ltd. | | Module Debugging
  • 208. 219219©2014 Check Point Software Technologies Ltd. | | vsx stat  See the status of the VSX and Virtual System:
  • 209. 220220©2014 Check Point Software Technologies Ltd. | | OS sniffer  tcpdump –i <if name> expression  Example: tcpdump –I eth2.11 arp or icmp
  • 210. 221221©2014 Check Point Software Technologies Ltd. | | Firewall monitor fw monitor [–v <vsid>] [-e expression]  Example: fw monitor –v 4 –e ‘port(520) and ip_p=17,accept;’
  • 211. 222222©2014 Check Point Software Technologies Ltd. | | Firewall tables Per context command. fw [-i k] tab -t table_name [-s] Example - obtain vs4 connections table: fw tab –t connections -s
  • 212. 223223©2014 Check Point Software Technologies Ltd. | | Kernel debugs  Setting Kernel debugs:  fw [-i k] ctl zdebug [-v "<vs ids>"|all] [-x] [-m <module>] [+|- <debug_flags> ]  Usage example: ► fw ctl zdebug –vs 1 + conn ld ► fw ctl zdebug –m cluster + forward ► fw –i k ctl zdebug (dispatcher debugging only)  See all possible debugs: ► fw ctl debug --help
  • 213. 224224©2014 Check Point Software Technologies Ltd. | | Kernel debugs – debug drop  Kernel debug drop shows the packets that are dropped with the reason:
  • 214. 225225©2014 Check Point Software Technologies Ltd. | | ClusterXL debugs  Get Cluster status  cphaprob [-vs vsid] stat (VS0 shows global state)  See the member interfaces status  cphaprob [-vs vsid] stat –a if  Advanced debugging:  cphaprob [-vs vsid] list  Down a member – useful to test failovers  clusterXL_admin up/down
  • 215. 226226©2014 Check Point Software Technologies Ltd. | | ClusterXL – Cont.  cphaprob stat output:
  • 216. 227227©2014 Check Point Software Technologies Ltd. | | SecureXL fwaccel –vs <vsid> {conns|templates|stat|on|off}
  • 217. 228228©2014 Check Point Software Technologies Ltd. | | SecureXL – debugs  Setting debugs:  fwaccel dbg  Performance Pack debugs:  sim dbg [-m <...>] [resetall | reset | list | all | mask | +/- <flags>]  The output file is /var/log/messages unless a buffer was allocated using fw ctl debug –buf <buffer size>
  • 218. 229229©2014 Check Point Software Technologies Ltd. | | CPD debugs  Useful in debugging Push configuration, SIC issues, Policy installation  Turning on CPD debugs:  cpd_admin debug on[TDERROR_ALL_ALL=5]  The output is written to:  $CPDIR/log/cpd.elg
  • 219. 230230©2014 Check Point Software Technologies Ltd. | | Fetching policy  Fetching the last installed policy:  fw [-vs <vsid>] fetch local  Fetching the last policy that failed to be installed  fw fetchlocal -d $FWDIR/state/__tmp/FW1/  Unloading the policy:  fw [-vs <vsid>] unloadlocal  Unload policy from all Virtual Systems:  fw vsx unloadall
  • 220. 231231©2014 Check Point Software Technologies Ltd. | | Fetching Configuration  Fetching configuration:  fw vsx fetch
  • 221. 232232©2014 Check Point Software Technologies Ltd. | | Fetching configuration – cont.  Fetching configuration for a specific Virtual System:  fw vsx fetchvs <vsid>  Fetching the last configuration that failed to be installed  fw vsx fetch -v lastbad  Verify that configuration is updated  fw vsx fetch –n
  • 222. 233233©2014 Check Point Software Technologies Ltd. | | NCS  See the NCS script for a specific Virtual Device:  fw vsx showncs <vsid> Shows the part of local.vsall that is relevant for VS with vsid 1
  • 223. 234234©2014 Check Point Software Technologies Ltd. | | SIC  Resetting the SIC on the VSX Gateway/Cluster:  cp_conf sic init <new OTP>  Resetting SIC on a specific Virtual System:  fw vsx sicreset (per context command) Manually pulling the certificate for a specific Virtual System(per context command):  cp_pull_cert -d -h <mgmt_ip> -n <vs_name For example: - “cp_pull_cert -d -h 172.16.16.145 -n Jack_vs2”
  • 224. 235235©2014 Check Point Software Technologies Ltd. | | Watchdog  Viewing all monitored processes (fwk, cpd, fwd…):  cpwd_admin list  Viewing monitored process of a specific VS:  cpwd_admin list –ctx <vsid>
  • 225. 236236©2014 Check Point Software Technologies Ltd. | | FWK Debugging  FWK is the FW-1 “driver”.  There are many ways to debug FWK:  $FWDIR/log/fwk.elg  fw ctl zdebug –v <fwk VSID>…  gdb/valgrind (or any other U/M debugging tool).
  • 226. 237237©2014 Check Point Software Technologies Ltd. | | Common Error Messages
  • 227. 238238©2014 Check Point Software Technologies Ltd. | | Push configuration common errors  “Failed to configure ecu with the following errors: ecu2 error :Failed to get VSX gateway's name from database.”  Cause: This error occurs when there is no policy installed on the VSX Cluster/Gateway (VSID 0)  Solution: Simply install policy on the VSX Cluster/Gateway
  • 228. 239239©2014 Check Point Software Technologies Ltd. | | Error Scenario Push configuration to VS1 fails View the error in the Report Dialog. Examine the error. Is it coming from the module or the management? Note: errors coming from the module have <module_name: > in the error message Try to manually load and debug the new configuration on the module: fw –d vsx fetch -v lastbad Module error Look for the reason of the error inside the debug prints Management error Turn the fwm debug on, on the relevant DMS Press the “OK” button again
  • 229. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 8
  • 230. ©2014 Check Point Software Technologies Ltd. | VSX R77 Conversion to VSX
  • 231. 242242©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF)11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 232. 243243©2014 Check Point Software Technologies Ltd. | | Agenda  Conversion  Implicit conversion
  • 233. 244244©2014 Check Point Software Technologies Ltd. | | Conversion to VSX  What is conversion to VSX? Conversion is the action of transforming a regular Security gateway/cluster into a VSX gateway/cluster.  When conversion is used? The conversion mechanism is used when a user wishes to change it’s security gateway/cluster to a VSX gateway/cluster. or when the user creates a VSX gateway/cluster from a clean installed gateway/s.  Where the conversion is taking place? The Conversion is done in the management database and for every gateway/s.
  • 234. 245245©2014 Check Point Software Technologies Ltd. | | Conversion to VSX  How to convert Security gateway to VSX ?  Open SmartDashboard.  From the Network Objects tree, right-click the Security Gateway or cluster and select Convert to VSX. The Welcome window opens.  Click ‘Next’  The Compatibility Check window opens. The wizard makes sure that the Security Gateway or cluster is compatible with VSX.  Click ‘Convert’  The Conversion Process window opens.  Click ‘Finish’  The Converting window is shown as the management database is updated.
  • 235. 246246©2014 Check Point Software Technologies Ltd. | | Conversion to VSX How conversion is done?  The conversion command is initiated by the management.  In order to communicate with the gateways, the management is using an infrastructure called cprid.  The management initiates a conversion script for every member called “set_fw_opt_mode.bash” the script does not run simultaneously in every member, the management waits until one member is done, and then initiates the script at the next member, the script is located at the gateway in $FWDIR/bin directory.  The script stops some firewall processes and removes kernel modules.  Two flags in the registry indicating whether the machine is a VSX machine, are changed.  The modules and the processes related to the VSX are turned on. The whole conversion is done without reboot.
  • 236. 247247©2014 Check Point Software Technologies Ltd. | | Conversion to VSX stages  In a regular conversion to VSX the mechanism goes through the following stages.  Compatibility Check - GUI Compatibility Check  Firewall must be on  blades that are not supported in VSX must be off( Mobile access, Anti-spam, DLP…)  Legacy blades must be off ( URL filtering, Traditional Anti-Virus ….) - Management Compatibility Check  check that there is only one sync interface.  Check that the interface names are the same for the members and the cluster.  Check that the members IPs are from the same subnet as the cluster IP.
  • 237. 248248©2014 Check Point Software Technologies Ltd. | | Conversion to VSX stages  Check connectivity to the gateways.  If it is a cluster - Set the conversion order of the members ( the active member is last in order to avoid connectivity loss).  Run the conversion script for every member.  Script stages:  Gateway Compatibility Check ► Check that the FW module in installed ► Check that there are no virtual devices. ► Check that the interfaces type is compatible ( ethernet, vlan, bond, loopback). ► Check that there are no aliases. ► Check that IPV6 is not used. ► Check that source base routing is disabled.  Create a timeout auto rollback script  Stop networking  Stop firewall processes  Remove firewall modules from the kernel ( fw, vpn, sim).  Change the registry flags VSX and USERMODE to on ( most important ).
  • 238. 249249©2014 Check Point Software Technologies Ltd. | | Conversion to VSX stages  Script stages (continue):  Load firewall drivers.  Start VSX processes.  Start networking.  Call post install hooks ( configuring VSX mode in the clish and enabling the vsenv command )  The management connects to the gateway and kill the self rollback script called “converter_terminator”.  Update management database ( Create vs_slot objects ).
  • 239. 250250©2014 Check Point Software Technologies Ltd. | | Conversion to VSX terminator  The terminator is a script spawned from the conversion script that sleeps for 9 minutes.  It was designed to reboot the gateway after the sleep if the connectivity to the management is lost and the reconnection attempts failed.  Two script at the gateway startup sequence are called in order to rollback the gateway to it’s former configuration ( before the conversion ).  If the connection to the gateway was restored The management sends a remote kill command to the terminator script.
  • 240. 251251©2014 Check Point Software Technologies Ltd. | | Conversion to VSX log A log is created at the gateway at /var/log/conversion_%day_%time. Example: cat /var/log/conversion_25_18_12_18.log log:[0] checking prerequisites log:[0] obtaining current firewall status and operation mode status log:[0] checking if the requested mode vsx/um is already set log:[0] passed prerequisites log:[1] Successfully created rollback script log:[2] succeeded to create terminatior log:[3] succeeded to start terminatior log:[4] stopping networking log:[4] networking stopped log:[5] stopping routed log:[5] adding ctx column to watchdog log:[5] executing cpstop log:[5] cpstop operation done
  • 241. 252252©2014 Check Point Software Technologies Ltd. | | Conversion to VSX log cont. log:[6] setting appropriate variables in registry for operation mode log:[6] setting appropriate variables in registry for firewall mode log:[6] mode changed to vsx/um log:[7] executing cpstart log:[7] starting routed log:[7] cpstart operation done log:[8] starting networking log:[8] networking started log:[9] running post script hooks log:[9] executing post script /opt/CPsuite-R77/fw1/scripts/post_conversion_hooks//dbset_hook.bash log:[9] executing post script /opt/CPsuite-R77/fw1/scripts/post_conversion_hooks//vsenv_hook.bash log:[9] total conversion time: 55 seconds
  • 242. 253253©2014 Check Point Software Technologies Ltd. | | Implicit Conversion to VSX Implicit conversion  Implicit conversion is done when creating a new VSX cluster/gateway object at the management.  Although the gateways are not VSX, they are converted to a VSX gateways.  In implicit conversion there are no compatibility checks and no networking restarts.  All the scripts run simultaneously.  At the end a vsx_slot object is created at the management.  The script for implicit conversion is called “gw_to_vsx” and it located at $FWDIR/bin.
  • 243. 254254©2014 Check Point Software Technologies Ltd. | | Implicit Conversion to VSX log A log is created at the gateway at /var/log/gw_to_vsx.log Example: cat /var/log/gw_to_vsx.log. Wed Jul 25 19:14:53 IDT 2012: converting module from gw to cluster Wed Jul 25 19:14:53 IDT 2012: Recieved the command convert. Wed Jul 25 19:14:53 IDT 2012: Stopping all processes. Wed Jul 25 19:15:16 IDT 2012: Removing drivers. Wed Jul 25 19:15:21 IDT 2012: Starting all processes and drivers. Wed Jul 25 19:16:10 IDT 2012: Verifying... Wed Jul 25 19:16:11 IDT 2012: Verification: Ok. Wed Jul 25 19:16:11 IDT 2012: running post script hooks Wed Jul 25 19:16:11 IDT 2012: executing post script /opt/CPsuite- R77/fw1/scripts/post_conversion_hooks//dbset_hook.bash Wed Jul 25 19:16:11 IDT 2012: executing post script /opt/CPsuite- R77/fw1/scripts/post_conversion_hooks//vsenv_hook.bash Wed Jul 25 19:16:11 IDT 2012: total conversion time: 78 seconds Wed Jul 25 19:16:11 IDT 2012: conversion done successfully! Wed Jul 25 19:16:15 IDT 2012: Received the command terminator_stop.
  • 244. 255255©2014 Check Point Software Technologies Ltd. | | Summary  Conversion is done when changing a gateway/cluster to a VSX cluster.  Implicit conversion is initiated when creating a new vsx gateway/cluster object at the management.  Non implicit conversion is initiated when choosing the “convert to VSX” at the Smarthdashboard.
  • 245. ©2014 Check Point Software Technologies Ltd. | Thank you ! Please proceed to lab 9
  • 246. ©2014 Check Point Software Technologies Ltd. | Annex VSX Layer 2 HA
  • 247. 258258©2014 Check Point Software Technologies Ltd. | | Course Timetables Day 1 Day 2 Day 3 9:00 Course Introduction VSX Clustering VSX Conversion 10:00 R77 VSX Introduction vsx_utill Gaia VS CTX & New Features (Conversion, SNMP, JF) 11:00 12:00 Mgmt. Implementation Gaia VSX Intro 13:00 Lunch Break 14:00 VSX Networking GW Implementation Open Questions 15:00 16:00 VSX CoreXL Affinity & Memory RC Debug & Troubleshooting 17:00
  • 248. 259259©2014 Check Point Software Technologies Ltd. | | Agenda  Spanning Tree Protocol  STP Bridge Mode  Limitations of STP Bridge Mode  Active/Standby Bridge Mode (A.K.A. Donald)  Active/Active Bridge mode with LACP
  • 249. 260260©2014 Check Point Software Technologies Ltd. | | Spanning Tree Protocol
  • 250. 261261©2014 Check Point Software Technologies Ltd. | | Spanning Tree Protocol  Why use STP?  To build redundant layer-2 networks  What is STP?  Allows switches to communicate with each other to discover Layer-2 loops and activate an algorithm to create a loop-free topology.  Two main stages of operation  Electing a Root switch ► Each switch has a MAC address and a configurable priority number  Determining and verifying the topology of the network ► Sending Bridge Protocol Data Units (BPDU) packets ► 2 second interval
  • 251. 262262©2014 Check Point Software Technologies Ltd. | | Phase 1: Root Election My ID is: AA:AA:AA:AA:AA:AA Election! My ID is: DD:DD:DD:DD:DD:DD My ID is: CC:CC:CC:CC:CC:CC My ID is: BB:BB:BB:BB:BB:BB Each switch can initiate an election
  • 252. 263263©2014 Check Point Software Technologies Ltd. | | Phase 1: Root Election I’m the root! OkOk Ok The switch with the lowest ID is chosen as root
  • 253. 264264©2014 Check Point Software Technologies Ltd. | | Phase 2: Sending BPDUs 19 19 38 38 I found a loop! Root Sender ID is: CC:CC:CC:CC:CC:CC Sender ID is: BB:BB:BB:BB:BB:BB I will block this port B 1 2 B 4 DC A 3
  • 254. 265265©2014 Check Point Software Technologies Ltd. | | Cluster in STP Bridge Mode
  • 255. 266266©2014 Check Point Software Technologies Ltd. | | STP Bridge Mode  Similar to 3rd party mode  Load Sharing decisions done by STP  Both members are Active  No CCP on interfaces  Link State only  Provides High Availability  Does not provide Load Sharing in STP  Can provide Load Sharing with PVST – not easy to configure
  • 256. 267267©2014 Check Point Software Technologies Ltd. | | STP Bridge Mode Root A A B Processing All traffic Processing some of the traffic Traffic arrives to switch Traffic blocked by switchTraffic is sent but dropped because the port is blocked
  • 257. 268268©2014 Check Point Software Technologies Ltd. | | STP Bridge Mode Limitations
  • 258. 269269©2014 Check Point Software Technologies Ltd. | | Problems in STP Bridge Mode  Works only with STP  1 minute failover timeout (STP)  5 seconds failover timeout (RSTP)  Active/Standby decision determined by STP  Both members handle some of the packets  Unsupported features, like in regular FW-1: ► Active streaming ► VPN ► Authentication ► Security Servers ► NAT  Does not support VSLS
  • 259. 270270©2014 Check Point Software Technologies Ltd. | | Three-Layered Hierarchical Model Access It’s main function is to connect users. Distribution The distribution or policy layer performs the policy-based operations: routing, firewalling. Core The backbone of the network. It should be high-speed and concerned mainly with switching traffic as quickly as possible. LAN Switches Routers Backbone Switches
  • 260. 271271©2014 Check Point Software Technologies Ltd. | | VLAN 10 Deployment Scenario VLAN 20 VLAN 10 VLAN 20 Customer’s requirement is to connect the firewalls to the routers
  • 261. 272272©2014 Check Point Software Technologies Ltd. | | Active/Standby Bridge Mode
  • 262. 273273©2014 Check Point Software Technologies Ltd. | | Active/Standby Bridge Mode  Cluster state dictated by ClusterXL  Standby member drops all traffic  All members do not pass STP  Active member learns MAC addresses  MAC addresses synchronized to standby member  During Failover, switches are updated to forward traffic to newly active member
  • 263. 274274©2014 Check Point Software Technologies Ltd. | | Active/Standby Bridge Mode A S 00:12:00:ab:00:01 eth0 00:12:00:ab:00:02 eth0 00:12:00:ab:00:03 eth1 00:12:00:ab:00:04 eth1 00:12:00:ab:00:05 eth1 00:12:00:ab:00:06 eth1 br_shadow A 00:12:00:ab:00:01 eth0 00:12:00:ab:00:02 eth0 00:12:00:ab:00:03 eth1 00:12:00:ab:00:04 eth1 00:12:00:ab:00:05 eth1 00:12:00:ab:00:06 eth1 br_shadow
  • 264. 275275©2014 Check Point Software Technologies Ltd. | | Analysis  Advantages  Full control of the bridge failover  Instantaneous failover  VSLS can now work in bridge mode  Distribution layer can now be protected  Supports Mixed Mode (bridges connected to a router)  Bridge Interface monitoring  Limitations  STP tree is broken
  • 265. 276276©2014 Check Point Software Technologies Ltd. | | Active/Active Bridge Mode with LACP
  • 266. 277277©2014 Check Point Software Technologies Ltd. | | Active/Active Bridge Mode with LACP  Still experimental. Not officially supported by CP.  All members are active.  Switches behave as external load balancers.  Similar to STP Mode in terms of FW-1 configuration and behavior.
  • 267. 278278©2014 Check Point Software Technologies Ltd. | | LACP  Link Aggregation Control Protocol  Industry standard (802.3ad/802.1AX)  Used to dynamically detect multiple links between switches  Dynamically bond links together to create a single logical link, with more bandwidth and reliability.  Switches send/receive LACP packets to learn topology.  Special procedure required to allow LACP packets to pass through FW-1
  • 268. 279279©2014 Check Point Software Technologies Ltd. | | LACP example LACP negotiation LACP packets LACP packets
  • 269. 280280©2014 Check Point Software Technologies Ltd. | | LACP - Load Balance method  Once a logical link is established, switches send packets on logical link  Choice of physical link done using some algorithm  Non-standard algorithms. Depend on vendor and model.  Usually considers source/destination MAC/IP, or some combination of them.
  • 270. 281281©2014 Check Point Software Technologies Ltd. | | LACP load-balance example
  • 271. 282282©2014 Check Point Software Technologies Ltd. | | LACP with VSX - diagram A B C
  • 272. 283283©2014 Check Point Software Technologies Ltd. | | LACP with VSX  Each member inspects one of physical wires, while working in Bridge Mode.  A VS can inspect untagged traffic, or a specific VLAN.  ClusterXL is almost inactive. Switches decide where to send packets to.  LACP packets pass via all members. (on VLAN #1)
  • 273. 284284©2014 Check Point Software Technologies Ltd. | | LACP with VSX - stickiness  For correct inspection of traffic, the same connection must pass on the same member. (symmetric routing)  It is the responsibility of the administrator to configure the switches in such a way that connections are sticky  Algorithm varies between vendors and models.  Even the order of the cables in the switches may be important.
  • 274. 285285©2014 Check Point Software Technologies Ltd. | | LACP with VSX - failover A B C LACP packets  When a member goes down, LACP packet don’t pass through it. Switches renegotiate and pass around failed member.
  • 275. 286286©2014 Check Point Software Technologies Ltd. | | Analysis  Advantages – Provides Load Sharing – Scalable to multiple members  Limitations – Slow failover. Depends on switch, but usually around 30 seconds. – Requires same algorithm on both switches for stickiness. – No active monitoring by ClusterXL. Only by switches. – Not as scalable as VSLS – no Backup mode to reduce Sync
  • 276. 287287©2014 Check Point Software Technologies Ltd. | | Summary  STP bridge mode is ideal for internal network deployment.  Active-Standby bridge mode is for network perimeter deployment.  Active-Standby bridge mode has wider functionality and feature set.  Active-Active with LACP is generally easy to deploy and provides true LS, but may have slow failovers.
  • 277. ©2014 Check Point Software Technologies Ltd. | Thank you !
  • 278. ©2014 Check Point Software Technologies Ltd. | R77 SNMP Per VS
  • 279. 290290©2014 Check Point Software Technologies Ltd. | | Motivation  In versions prior to R77, VSX GW is capable of reply SNMP requests regarding VS0 statuses and a very limited set of non-VS0 statuses.  The capability of polling data regarding non- VS0 Virtual Devices is important for several reasons: 1. Extended Monitoring Capabilities: Each VS should have similar monitoring capabilities as FW- 1. 2. Error Detection: By using SNMP request in some polling interval, administrators are capable to detect and fix errors.
  • 280. 291291©2014 Check Point Software Technologies Ltd. | | Design Overview  There are two modes of SNMP monitoring that you can use with VSX: 1. Default mode ‒ lets you monitor only VS0. ‒ snmpd0 listens on all interfaces. 2. VS mode ‒ lets you monitor all of the Virtual Systems in the VSX Gateway. ‒ snmpd0 listens on all interfaces, non-snmpd0 listens on loopback and on UDS.  When SNMP agent is enabled, PM starts snmpd0 and a process named snmp_launcher.
  • 281. 292292©2014 Check Point Software Technologies Ltd. | | Supported SNMP Versions  VS mode uses SNMP version 3 to query the Virtual Systems. You can run remote SNMP queries on Virtual Systems in the VSX Gateway without changing the Virtual System environment.  For systems that only support SNMP versions 1 and 2:  You cannot run remote SNMP queries for each Virtual System.  You can only run a remote SNMP query on VS0.  You can use the CLI to change the Virtual System context and then run a local SNMP query on a Virtual System.
  • 282. 293293©2014 Check Point Software Technologies Ltd. | | Enabling VS Mode using CLISH  To enable VS mode on the VSX Gateway: 1. Configure an SNMP v3 user 2. Enable VS mode 3. Start the SNMP agent VSX-Box> add snmp usm user admin security-level authNoPriv auth-pass- phrase zubur123 VSX-Box> set snmp mode vs VSX-Box> set snmp agent on
  • 283. 294294©2014 Check Point Software Technologies Ltd. | | SNMP commands Examples  OS OIDs request  Query from VS context:  Query non-VS0 from VS0 context:  Query non-VS0 via Remote host: [Expert@VSX-Box:2] snmpwalk -v 2c -c public localhost ifDescr [Expert@VSX-Box:0] snmpwalk -n ctxname_vsid2 -v 3 -l authNoPriv -u admin -A zubur123 localhost ifDescr [Expert@Mgmt] snmpwalk -n ctxname_vsid2 -v 3 -l authNoPriv -u admin -A zubur123 172.16.16.77 ifDescr
  • 284. 295295©2014 Check Point Software Technologies Ltd. | | SNMP commands Examples  CP OIDs request:  Query from VS context:  Query non-VS0 from VS0 context:  Query non-VS0 via Remote host: [Expert@VSX-Box:2] snmpwalk -m $CPDIR/lib/snmp/chkpnt.mib -v 2c -c public localhost fwFilterDate [Expert@VSX-Box:0] snmpwalk -m $CPDIR/lib/snmp/chkpnt.mib -n ctxname_vsid2 -v 3 -l authNoPriv -u admin -A zubur123 localhost fwFilterDate [Expert@Mgmt] snmpwalk -m $CPDIR/lib/snmp/chkpnt.mib -n ctxname_vsid2 -v 3 -l authNoPriv -u admin -A zubur123 172.16.16.77 fwFilterDate
  • 285. 296296©2014 Check Point Software Technologies Ltd. | | SNMP commands Examples  Important OS full trees:  ALL statuses query:  Standard interface table query:  Extended interface table query: snmpwalk -v 2c -c public localhost snmpwalk -v 2c -c public localhost iftable snmpwalk -v 2c -c public localhost ifxtable
  • 286. 297297©2014 Check Point Software Technologies Ltd. | | Troubleshooting 1. Steady state of SNMP per VS should be composed of:  Snmp_launcher process running  snmpd process running under each VRF context. i. VS0 will have a process named 'snmpd'. ii. Non-VS0 will have a process named snmpd_<vsid>. [Expert@VSX-Box:0]# ps fx | grep snmp 5252 ? Ss 0:00 _ /usr/sbin/snmp_launcher 5265 ? S 0:00 | _ snmpd_1 -f -C -c /etc/snmp/vsx-proxy/CTX/1/snmpd.user.conf,/etc/snmp/vsx- proxy/CTX/1/snmpd.local.conf /tmp/snmpd1_uds localhost 5274 ? S 0:00 | _ snmpd_2 -f -C -c /etc/snmp/vsx-proxy/CTX/2/snmpd.user.conf,/etc/snmp/vsx- proxy/CTX/2/snmpd.local.conf /tmp/snmpd2_uds localhost 5323 ? Ss 0:00 _ /usr/sbin/snmpd -f -c /etc/snmp/vsx-proxy/snmpd.vsx.proxy.conf -p /etc/snmp/snmpd.pid
  • 287. 298298©2014 Check Point Software Technologies Ltd. | | Troubleshooting 2. If query to some non-VS0 fails, the following should be verified:  If the request is OS OID – verify that snmpd0 and snmpd_<vsid> exist.  If the request is CP OID – verify that snmpd0 and snmpd_<vsid> exist and CPD of corresponding VS is running. 3. If snmpd0 is query-able via SNMP V1/2 but is not query-able via SNMP V3, check that a USM is configured properly.
  • 288. ©2014 Check Point Software Technologies Ltd. | R77 Gaia and VSX specific commands
  • 289. 300300©2014 Check Point Software Technologies Ltd. | | Gaia and Clish- Overview  Gaia is the next generation operating system, unifying IPSO and SPLAT to support all appliance product lines  Default shell is an IPSO like shell called clish
  • 290. 301301©2014 Check Point Software Technologies Ltd. | | Gaia and Clish- Overview  Gaia uses a WebUI which is available only during the First Time Wizard  All configuration, whether done from WebUI or clish, is saved under /config/active
  • 291. 302302©2014 Check Point Software Technologies Ltd. | | Clish - VSX specific commands  To enable/disable virtualization, use: set vsx on set vsx off  To show virtual system/s show virtual-system all  Default context is VSX-Box. All clish commands are similar to those of regular Gaia OS, but context-dependent. In order to switch the context use: set virtual-system <vsid>  Interface configuration is disabled in VSX mode - set commands are blocked.