cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
General Topics

Have a question and you can't figure out where to post about it after reading All Products and Where to Post About Them? Post it here!

Rob_Napholz
Rob_Napholz inside General Topics yesterday
views 2830 13 1

Delete trail license

How can the first temp/30 day trial license be deleted ?cplic print  -xtrial            14Jul2019   axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcplic del axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Failed to delete licenseI had a ticket open with support, with no luck.I prefer not to have a box in production with a trial license and don't want to wait the 30 daysThe FW does have the actual/correct  license,Thanks Rob
peter_schumache
peter_schumache inside General Topics yesterday
views 119 3

How to filter syslog messages in Smartlog

I configured my gateway to send its syslog messages to the SmartCenter Server according to sk102995. To view the syslog messages in Smrtview Tracker, is says:"In SmartView Tracker log, the informational field will should show "...system daemons syslog_severity..."There is no way to define a query (in R80.20) for the "informational" Field. There is a field "Information", but again, no query available.What did I miss?
Fernando_Lourei
Fernando_Lourei inside General Topics yesterday
views 2956 4 1

Tacacs accounting support

Hi,I have several clusters spread across the globe and i am using Tacacs+ authentication. Does anyone know if checkpoint  R77.30 or R80.10 supports accounting features like send to the tacacs server all the commands and configurations made by the serveral administrators? Thank you
Oscar_David_Gom
Oscar_David_Gom inside General Topics yesterday
views 384 2

VSX VPN with AWS

HI I have a R80.10 VSX cluster, one of my VS is manging our VPNS, today I recevied a request of creating a VPN against AWS, they send us a txt file generated from AWS where indicate the step by step for creating it, the problem started with first step: Creating a Tunnel interface, as we are using VSX, that is not supported, so what we do was: 1. Creating a Star community2. Add as the center my VS and for the satellite the interoperable device configured as usual (Public IP, encryption domain, etc).3. Setting parameters of encryption, etc. as said by txt configuration file from aws. 1. Under Security Policies choose "VPN Communities" and click "New", "Star Community". 2. Choose "General" and provide a name : vpn-0a265dfe8bec93511. 3. For "Center Gateways", add your gateway or cluster. 4. For "Satellite Gateways", add the interoperable devices that you created before. 5. For "Encryption", choose "IKEv1 only". 6. In the "Encryption Suite" section, choose "Custom", "Custom Encryption". 7. Configure the properties as follows: Phase 1 Properties - Internet Key Exchange (IKE) a. Perform key exchange encryption with: aes128 b. Perform data integrity with: sha1 Phase 2 Properties -IPSEC a. Perform IPsec data encryption with: aes128 b. Perform data integrity with: sha1 8. For "Tunnel Management", choose "Set Permanent Tunnels", "On all tunnels in the community". 9. In the "VPN Tunnel Sharing" section, choose "One VPN tunnel per Gateway pair". 10. Expand "Advanced Settings". For "Shared Secret": ************* 11. For "Advanced VPN Properties", configure the properties as follows: IKE (Phase 1) a. Use Diffie-Hellman group: 2 b. IKE SA lifetime: 28800 seconds IPSEC (Phase 2) a. Use Perfect Forward Secrecy: Checked b. IPSEC SA Lifetime: 3600 sec 12. Click OK to close the VPN Window4. Configuring tunnel_keep_alive method for dpd.5. Creating the rule.6. Installing policies.Result: VPN is always Down, so my question is, how to configure a vpn against amazon when i'm using VSX? Thanks.
HeikoAnkenbrand
HeikoAnkenbrand inside General Topics yesterday
views 1181 10 11

R80 - Top 20 Gateway Tuning Tips

SecureXL SecureXL is a software acceleration product installed on Security Gateways. SecureXL network acceleration techniques deliver wire-speed performance for Security Gateways. Performance Pack uses SecureXL technology and other innovative network acceleration techniques to deliver wire-speed performance for Security Gateways. The SecureXL device minimizes the connections that are processed by the INSPECT driver. SecureXL accelerates connections on two ways. SecureXL is implemented either in software or in hardware:       SAM cards on Check Point 21000 appliances       Falcon cards (new in R80.20) on different appliances Tuning Tip: From R80.20 SecureXL is always enabled and can no longer be disabled completely. sk98722 - SecureXL for R80.10 and below sk98348 - Best Practices - Security Gateway Performancesk32578 - SecureXL Mechanism sk153832 - SecureXL for R80.20 and above  R80.x - Security Gateway Architecture (Logical Packet Flow)R80.x - Security Gateway Architecture (Acceleration Card Offloading) SecureXL Connection Templates Feature that accelerates the speed, at which a connection is established by matching a new connection to a set of attributes. When a new connection matches the Connection Template (old name "Accept Template") , subsequent connections are established without performing a rule match and therefore are accelerated. Connection Templates are generated from active connections according to policy rules. Tuning Tip: Accept Templates are enabled by default. sk32578 - SecureXL MechanismPerformance Tuning R80.30 Administration Guide - Connection Templates R80.x - Security Gateway Architecture (Logical Packet Flow)   SecureXL NAT Templates Using SecureXL Templates for NAT traffic is critical to achieve high session rate for NAT. SecureXL Templates are supported for Static NAT and Hide NAT using the existing SecureXL Templates mechanism. Tuning Tip: Enable NAT Templates depending on the situation. sk71200 - SecureXL NAT Templates  R80.x - Security Gateway Architecture (Logical Packet Flow)   SecureXL Drop Templates Optimized Drops feature in R76 and above. Heavy load of traffic that should be dropped causes an increase in the Security Gateway's resource consumption. SecureXL Drop Templates are not created, although this option was checked in SmartDashboard. Tuning Tip: Enable Drop Templates depending on the situation sk90861 - Optimized Drops feature in R76 and above sk66402 - SecureXL Drop Templates  R80.x - Security Gateway Architecture (Logical Packet Flow)   SecureXL Penalty Box The SecureXL penalty box is a mechanism that performs an early drop of packets arriving from suspected sources. This mechanism is supported starting in R75.40VS. The purpose of this feature is to allow the Security Gateway to cope better under high load, possibly caused by a DoS/DDoS attack. A client that sends packets that are dropped by the firewall rulebase or performs violations of the IPS policy is reported to this mechanism. If a client is reported frequently, it would be put in a penalty box. Any packet arriving from this IP address would be dropped by the performance pack at a very early stage. Tuning Tip: Use the SecureXL penalty box if you have DDoS attacks sk74520 - What is the SecureXL penalty box mechanism for offending IP addresses?  R80.x - Performance Tuning Tip - DDoS „fw sam“ vs. „fwaccel dos“   SIM Affinity Association of a particular network interface with a CPU core (either 'Automatic' (default), or 'Static' / 'Manual'). Interfaces are bound to CPU cores via SMP IRQ affinity setting. SIM Affinity in Automatic mode may make poor decisions on multi-core platforms. In addition, some multi-core hardware platforms suffer from an inability to assign IRQs to use all the CPU cores efficiently. Tuning Tip: In special cases the SIM affinity should be set manually.sk61962 - SMP IRQ Affinity on Check Point Security Gateway sk33250 - Automatic SIM Affinity on Multi-Core CPU Systems Performance Tuning R80.30 Administration Guide – Affinity Settings  CoreXL CoreXL is a performance-enhancing technology for Security Gateways on multi-CPU-core processing platforms. CoreXL enhances Security Gateway performance by enabling the processing CPU cores to concurrently perform multiple tasks. CoreXL provides almost linear scalability of performance, according to the number of processing CPU cores on a single machine. The increase in performance is achieved without requiring any changes to management or to network topology. On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated copy, or FW instance, runs on one processing CPU core. These FW instances handle traffic concurrently, and each FW instance is a complete and independent FW inspection kernel. When CoreXL is enabled, all the FW kernel instances in the Security Gateway process traffic through the same interfaces and apply the same security policy. sk98737 – CoreXL sk98348 - Best Practices - Security Gateway Performance R80.x - Security Gateway Architecture (Logical Packet Flow)R80.x - Security Gateway Architecture (Content Inspection)   CoreXL - Dynamic split of CoreXL Dynamic split of CoreXL changes the assignment of  CoreXL SND's and CoreXL firewall workers automatically without reboot in R80.40+.  Now, let's assume the CoreXL SNDs are overloaded, a mathematical formula is used to calculate that a further CoreXL SND is added. In this case a CoreXL firewall worker  will not get any new Connections and the connections are distributed to another CoreXL firewall worker. If there are no more connections running through this CoreXL firewall worker, the core will be used for a new CoreXL SND instance. It also works the other way round. Adding and removing a CoreXL firewall worker Adding and removing a CoreXL SND Balance between CoreXL SND and CoreXL firewall worker GAIA 3.10 kernel only Check Point appliances with 8 cores or more Tuning Tip: Use this function from R80.40 on appliances with 8 cores or more. No SK is available yet. R80.40 - Dynamic split of CoreXL    MultiCore IPsec VPN R80.10 and above introduced MultiCore support for IPsec VPN. Starting in R80.10 Security Gateway, IPsec VPN MultiCore feature allows CoreXL to inspect VPN traffic on all CoreXL FW instances. This feature is enabled by default, and it is not supported to disable it. Tuning Tip: MultiCore IPsec VPN is enabled by default on R80.x gateways. sk104760 - VPN Core sk105119 - Best Practices - VPN Performance sk118097 - MultiCore Support for IPsec VPN in R80.10 and above  MultiCore Support for SSL Introduced in R77.20, SSL MultiCore feature improves SSL performance of Security Gateway. SSL MultiCore feature is based on Check Point CoreXL technology, which enhances Security Gateway / VSX Gateway performance by enabling the CPU processing cores to concurrently perform multiple tasks. Tuning Tip: MultiCore SSL is enabled by default on R80.x gateways. sk101223 - MultiCore Support for SSL in R77.20 and above  AES-NI Intel‘s AES New Instructions AES-NI is a encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data in many processor familys. Better throughput can be achieved by selecting a faster encryption algorithm. For a comparison of encryption algorithm speeds. Relative speeds of algorithms for IPsec and SSL. AES-NI is Intel's dedicated instruction set, which significantly improves the speed of Encrypt-Decrypt actions and allows one to increase AES throughput for: Site-to-Site VPN, Remote Access VPN, Mobile Access, HTTPS Interception The general speed of the system depends on additional parameters. Check Point supports AES-NI on many appliances, only when running Gaia OS with 64-bit kernel. On these appliances AES-NI is enabled by default. AES-NI is also supported on Open Servers. Comprised of seven new instructions, AES-NI gives your environment faster, more affordable data protection and greater security. Tuning Tip: Enable AES-NI in the BIOS. sk73980 - Relative speeds of algorithms for IPsec and SSL R80.x - Performance Tuning Tip - AES-NI   Firewall Priority Queues Packets could be dropped by Firewall when CPU cores, on which Firewall runs, are fully utilized. Such packet loss might occur regardless of the connection's type (for example, local SSH or connection to Security Management Server server). The Firewall Priority Queues are disabled by default. The Priority Queues (PrioQ) mechanism is intended to prioritize part of the traffic, when we need to drop packets because the Security Gateway is stressed (CPU is fully utilized). Tuning Tip: Use it depending on the situation.sk105762 - Firewall Priority Queues in R77.30 / R80.10 and above  Multi-Queue By default, each network interface has one traffic queue handled by one CPU. You cannot use more CPU cores for acceleration than the number of interfaces handling traffic. Multi-Queue lets you configure more than one traffic queue for each network interface. For each interface, more than one CPU core is used for acceleration. Multi-Queue is relevant only if SecureXL is enabled. Tuning Tip: Enable multi-queueing on 10/40/100 Gbit/s interfaces. Performance Tuning R80.30 Administration Guide – Multi-Queue R80.x - Performance Tuning Tip - Multi Queue   Dynamic Dispatcher CoreXL is a performance-enhancing technology for Security Gateways on platforms with multiple CPU cores. CoreXL enhances Security Gateway performance by enabling the processing CPU cores to concurrently perform multiple tasks. On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated copy, or Firewall instance, runs on one processing CPU core. These Firewall instances handle traffic concurrently, and each Firewall instance is a complete and independent Firewall inspection kernel. When CoreXL is enabled, all the Firewall kernel instances in the Security Gateway process traffic through the same interfaces and apply the same security policy. The CoreXL software architecture includes the Secure Network Distributor (SND). The SND is responsible for: Processing incoming traffic from the network interfaces Securely accelerating authorized packets (if SecureXL is running) Distributing non-accelerated packets or Medium Path packets among CoreXL FW kernel instances - this functionality is also referred to as dispatcher Traffic received on network interface cards (NICs) is directed to a processing core running the SND. The dispatcher is executed when a packet should be forwarded to a CoreXL FW instance (in Slow path and Medium path - see sk98737 for details) and is in charge of selecting the CoreXL FW instance that will inspects the packet. In R77.20 and lower versions, traffic distribution between CoreXL FW instances is statically based on Source IP addresses, Destination IP addresses, and the IP 'Protocol' type. Therefore, there are possible scenarios where one or more CoreXL FW instances would handle more connections, or perform more processing on the packets forwarded to them, than the other CoreXL FW instances. This may lead to a situation, where the load is not balanced across the CPU cores, on which the CoreXL FW instances are running. Tuning Tip: Use Dynamic Dispatcher depending on the situation.sk105261 - CoreXL Dynamic Dispatcher in R77.30 / R80.10 and above  SMT (Hyper Threading) Hyper Threading Technology is a form of Simultaneous Multithreading Technology (SMT) introduced by Intel. Architecturally, a processor with Hyper-Threading technology consists of two logical processors per core, each of which has its own processor architectural state. Each logical processor can be individually halted, interrupted or directed to execute a specified thread, independently from the other logical processor sharing the same physical core. SMT (also called HyperThreading or HT) is a feature that is supported on Check Point appliances running Gaia OS. When enabled, SMT doubles the number of logical CPUs on the Security Gateway, which enhances physical processor utilization. When SMT is disabled, the number of logical CPUs equals the number of physical cores. SMT improves performance up to 30% on NGFW software blades such as IPS, Application & URL Filtering and Threat Prevention by increasing the number of CoreXL FW instances based on the number of logical CPUs. Tuning Tip: Enable SMT on appliances and disable SMT on open server. sk93000 - SMT (HyperThreading) Feature Guide R80.x - Performance Tuning Tip - SMT (Hyper Threading)   HTTPS Interception vs. SNI With enabled HTTPS interception: If the https interception is enabled, the parameter host from http header can be used for the url because the traffic is analyzed by active streaming. Check Point Active Streaming (CPAS) allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.). An application is register to CPAS when a connection start and supply callbacks for event handler and read handler. CPAS breaks the HTTPS connection and others into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.)  Without enabled HTTPS interception (SNI is used): If the https interception is disabled, SNI is used to recognize the virtual URL for application control and url filtering. It is less resource intensive than HTTPS interception Tuning Tip: Prefer SNI to HTTPS interception, if you only use application control and url filtering. sk108202 - HTTPS Inspection URL Filtering using SNI for HTTPS websites.pdf R80.20 - SNI vs. enabled HTTPS Interception    Network Interfaces and Server Hardware Only use certified hardware for open server and network cards. Prevent network and packet  errors on the network cards. Tuning Tip: Use supported hardware only and avoid network card issus. HCL R80.x - Performance Tuning Tip - Intel Hardware   Interface Errors   RX-ERR: Should be zero.  Caused by cabling problem, electrical interference, or a bad port.  Examples: framing errors, short frames/runts, late collisions caused by duplex mismatch.Tuning Tip:  First and easy check duplex mismatch RX-OVR: Should be zero.  Overrun in NIC hardware buffering.  Solved by using a higher-speed NIC, bonding multiple interfaces, or enabling Ethernet Flow Control (controversial).  Tuning Tip:  Use higher speed NIC's or bond interfacesRX-DRP: Should be less than 0.1% of RX-OK.  Caused by a network ring buffer overflow in the Gaia kernel due to the inability of SoftIRQ to empty the ring buffer fast enough.  Solved by allocating more SND/IRQ cores in CoreXL (always the first step), enabling Multi-Queue, or as a last resort increasing the ring buffer size. Tuning Tip:  Use more SND/IRQ cores in CoreXL sk61962 - SMP IRQ Affinity on Check Point Security Gateway sk33250 - Automatic SIM Affinity on Multi-Core CPU Systems Performance Tuning R80.30 Administration Guide – Multi-Queue R80.x - Performance Tuning Tip - Multi Queue
HeikoAnkenbrand
HeikoAnkenbrand inside General Topics yesterday
views 1308 15 26

Update R80.20+ Security Gateway Architecture (Logical Packet Flow)

Chapter More interesting articles: - R80.x Architecture and Performance Tuning - Link Collection- Article list (Heiko Ankenbrand) Flowchart news in R80.20 and above SecureXL has been significantly revised in R80.20. This has also led to some changes in "fw monitor". There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine. Now SecureXL works in part in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing. The packet flow in R80.20+ is a little bit different from the flow lower than R80.20. Now it is possible to use async SecureXL and other new functions. This figure shows the new features with the reinjection of SecureXL packages. SecureXL supportes now also Async SecureXL with Falcon cards. That's new in acceleration high level architecture (SecureXL on Acceleration Card): Streaming over SecureXL, Lite Parsers, Scalable SecureXL, Acceleration stickiness... More informations here: R80.x Security Gateway Architecture (Logical Packet Flow) Whats new in R80.20+: Now there are several SecureXL instances possible. As a result, packets are reinjected with the new SecureXL ID into the correct SecureXL instance again after they have been allowed by access template or rule set. After the packet has been reinjected, the SecureXL ID is added to the SecureXL connetion table and the packet is forwarded to the correct SecureXL instance. Therefore the flow is slightly different to older version before R80.20. This new mechanism also offers the possibility to transfer packets into a new SecureXL instance on Falcon cards. PXL vs. PSLXL - Technology name for combination of SecureXL and PSL. PXL was renamed to PSLXL in R80.20. This is from my point of view the politically correct better term. For the new acceleration Falcon card architecture with R80.20+ and SecureXL offloading read this article: R80.x Security Gateway Architecture (Acceleration Card Offloading):
Tuannnnnnnnn
Tuannnnnnnnn inside General Topics Monday
views 105 3

Integration with Cisco ACI in unmanaged PBR mode

Hi CheckMates,We're in the process of migrating from a traditional DC network to ACI, with a pair of ClusterXL HA CheckPoint SG as the gateway. The SG is currently at R77, but we're also about to upgrade to R80.We're about to move all gateway to the Cisco ACI (leaving only one logical sub-interface connecting the ACI leaves to the SG, as a requirement of PBR). On the SG there's gonna be only one default route out.As traffic is gonna be entering and exiting on the same sub-interface, just want to ask if CheckPoint does support this "one-armed" topology? As far as I know, CheckPoint has an Anti-Spoofing feature - how does it affect the networks behind the sub-interface, as they will not be directly connected to the CheckPoint SG anymore?Also, will changing interfaces affect the existing security rules? I know that Palo Alto is OK with this, Cisco ASA doesn't like that so much, but how does the CheckPoint SG act upon the firewall rules in response to topology change?Thanks heaps! 
John_Fenoughty
John_Fenoughty inside General Topics Monday
views 4024 2 5

Making Skype work properly with HTTPS inspection enabled featuring To Probe Bypass or Not To Probe Bypass

As suggested (By DWA AKA PhoneBoy) in the thread https://community.checkpoint.com/message/27675-re-https-inspection-probe-bypass-to-enable-or-not-to-enable?commentID=276… which discusses HTTPS inspection an general and getting Skype to work without resorting to destination based IP address overrides or disabling HTTPS inspection on 'Skype clients' (a rather impossible concept) in particular here is the document and CSV file which at the time of writing can be used to achieve this.
HeikoAnkenbrand
HeikoAnkenbrand inside General Topics Monday
views 209 1 5

R80.40 EA - Dynamic split of CoreXL

  What is new in R80.40 EA. A new interesting function for performance tuning has been included in R80.40 EA. Dynamic split of CoreXL changes the assignment of  CoreXL SND's and CoreXL firewall workers automatically without reboot. How does this magic happens? Adding and removing a CoreXL firewall worker Adding and removing a CoreXL SND Balance between CoreXL SND and CoreXL firewall worker Work in ClusterXL environments A reboot is not necessary Pre-requisites: GAIA 3.10 kernel (USFW/Kernel only Check Point appliances with 8 cores or more VSX is currently a limitation currently supported on ClusterXL HA currently VSLS is a limitation How does it work? Suppose we have two SND's and 6 CoreXL firewall workers. If no CoreXL SND's and CoreXL firewall workers are overloaded, nothing happens (picture 1). Now, let's assume the CoreXL SNDs are overloaded (picture 2), a mathematical formula is used to calculate that a further CoreXL SND is added. In this case a CoreXL firewall worker 5 will not get any new connections (picture 3) and the connections are distributed to another CoreXL firewall worker for example to the CoreXL firewall worker 4. If there are no more connections running through this CoreXL firewall worker on core two, the core will be used for a new CoreXL SND instance (picture 4) . Now our appliance has three SND's and 5 CoreXL firewall workers.It also works the other way round. Picture 1 - nothing overloadedPicture 2 - SND's overloaded Picture 3 - CoreXL firewall worker stops the processing and distributes the connections.   Picture 4 - new SND is added Please note that functions can change in the GA version. This is only a short description of the EA function.  
columb
columb inside General Topics Monday
views 187 8

Issues with Identity Awareness - some users are not seen and some traffic is incorrectly marked

Hello, I need to deploy IA across few firewalls in order to replace statically assigned IPs with IA-based rules.For the record I'm running 80.30 Take 50 across all of our firewalls.I have 4 collectors and they seems to be talking fine to my Gateways.I have done some investigation on the PDP/PEP and connectivity to the AD - or, actually, Collectors. Long story short I think we can summarise our issue in 2 separate points: Some users are not being recognised as a AD users by PDP. Or they are "lost"Some traffic is marked as initiated by the users but that’s not the case at all as user just logged on to the server. Traffic is not generated by them. I will explain below exactly what I mean by that. In terms of problem number 1:My user (one of many!) is not to be seen by PDP/PEP daemons.I have 2 devices (laptop/PC) and I have logged on to both of them today. I have also done full reboot of my PC and I had confirmation that my trust with the AD was established, all of the log on scripts were run correctly.My user was recognised before – I have logs to prove thisSome other users were recognised before but they are not now (for example my colleague who sits right next to me – I could see his username yesterday but not today. He has definitely logged on to this PC multiple times today)Sometimes I can see user but NOT IP associated with that userLooking at the "Logs & Monitor" tab in SMS Console I can see events related to the "Log in/log out" however looking at "pdp monitor user" I can see user within PDP/PEP Problem 2 manifests itself by marking traffic between servers as USER TRAFFIC.Here is a specific scenario of what happens:Server is sending syslog messages to another server (and this traffic is seen correctly)User A logs in to the server and performs some operations NOT RELATED to the syslog (for example looking at the DHCP configuration)From that point on server marks traffic as sent by the user and goes against user’s ACLs.Only Syslog traffic (514) seems to be marked as the user's traffic.Needless to say that both issues would be a showstoppers to implement this into PROD environment. Please see some details about our setup – I have created a quick script to give us one-page summary about most important features of PDP:   Now, users and machines numbers are taken from this grep:  pdp monitor summary all | grep -c "[u]"    Thank you in advance for your help. I'm not sure what I could be looking into. I do have case open with our 1st line support (before we hit TAC) but that's slow to progress so I'm hoping I can get some help from "the experts in the field" CheersChris
ashish_verma
ashish_verma inside General Topics Monday
views 71 2

NAT issue over VPN

Hello Mates,  We are getting this issue in which the tracker is showing 2 logs for the same traffic (same source and destination port numbers) one is getting encrypted (and accepted) and with the same time stamp another one which is getting dropped at the external interface with reason of address-spoofing. Below are the details:The source is 10.1.4.0/24 and is directly connected to CP firewall. The source is getting natted to IP 194.168.1.153 (subnet 194.168.1.x is not configured on any of the interface of this firewall. The VPN is configured with interoperable object and the tunnel are up. When initiating the traffic with source 10.1.4.233, in the tracker we can see the source is getting natted to 194.168.1.153 and also the traffic is getting encrypted. Just after this log ( with the same timestamp) another drop log is there with source 10.1.4.233, same source port and destination and getting reason is address-spoofing on eth2.530(external interface). On putting tcpdump on eth2.530 we are not getting any hit. On "fw monitor -p all", I can see the traffic (Syn) is passing through the firewall after getting translated, also receiving the reply back (Syn/Ack) to 194.168.1.153 but only i (Pre-inbound) after that no IoO. We have done manual hide nat configuration. Please let me know if any further info required. Thanks in advance.  
markovencelj
markovencelj inside General Topics Monday
views 162 4

checkpoint cluster splitbrain issue

Helo guys.I am searching some kind of official answer regarding Cluster HA (How to avoid split brain) If we have cluster on 2 different locations in HA and L2 DarkFiber link between for all interfaces, vlans,sync, etc.Cluster is in Active/Stdby mode, but customer have Datacenter in active/active mode stretched in both locationsDatacenters are configured to use Witness in azure, which is cloud based and in case of splitbrain (if we totally cut all links between locations), that witness decide which site became off and which remain active - reason is that we don't write data on both sites, because it may come to data corruptionMy question is for CHKP cluster. What happens if we cut all interfaces between them?Do they became active/active? in that case traffic goes through via both clusters which is not good.How do you solve that kind of scenarios to avoid split brain situations.BR
Jozsef_Balogh
Jozsef_Balogh inside General Topics Monday
views 968 1

DHCP server is not active

This issue is solved, I am posting it in case anyone else is experiencing the same problem.One of our customers configured a simple DHCP Relay on a standalone CP3100 gateway running Gaia R77.30, using the new services as per sk104114. Everything was set up correctly, but the dhcp relay was not working. The incoming dhcp requests have been accepted from the clients, but nothing has been forwarded to the relay server, tcpdump did not show any bootp packets exiting on the configured interface. We have ruled out any NAT, policy or routing issues. At this point of troubleshooting we have not done any bootp traces or kernel debugs yet (although it would have been useful).  We found this:> set bootp interface eth2 on> set bootp interface eth2 primary x.x.x.x wait-time 40 on> set bootp interface eth2 relay-to y.y.y.y on> save config> show bootp interface eth2BOOTP: Feature not enabled on eth2 But in the actual configuration we could see the setting enabled (routed.conf):}; bootpgw on { interface eth2 maxhopcount 35 waittime 40 primary x.x.x.x relayto { host y.y.y.y; };  /var/log/messages:[...] xpand[4962]: admin localhost t +routed:instance:default:bootpgw:interface:eth2:waittime 40 [...] xpand[4962]: Configuration changed from localhost by user admin [...] routed[5097]: bootpgw (bootpgw_detect_listener_mode): Relay agent will listen on 0.0.0.0:67 because DHCP server is not active Jun 3 16:06:01 2019 b-schul-ha1 routed[5097]: task_reconfigure reinitializing done  Only a reboot solved the issue, a cpstop/cpstart was not enough.(Reference found in this reddit post.)  
6dd15084-b97a-4
6dd15084-b97a-4 inside General Topics Monday
views 184 2

Cluster Interface not reachable

Hello,I have 2 gateways with cluster Configured. all ports are reachable from both Gateways, we observed that some ports from secondary gateway is not reachable from inside network. but on Mgmt server it is showing as up and running correctly.