cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Philip_W
Philip_W inside VSX Monday
views 2580 6

rename VSX cluster member

Hi Checkmates,Our customer's wants to upgrade his environment from R77.30 to R80.20.Problem is: he has a VSX cluster with cluster members named 'fw1' and 'fw2'. After importing the SMS database to a new R80.20 management server the Validations tab tells us that "more than one object named fw1 exists" (the other being a default service FW1).Long story short: we have to rename VSX cluster member 'fw1' before we can consider upgrading. In my lab I experimented with vsx_util:- vsx_util add_member to add a Dummy gateway- vsx_util remove_member to remove fw1but this can't be used: "A previous remove member operation did not complete for..." because there is no SIC with the Dummy gateway, which also prevents policy installs to the remaining VSX member.TAC told us to use vsx_provisioning_tool (and to contact Professional Services 🤔), but after reading the documentation and testing some commands I don't see how that would work.Anyone?Ph.
ndcosta
ndcosta inside VSX 2 weeks ago
views 168 3 1

Geo Active-active Datacenter firewall architecture

Hi guys, We are checkpoint costumer. Currently we have two VSX clusters in two geographic locations with production and disaster recovery site.In near future we will change this to active-active architecture streching the network in both geographies using Cisco ACI with VxLAN.Can you please advise us with the best scenario for firewall?Do we need two clusters?Can we have firewall instance in both geographies for the same networking "zone". Regards,Nuno
Federico-M
Federico-M inside VSX 3 weeks ago
views 1386 4

VSX Cluster + Bond + Proxy ARP: To VMAC or not to VMAC

Hello,Hope you're doing well, recently I had to design an architecture that supports a VSX cluster of 2 gateways( active/passive) in R80.20 or R80.30We have bonded interfaces and manual NAT entries in many VS. When I started researching about Proxy ARP in VSX I found a blog entry from @Valeri_Loukine about how to approach this design:http://checkpoint-master-architect.blogspot.com/2014/08/setting-proxy-arp-for-bonded-interface.htmlLong story short, you have the following options:Create a Virtual Switch and attach the bond to that virtual device and setup the proxy ARP on the virtual link between the vswitch and the vsystem.Configure VMAC on VSX cluster and add Proxy ARP entries on that VMACLet the bond as it is.As stated in the blog post, solution 2 and 3 are more viable, my question is the following: ¿Which option is the recommended one?From my point of view is always best to deploy as most default as possible, option 3 would be the best, also I had some issues with VMACs.My concern is how Check Point handles the MAC of the bond interface, when you set it up one of the interface's MAC address is chosen and is used by the bond and the N interfaces. However it seems that there was a time when this MAC could change, reffer to SK111675:"MAC address for Bond interface changes after reboot. This affects the Proxy ARP configuration if the client is manually configuring the Bond interface's MAC address in the Proxy ARP.This problem was fixed. The fix is included in:Check Point R80.10Jumbo Hotfix Accumulator for R77.30 - since Take_210"In theory it should be safe to just use de MAC of the bond.Would be great to have your opinion on this matter, Thanks for reading,Federico Meiners
Enyi_Ajoku
Enyi_Ajoku inside VSX 4 weeks ago
views 1046 3

Traffic Engineering

Attached is a brief look of my present architecture. The camera traffic highlighted in blue terminates to the video server for display on the a.a.a.a ip address. On the other hand i have users (using the labeled netscaler as an example) on Vlan B also trying to get access to a.a.a.a.I have BGB established with all switches and from information i have gathered from the network they have bgp/ospf redistribution set up between the multicast switch and blef switch VS5. The issue i have right now is, VS4 firewall is sending all traffic going to vlan A to use the multicast switch as it next hop which should not be the case. This is causing a loop on my network.The attached image shows the right part i want the traffic to go.I have VSX running,i have tried to setup pbr but it is disabled.Would appreciate any insights.Thank You
Ludolfo_Ocfemia
Ludolfo_Ocfemia inside VSX 2019-07-10
views 262 2

VSX Shared Vlan Interfaces and ARP Issue

We are deploying VSX and getting some difficulties implementing it to customer's environment whether we use vSwitch or vRouter.Both VSes need to have an access to shared vlan interfaces (internal & DMZ). eth5 (internal) has 4 vlans and eth6 (DMZ) has 1 vlan only. I believe vSwitch can have only 1 vlan tag, it seems we don't have other options but to use vRouter or create multiple vSwitch for each vlan.The second problem is after creating vSwitch and connecting to VS0 (warp link) with the ip address of 10.10.1.254, the gateway or VS0 is not responding to arp request."arp who-has 10.10.1.254 tell 10.10.1.210" Clearly, that IP belongs to virtual device.Did I miss anything? Any suggestion are welcome and appreciated. I have attached the topology for reference. Thank you.
Valeri_Loukine
inside VSX 2019-07-02
views 490 3
Admin

White Paper - VSX Migration - Moving one VS at a Time

Authors: @Joseph_Audet1 & @Michael_LeFebvr Abstract The article presents a customer case of migrating a large VSX R77.30 cluster to new R80.20 based infrastructure, by moving the security system VS by VS, one at a time, while changing overall topology in the process. For the full list of White Papers, go here.
HS
HS inside VSX 2019-06-28
views 398 2

Cluster XL error applying policies

Hi,I'm trying to setup a clusterXL with two checkpoint firewall 12000series.I'm getting some errors applying policies.the following error is:There is only one interface defined for object XXXXX. At least one more interface must be configured for this object in order to use the Anti-Spoofing feature.At this moment it is affecting all my VSX when we tries a policy installation with virtual IP as Sync.We have a Sync interface with the name bond0 with topology "this network".We have Internal Network with the name bond1.29 with topology "this network".We have mgmt interface with the name mgmt with topology "external" with virtual IP as Private.All interfaces have anti-spoofing active. If we remove it will should resolved this issue ? do we need to configure other interface, with topology ? Many thanks
Kaspars_Zibarts
Kaspars_Zibarts inside VSX 2019-06-12
views 4301 8

VSX upgrade R80.10 to R80.20 - CPUSE or fresh install

Apart from having "fresh slate" and removing old gremlins, are there any other possible reasons to chose fresh install + vsx_util reconfigure over straight CPUSE upgrade on VSX? File system remains the same.. I would prefer simpler approach (CPUSE) unless someone can provide convincing arguments against it 🙂
TheRealDiZ
TheRealDiZ inside VSX 2019-06-12
views 1818 2

Upgrade VSX Cluster from R77.30 to R80.20 with CLEAN INSTALL

Hi Guys, There is a clear SK on how to upgrade VSX from any version to R77.30 : https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk101518 Can I use this sk also for R80.20?Is there any specific documents related to it?Did you guys have already tried this procedure with R80.20 (suggestions/tips)? Many many thanks.. in advance! RealD!Z**
Yuvraj_Mehta
inside VSX 2019-06-11
views 1014 2
Employee

Procedure to upgrade a VSX cluster - R77.XX to R80.20

Users can follow the below procedure, in order to upgrade their VSX cluster from R77.XX to R80.20 (VSLS | In-place upgrade with Zero-downtime) Things to discuss A) Management Server i) Pre-Start Tasks ii) Operation vsx_util upgrade B) VSX Upgrade Stand By Member i) Pre-Start Tasks ii) Upgrade (& Install JHF - optional) iii) Verification iv) Connectivity Upgrade C) VSX Upgrade Active Member i) Pre-Start Tasks ii) Upgrade (& Install JHF - optional) iii) Verification D) Recovery Plan A) Management Server i) Pre-Start Tasks 1) Ensure there are no locks on objects relevant to the VSX upgrade and to show the list of all the locked objects in an R80.20 database, let’s open PostgreSQL on MDS cmd line: # $MDS_TEMPLATE/bin/psql_client cpm postgres 2) To see current locks, run: # select objid, name, dlesession, cpmitable, subquery1.lockingsessionid, subquery1.operation FROM dleobjectderef_data, (SELECT lockedobjid, lockingsessionid, operation FROM locknonos) subquery1 WHERE subquery1.lockedobjid = objid and not deleted and dlesession >=0; 3) To exit out of PostgreSQL: (mandatory!) # \q 4) To remove current locks from Smart Console, go to Manage and Settings, view Sessions, locate the columns where "Locks" and "Changes" are not 0, and publish or discard session as required 5) **Take MDS and Firewalls – Snapshot & Backups before proceeding with the operation below. 6) Ensure Serial Console and/or LOM access is available to cluster members during operations. ii) Operation vsx_util Upgrade 1) SSH to Primary MDS > elevate to expert mode 2) mdsenv x.x.x.x (switch to the context of VSX-Master Domain Server) 3) # vsx_util upgrade > enter x.x.x.x for Management Server IP Address , enter admin credentials when prompted! 4) Select Desired VSX Cluster Object Name in numerical list to upgrade 5) Select yes and the desired version to upgrade to and wait for operations to complete on management (all associated virtual objects will be updated in all associated Domains managing virtual objects tied to this VSX cluster) B) VSX Upgrade Stand By Member i) Pre-start Tasks (along with installing a Jumbo Hotfix) 1) Make sure the CPUSE build is up to date, see: sk92449 2) Upload the image to folder /var/log/tmp 3) Upload the Jumbo Hotfix Take_xx on a same/different directory. 4) Compare the MD5sum of packages 5) To import the file to CPUSE repository: > installer import local /var/log/tmp/<>.tgz > installer import local /var/log/tmp/<JHF>.tgz > quit(exit clish) 6) Ensure that the vsls status reflect all VSs in standby state before proceeding with the standby member upgrade (# vsx_util vsls) ii) Upgrade 1) Run cphaprob state to ensure this member is standby and the peer is active 2) On the ssh session to Standby Member Login into clish Run installer upgrade <image number> Gateway will reboot when complete! Jumbo Install (optional) On the ssh session to Standby Member Login into clish. Run installer verify <number of JHF> Run installer verify <# of Take xx>. (Verification should come clean with no conflicts. If not, fix any issues and then re-run this step) Run installer install <# of Take xx> The gateway will automatically reboot when finished. iii) Verification On the ssh session to Upgraded Standby Member Run cphaprob state (should show cluster state as "Ready") After waiting for a minute or two (depending on database size) policy should be installed automatically. Execute an SSH to Primary Member (non-upgraded) Run cphaprob state (should show "Active" or "Active Attention" and upgraded peer as "Down") iv) Commence Connectivity Upgrade Script (Will sync connections for all VSs) Turn off SecureXL On the ssh session to Primary non-upgraded Active Member Elevate to Expert Mode Run vsenv 0 (to ensure you are in the main VSX GW context) Run fwaccel off -a (This will ensure SecureXL and Templates are disabled to ensure delayed connections are synchronized with peer) Run fwaccel stat -a (to verify SecureXL is disabled) On the ssh session to Standby Go to Expert Mode Run cphacu start cphacu will show connection sync status and inform if ready for failover C) VSX Upgrade Active Member i) Pre-start Tasks 1) Make sure the CPUSE build is up to date, see: sk92449 2) Upload the image to folder /var/log/tmp 3) Upload the Jumbo Hotfix Take_xx on the same directory. 4) Compare the MD5sum of packages 5) To import the file to CPUSE repository: > installer import local /var/log/tmp/<>.tgz > installer import local /var/log/tmp/<JHF>.tgz > quit(exit clish) 6) Ensure that the vsls status reflect all VSs in Active state before proceeding with the active member upgrade (# vsx_util vsls) ii) Upgrade 1) Turn off SecureXL Run fwaccel stat -a (to verify SecureXL is disabled) 2) Failover connections to Standby Upgraded Member – R80.20 On the ssh session to Primary non-upgraded Active Member Run cpstop SSH to standby and run cphaprob state (should show its cluster state as active) Run cphacu stat on standby (For connectivity Upgrade status, should show handling connections) Run cphacu stop on standby (to halt the connectivity upgrade process) 3) On the ssh session to Primary Member get into clish Run installer upgrade <Image number> Gateway will reboot when complete 4) Jumbo install (optional) On the ssh session to Standby Member Get into clish. Run installer verify <number of JHF> Run installer verify <# of Take xx>. (Verification should come clean with no conflicts. If not, fix any issues and then re-run this step) Run installer install <# of Takexx> The gateway will automatically reboot when finished. iii) Verification The state should now show up as Active/Standby We do not expect to see any traffic drops. Ensure that the secureXL is turned on at both nodes D) Recovery Plan 1) Restore the snapshots on all servers in question. Alternatively, 2) Management Server: Run mds_restore 3) VSX Servers: Fresh install First-time wizard Run vsx_util reconfigure from MDS
Maik
Maik inside VSX 2019-06-11
views 2552 5 1

Different DNS server per VS

Hello guys,I'm pretty new when it Comes to VSX deployments and the related VS configuration. I have a quite Basic setup with one VSX cluster consisting out of two physical devices. On top of the VSX cluster we have two VS running (VS #1 and #2). Each VS has two dedicated interfaces. So currently there is not virtual switch or router in place, as there was no need for VS-to-VS communication or shared interfaces.Now to my issue:Basically I just want each VS to use a different DNS server, as per default the DNS config (as well as some other GAiA paramaters) are getting synched from VS0. The issue is, that once a change in clish of VS2 is made (regarding DNS) this is also getting synched to all the other VS (including VS0). So basically I assume that there is not way to have a different dns server entries for each VS...? I found a SK that mentions this problem and offers a solution - but this is only related for the remote access vpn blade and can't be used by any other feature. Without the possibility of configuring one or multiple different dns Servers for each VS I do not see a way to get any updates or the proxy feature working, as the gateway itself needs to send dns queries here.It is also not wanted to have a shared dns in this environment as each VS should work completely independent from the other. So even if I adjust the routing so that VS2 can reach the DNS of VS0 no solution is met.I read the VSX admin guide and could not find any word regarding this issue - so it could be the case that I overlooked something. Hopefully someone can point me in the right direction. 🙂Regards,Maik
Andreas
Andreas inside VSX 2019-06-09
views 1272 1

VSX route propagation with more then one vSwitch

Hi allI have a question to the feature "propagate route to adjacent Virtual Devices".Lets assume we have three external vs: Inbound-vs, Outbound-vs and VPN-vsThis three VS are in a vSwitch sandwich, one vSwitch for the external subnet and one for internal transit LAN leading to internal VS with internal networks.The question is now: How does Check Point decided through which of the two vSwitch traffic is routet from one DMZ to the other? (Random, vs-id, higher ip, ...)In our setup the routes are propagated through the external vSwitch. This works as consequently for all interfaces the external vSwitch is chosen and no asynch routing occurs. From a security point of view and also architectural considerations, this is not the desired path. For example traffic is coming encrpyted over VPN to the VPN-vs and is sent clear text over the external interface to the DMZ of the Outbound-vs. Assuming the two vs are on another physical VSX host, the traffic is sent over a physical switch, which is exposed to the internet. Not so good.Of course, we could disable the feature and manually route through the internal transit vSwitch. As of now, it looks like we have to go that way.Is there a way to force check point to choose the internal vSwitch for the propagated routes?Imho check point should never use an external interface to route traffic. The information, that these interfaces are external is given in the topology. That might be an RFE.What do you think about the topic?
Henry_Poole
Henry_Poole inside VSX 2019-06-06
views 1975 2

Deleting VSX interfaces from MDS with a script

Hello,Our environment is R80.20 MDS management with Multiple R77.30 VSX gateways. We have a requirement to migrate the current VSX gateways to another fabric. This is a carefully orchestrated change control - however removing the gateways via smart console is a slow clunky task. Compared to none VSX gateways where we can script the usual 'ifconfig ethx.x down' (not supported in VSX) or interface state off in Gaia. The VSX config for interface changes is pushed down from the MDS server in our case, so my question is - Can this configuration be scripted via the API interface? This would make the process much smoother for me and leave much less room for error...
Francois_Beve
inside VSX 2019-06-05
views 1619 1
Employee

how to show connections for VS1 and VS2 using CPViewInsights

Can you let me know how to see the number of connections in each VS, using CPViewInsight ? At this time, we only see the number of connection for VS0
Chris_Phillips
Chris_Phillips inside VSX 2019-05-09
views 1977 3

R80.x OSPF routes

Can anyone suggest a reliable and painless way of getting the routing tables from a gateway. I'm specifically interested in getting OSPF routes the gateway has learn't but would like to extend to any and all routes the gateway has learnt from any routing protocols. I'm finding it hard to know which fw to add my rules to if i can't determine which subnets are behind it.TIA