Monthly Archives: October 2012


OK, I admit I’m a neewbie with VSX so there may be an easy answer. But I’m sharing these in case others are struggling…or they know the answer.

So I setup a VSX cluster and for the life of me I could not remember if I set it up as a VSLS or HA. I went to the ClusterXL page and guess what, no matter what you choose this page cannot be modified and it always says the same thing:

and cphaprob stat is always set to “active standby” when you’d think it’d be “active active”.

Wellll…look at the cluster mode: VS Failover!!! Ah Haaa, what does that mean Dr. Spock?

SOOOOOO where is the command to figure out what ClusterXL mode I’m really in?

I can’t find it. But this will tell you:


Debugging Confwiz

Started to use confwiz instead of the usual migration tools for migrating domains. Works pretty good. Only problem is when there are problems, not too obvious where it blows up.

This was the magic I used to debug confwiz:

alias df=’fwm debug fwm off TDERROR_ALL_ALL=5′
alias do=’fwm debug fwm on TDERROR_ALL_ALL=5′
mdsenv <cma>
cd log


<import the database>

fgrep ‘E R R O R’  fwm.elg.*

<look for missing variable>

<create missing variable in smartdashboard>

Penalty box for DDOS attacks

Saw this today. I think Watchguard has had this for years. About time.

Too bad its command line only now.

Bypass first time setup

Can’t believe CP did this. When doing remote Lights Out setups, the Mgmt port is configured to Appliances make you use WebUI to configure GAIA/Splat for the first time. But what if you are not on the directly connected net and its a LOM setup? How to you get to if its physically located in Ghana or somewhere?

So how do you directly connect. These guys are brilliant. Thanks.


touch /opt/spwm/conf/wizard_accepted

touch /opt/spwm/conf/wizard_post_install.accepted

when done

rm /opt/spwm/conf/wizard_accepted
rm /opt/spwm/conf/wizard_post_install.accepted

GAIA (sk71000)

touch /etc/.wizard_accepted



VSX design considerations – Eggs In One Basket

VSX is pretty cool as VMware is cool. You can spin up new firewalls in a right-click and have them running in minutes vs dealing with ISO installs and physically installing a system.

Downside: Eggs In One Basket

Obviously if the VSX chassis has an issue, then all VSs inside of it are impacted. Like VMware. If the host has problems, then all the guests have problems. Like marriage, if the wife is not happy…the man is not happy.

But I diverge.

So I am creating a list of VSX design considerations to think about when deploying VSX. I’ll update as life goes on. These are mostly related to MDM, haven’t thought about SmartCenter:

1) Put the policies for all your VSX gateways/chassis in a single domain (VSXDOMAIN) that only admins can get to. These policies are pretty simple like ssh, web, control connections. This way some newbie can’t modify chassis related parameters and rules that impact the whole chassis. You can also then assign specific administrative permissions to  VSXDOMAIN so that only superduper users have access to it. Also prevents newbies from doing an “Install Policy on All Gateways” and installing some random policy from one of the VSs onto your VSX gateway. Boy would that suck or what?

Or maybe more out there but has happened, is that when you mix VSX and VS config information in one domain, then the underlying file system is also hierarchical. If you delete the VSX domain file system, you delete all your VS config information. This is not true if you separate them.

2) Propagate routes: Note that when you update routing tables in SmartDashboard when you save the policy, the routes are immediately injected into the  running VSs even if you don’t do a SAVE. So you might want to think about limiting the propagation of routes if it will be a problem.

Check out this listing of files that changed after I saved the dashboard. THe files contain mostly routing information. These files are also updated with dinking with interfaces and spoofing. Oh yeah, in theory all you have to do is a “Save Policy”, but in reality you probably have to do a push policy. For example routing is suppose to be independent and not need a install policy, but you may run into spoofing issues and so you have to push policy to make it all work. Interfaces and spoofing you have to push policy to make work. I would say for major interface updates like bonding, vlans, give it the old reboot too.

3) VSs are attached to VSX gateway objects. This is a permanent binding, you can’t undo. If you need to rename the VSX gateway object, you basically can’t. You have to have downtime on all VSs as you re-create VSs on new VSX gateway objects.

4) Think about the things that are shared; CPU, time, file system like the /etc directory. All these shared items impact the whole chassis. So if someone deletes the /etc directory or a critical file like resolve.conf, you lose the whole platform. So create least privilege around who can modify these shared items.

5) Along with #4 above. Arp tables. VSX interacts with many clients so it creates huge arp tables. Check out sk43772.

6) Along with #4, watch out for SmartMonitor, cpstat fw -f os, top, fw ctl pstat. They all lie about CPU utilization. VSs share CPUs, but the reporting tools only report on the average of ALL the CPUs.  If the system is configured to use 2 of 12 CPUs, you get the average of all 12 even though the 2 are running at 100%. So your average will be say…. 80% idle.

7) I guess the biggest issue is scope. VSX is fantastic for small little used firewalls.Major gateways with 10s thousands of users or major ecommerce gateways….no. Why? 1) Shared platform – Any virtual system shares the platform. Eggs in one basket.If your lab firewall all of a sudden overwhelms the CPU, then your ecommerce firewall is toast. If an admin types in the wrong command, toast. If  you add interfaces and something goes wrong, toast. 2) Going backwards – VSX is really cool, but it is difficult to go backwards. Yes you can delete virtual systems….but you sit there with your fingers cross praying to gods you didn’t even know exist. And if it blows, get ready to hand edit internal databases. I’ve done it. Sucks. Check Point HAS to fix their DMS database from flat files to a SQL lite database. Right now an object name appears in 100 different places. If the delete or modify goes wrong, it only updates 50 of the 100 and then you hunt for the rest. And pray none are in a binary file.  3) Upgrades. If you never done a VSX upgrade then you won’t appreciate what it takes and how delicate it can be. You really don’t want to do this on a $1million/minute gateway. With ANY virtual system. Just one mans opinion.

That’s what I know for now, stay tuned I’m sure this will get updated as life goes on.


Using WebUI with VSX

Learned this one today. Thanks Jon!

Notice you can’t use WebUI with VSX. Well, make VSX go away.


  1. set vsx on
  2. USE webui
  3. set vsx off

Another day

On the CP Forums I was told that this undocumented feature enables/disables CLI/WebUI editing of networks and interfaces and routes.  All that editing should be done in VSX Dashboard. Haven’t verified this.




VSX – Adding default route for DMI Interface

The VSX admin manual is pretty good, but one thing I hate is when manuals describe concept A in terms of concept B before they define what concept B is. R75.40 Page 14,

“You can choose to use a non-dedicated management interface by connecting a Virtual Router or Virtual Switch to the management interface.”

Oh that’s obvious – VRs and VSs are not even discuss and get this they never go back to discuss what this means.

Anyways in my labs I was stuck trying to figure out how to route the management interface out the external interface. VSX purposefully dead ends the interface so that it is strictly a management interface and should not be routed outside the VSX gateway. I need to do this for NTP/DNS  to my MDS and SmartCenters (and to surf porn and fantasy football…right).

So a couple things:

– Virtual Switches are used to merge multiple VSs into using 1 physical interface
– So VS1/2/3/4 all want to talk to the external physical interface eth0, you are required to share eth0 through a
virtual switch.
– “Warp” interfaces link the VS to the virtual switch and then the virtual switch links into the physical switch

Anyways what I had to do is create a link to the virtual switch for the VSX gateway.

I went into the topology for the VSX gateway and created a NEW interface to the Virtual Switch “HQClusterSwitch”. I put an address on the interface of the external physical interface that external systems see ( for the VSX gateway.

I then added a default route to the external router

This is the interface defs for the VSX gateway or ‘vsenv 0’. So for those not familiar with VSX, what happens in the internal routing table is a little different than standard Linux. A new WRP1 interface is created.  Notice it has an IP address of Notice there is NO interface for



BUT a route statement is inserted that points TO the wrp1 interface.

Here above if you ‘vsenv 1’ which means change to the context of the Virtual Switch, you can see the other end of the warp interface wrpj1 and you can see the switch tied into the eth1 which is the external interface.

So my next question is “Where is the interface????” More specifically where is defined? .

Well I have some of the answer but not all. Seems there is some weird NAT going on. Check this out, an FW monitor of vsenv 0 the VSX gateway:

Notice how packets are entering VSX gateway going up the input stack as but are then address translated to which is the warp interface
of the VSX gateway!!! Cute huh?

So I went digging into the NAT table and nada, zilch, bust. Not there. But I know its somewhere!!!

The search goes on.

Adios amigos noche tarde,


Helen's Loom

"Peculiar travel suggestions are dancing lessons from God." - Kurt Vonnegut

Life Stories from Dreez

These are stories from my travels. Generally I like to write stories about local people that I meet and also brag about living the retirement dream with my #1 wife Gaby. She is also my only wife.