Configuring SSH login mail alert on checkpoint secureplatform..

http://firewalltips.blogspot.com/2010/05/configuring-ssh-login-mail-alert-on.html

How add / change interface IP on Nokia IP useing clish / CLI??

Below shows you the commands required to change the IP address of an interface within clish on a IPSO Nokia gateway,

1.add interface eth1c0 address IP [NEW IP]/[NETMASK]

2.delete interface eth1c0 address [OLD IP]

3.set interface eth1 speed 100M duplex full active on

4.set interface eth1c0 enable

Below gives you an example :

1.nokia-firewall[admin]# clish

2.NokiaIP390:102>add interface eth1c0 address IP 192.168.1.1/24

3.NokiaIP390:102>delete interface eth1c0 address 172.16.1.1

4.NokiaIP390:102>set interface eth1 speed 100M duplex full active on

5.NokiaIP390:102>set interface eth1c0 enable

F5 LTM VE – Node Monitors

A node is the actual physical server. So in this case, a node would be WebHost1, 2, or 3. Members are a specific service on a node. As we saw when we added pool resources we specified an IP address (the node) and the port (node + port = member (in most cases)). That being said, we never actually defined any nodes. Let’s take a look at what it did for us. Click on ‘Nodes’ under the ‘Local Traffic’ menu on the left. You should see something like…

So the LTM created nodes for us. These could be left as is, but I’m going to open each one and change the name so its more descriptive. You’ll notice that while you are in the node settings changing the name that there is an option for a health monitor. The default should be set to ‘Node Default’ as shown below…

Back on the main ‘Node’ screen you’ll see at the top an option for ‘Default Monitor’. You should have also noticed that the nodes are showing availability as ‘unknown’. This is because we are telling the node to check its availability using the ‘Node Default’ but we haven’t defined that yet. My host are available via ICMP, so I’ll configure that as my node default monitor.

Click ‘update’ and then click ‘Node List’ to go back to the main ‘Node’ window. It should now look like this…

Note the updated names as well as that they all show as green indicating that they are available. So now we have health checking enabled on both the member as well as the node itself. If a node goes offline, all of its members will fail the health check and be removed from the pool. We’ll wrap up this section with a quick test of that. I’m going to reboot WebHost1 and we are going to verify that traffic headed for the VIP doesn’t balance to the down server.

The instant the server stops responding to pings I can see that the pool member shows as down.

Additionally we can see that the node itself is marked as down…

A quick check of the VIP shows a pattern of…

This showing of course that WebHost1 is no longer in the pool. The instant it comes back online both monitors will show as green and it will be back as part of the pool.

In the next few posts I’m going to jump into some more of the more interesting pieces of the LTM config including load balancing methods, persistence, and hopefully I can get to iRules soon.

F5 LTM VE – Setting up basic load balancing

In this post we are going to go through setting up basic load balancing. On the LTMs this is a relatively easy task so I’m going to rip right through it. The nice thing about the configuration is that instead of starting from the bottom up, you can actually start from the top down. So rather than creating all of your nodes, then creating the members, and then the pool, we can just start with the virtual server and add the other objects. Best shown by example, so here we go..

Log in to your VE LTM and blow up ‘Local Traffic’ on the left menu bar. Select the ‘’Pool’ option and on the far right select the ‘Create’ button.

On the next screen, give the pool a name, select ‘http’ for the health monitor, and then move down to the resources area. Enter the information for each of your web hosts into the ‘New Members’ area. Enter 1’s info, then hit add, etc. until all of them are listed in the text box as shown below…

Then click ‘Finished’ to create the pool. You should now see your pool created and it should have a pretty green circle next to the name indicating that the monitors are succeeding in querying the device on port 80.

Now that the pool is created, we need to create a virtual server to associate it with. Select ‘Virtual Servers’ from the ‘Local Traffic’ menu on the left hand side of the screen. Then click the ‘Create’ button on the far right of the window.

There are lots of options on the next screen but just concern yourself with the ‘General Properties’ window. The ‘Destination’ field is the IP of the VIP that clients will connect to in order to be load balanced. Fill in your relevant information as shown below…

Then scroll to the bottom and click ‘Finished’ to create the virtual server. Once the server is created, it will take you back to the main virtual server window. Click the ‘Edit’ link on the far right of the virtual server description under resources…

Under ‘Default Pool’ select your newly created pool and then click ‘Update’

At this point we are ready to test. Open up a web browser and point it to the VIP. http://10.20.20.21 and see what you get. Hopefully, you’ll get nothing. Why do you ask? Because the web servers are returning traffic to our default gateways, not the LTM. Open up the virtual server settings and change the ‘SNAT Pool’ setting from ‘None’ to ‘Automap’. Automap tells the LTM to change the source to one of its self IPs in that subnet. In this case, it would source the packets from the 192.168.1.40 address.

Once the SNAT pool is specified, try hitting the VIP again and see what happens. With any luck you should get one of the web servers. Three refreshes and you should see all of the web servers get hit as shown below…

So that is all it takes to setup a very simple load balancing configuration. Not hard right? In the next post, we’ll go back through and talk a little bit more about what we just set up as well as look at monitors.

F5 LTM VE – Configuring Persistence

One of the main problems with load balancing is persistence. Some web applications require that the external user return to the same web server each time, or at least each time within a given window of time. That being said, there needs to be a mechanism in which we can determine if the external user has connected before, and if so, to what server he was balanced to.

Persistence is a configuration option of the virtual server. There are two settings for persistence. The first being the default persistence profile. Default persistence is the main persistence mode used for the virtual server. The second option, fallback persistence, is used when the first method of persistence fails. For example, if the default persistence is set to ‘cookie’ but the client isn’t accepting cookies, you could fallback to source persistence. There are 8 different persistence profiles, let’s walk through them one at a time with some examples along the way.

Source Address Persistence
This is a pretty common type of persistence. The LTM tracks the source of the incoming packet and redirects any connections coming from that IP to the same pool member. When this is configured on our test virtual server we see a return like this…

Destination address Persistence
Persistence based on the destination address is much like source address persistence. Except that the F5 examines the destination of the packet rather than the source. Now, you might ask yourself, when would this actually be useful? Think of a setup where an LTM is load balancing a set of proxy servers that are doing caching. Clients would be forced through the proxies to the external site (read destination) and the proxy would cache that site. Going forward, it would make sense to balance clients going to the same destination to the same proxy since that particular proxy already has the website cached.

Cookie Persistence
Cookie persistence is another common load balancing type. Cookie persistence requires that a HTTP profile be associated with the virtual server. We’ll talk more about profiles in another blog entry. When using cookies the F5 will examine the incoming request and determine if the appropriate cookie is part of the request. If it is, the F5 will balance the client to the same member based on the cookie. There are 4 different methods of cookie persistence. These can be set under the cookie persistence profile…

The default method is ‘Cookie Insert’. In this mode the F5 writes a cookie called ‘BIGIPServer’ into the response from the web server as it passes through the F5 on its return path to the client. This method require no additional configuration on the web servers.

In ‘Cookie Passive’ mode the web servers must control the insert and updates of the BIGIPServer cookie. The F5 only looks at the Cookie to determine which server the request should go to.

In ‘Cookie Rewrite’ mode the web server must send a cookie formatted in a particular order to the F5. The F5 will then rewrites the cookie to the BIGIPServer cookie, updates it with the member information, and sends it back to the client.

In the last mode ‘Cookie Hash’ the LTM examines the cookie inserted by the web server on a previous connection and makes a load balancing decsion based on the hash in the cookie. While the LTM is still making the load balancing decision, its making it based off of the cookie set by the web server. This effectively moves the brains of the load balancing decision to the web server(s) that calculate the hash to insert into the original cookie.

To see the cookie on the client, you’ll need to change the cookie persistence profile from ‘Session Cookie’ to an set expiration cookie. Session cookies are only good for that particular session and are stored in memory so they are never written to disk. The expiration date of the cookie is updated each time the client hits the F5 so its sort of a rolling expiration. At any rate, set it for at least an hour, and then hit the VIP with your browser. I used a app called ‘IECookiesView’ to read the cookie…

Hard to see there, but the cookie is on the system at this point.

Hash Persistence
By now you should be seeing that things including the hash function on the F5 are the more advanced custom like features. I’ve never used this but I imagine you could use an iRule to examine the hash and make decision based on that.

Microsoft Remote Desktop (msrdp)
Tracks sessions between the RDP server and client

SIP (sip_info)
Persistence based on servers that receive and process SIP traffic

SSL
Keeps track of the sessions using the SSL Session ID

Universal
Allows for persistence based on custom expressions that you can write yourself.

Well that covers all of the different types. You can probably tell that I went into greater detail on some of the more common ones. The last few I at least haven’t dealt much with, so I don’t have a ton of info on yet. If and when I get more info, I’ll update the post.

F5 LTM VE – Configuring iRules

iRules are perhaps one of the coolest features of the F5 devices. They allow you to write rules that can manipulate the load load balancing decision. The rules can evaluate variables that the F5 can detect. In this entry, we are going to examine the user-agent string which is part of the HTTP header. Based on the use-agent field, we can determine what type of browser the client is connecting with. Looking at this information can also help us determine what kind of device the client is connection from.

First off, I wanted to add another pool to my LTM. Rather than spin up new VMs for this purposes I told apache on each WebHost instance to listen on port 81 and direct requests incoming on that port to a different folder. So I added this to my httpd.conf on each WebHost…

Listen 81

ServerName localhost
DocumentRoot /var/www/html/81

Then I put a modified copy of my index.html file in the 81 folder on each WebHost. Then I created a new pool that looked like…

Now that that’s done we can write our iRule. iRules are pretty easy to understand just by looking at them but on the other hand, rather picky about syntax, spacing, etc. So lets take a look at the iRule we are going to use in this test. I wanted to create a iRule that would send requests coming from a iPhone to the new HTTP_MOBILE_POOL (the port 81 group we just created) and send the rest to the default HTTP_POOL. So I came up with…

So as I said earlier, this is pretty easy to read. If I detect “iPhone” in the user-agent filed, I’ll send the request to the mobile pool. If I don’t, send it to the regular HTTP pool.

Now that we wrote the rule we have to apply it to the virtual server. Open your virtual server and click on the ‘Resources’ tab. Since this iRule is setting the pool for us and we have a ‘else’ statement, I’m going to set the default pool to none. Then set the iRule accordingly…

That’s it, give it a test! From out desktop we see the normal page…

And from the iPhone we see…

Not very inventive of me but you get the point.

So as you can see iRules are very powerful. I hope to write some more soon and post them up as templates and examples but for now I just wanted to let you see how powerful they can be.

iRules Editor – much easier…

So I’m quickly falling in love with F5 and iRules, but writing them was sort of a pain. I wasn’t good at catching typos and syntax errors on the fly and pasting the code into the LTM, saving it, and it kicking back some cryptic error message about your typos was a little maddening. So I thought I’d do some googling and check out what I found…

The F5 iRule Editor! (Click here for site)

How awesome is this! Once installed the app connects to your LTM in one easy step…

After connecting to the LTM it loads all your current iRules for editing and allows you to create new ones through it editor and upload them to the LTM. I literally just installed the app, but my favorite part at this moment is the fact that the editor is what I call ‘command context aware’. Check this out..

All I Did was type ‘HTTP::’ and the context menu came up with all of the options I can use on the HTTP object. Awesome!

Well I’m sure there will be more to come on this as I explore but I thought I’d share right away. More to come soon!

F5 LTM VE–Setting up basic load balancing (CLI!)

So since I’m such a huge CLI guy I thought that I’d go back through my previous F5 LTM VE posts and do it all through the CLI. To be honest, Im brushing up on the topic so that I can someday sit the F5 exams. Not sure when that will be but I’m hoping soon. So, I deployed the OVA template into VMWare again and I’m going to do the full setup again. Not as much explanation this time but I’ll walk through it.

Management IP
Boot the VM up, log in with default credentials, launch the config wizard, setup your management IP.

License
Fire up a SSH connection to the management IP you configured. At the command prompt enter the following command…

get_dossier –b

This will kick out the dossier file. Copy the dossier, browse over to activate.f5.com, select the activation method you are looking for, and enter your dossier. After accepting the terms you should get a license file kicked back to you that looks something like this…

Copy the entire text contents of the text box and head back to your SSH session. Edit the contents of /config/bigip.license with vi…

vi /config/bigip.license

Its a new file so go into insert mode and past the contents. Write the file and then issue the following command to restart the BigIp processes

bigstart restart

You should notice that your prompt changed from ‘NO LICENSE’ to ‘INOPERATIVE’ after the restart. That’s a good sign.

Hostname
tmsh modify sys global-settings hostname LTM2.interubernet.local

Create VLANs
tmsh create net vlan external interfaces add {1.2}
tmsh create net vlan internal interfaces add {1.1}

Create Self IPS
tmsh create net self 10.20.20.40/24 vlan external
tmsh create net self 192.168.1.40/24 vlan internal

Create HTTP_POOL Pool
tmsh create ltm pool HTTP_POOL load-balancing-mode round-robin members add {192.168.1.41:80 192.168.1.42:80 192.168.1.43:80}

Create HTTP_TEST Virtual Server
tmsh create ltm virtual HTTP_TEST destination 10.20.20.40:80 profiles add {tcp http} pool HTTP_POOL snat automap

Save the config
tmsh save sys config

And that’s it! You should be able to hit 10.20.20.40 and see round robin traffic between the three web servers.

F5 LTM VE – Load balancing methods

So now that we are getting comfortable with the LTM, we should discuss the various types of load balancing methods. The LTM provides for lots of different types as shown below…

F5 breaks them into two groups, static and dynamic. Let’s go through them one at a time and discuss each.

Round Robin (Static)
Its the default load balancing type. Everything we’ve seen up to this point has been round robin. It provides an even distribution between all available pool members.

Ratio (Static)
Ratio mode allows you to define a ratio for each server. This is a good mode to use when servers have varying degrees of processing power. A ratio of…
WebHost1 – 3
WebHost2 – 1
WebHost3 – 1
Would result in the host being directed to WebHost1, WebHost1, WebHost1, Webhost2, WebHost3, Webhost1, Webhost1, Webhost1, Webhost2, etc.

Least Connections (Dynamic)
This mode distributes connections between web servers based on the current connection count between the F5 and the web server. Its not possible for the F5 to know of any other connections coming from other hosts so it only uses its own connection table to determine where to send the next request. So let’s test this one out to see what happens. I’m going to open a http request to one of the web servers. To do this, I’m actually going to download a large file from both of them to keep the sessions open long enough to test. With the file being downloaded we can see that we have a open connection to Webhost1…

Any future requests will take this into account. Browsing to that VIP will point us to the remaining two web servers. Try hitting the VIP and see what happens…

As you can see, we aren’t getting any requests going to Webhost1 at this point.

Fastest
Fastest distributes connections based on the server response time. This would be useful in a situation where previous requests may put varying degrees of a load on a server, hence slowing down future requests.

Least Sessions
Much like least connections but based on the session (F5 calls a persistence record that’s valid a session) count. The member with the least amount of sessions will get the next connection.

Weighted Least Connections
In order to use this method each member must have a defined (not 0) connection limit. The LTM then calculates the member capacity by as a ratio of current connections to the connection limit. The server with the smallest percentage of used capacity gets the next session.

Observed
This is sort of an odd one. The system assigns ratios to the members dynamically. The LTM checks the connection count on each member every second. The average is calculated and members with less than average connection counts get assigned a ratio of 3 and the those with a greater than average connection count get assigned a ratio of 2.

Predictive
Same as observed but uses 4 rather than 3 for less then average and 1 rather then 2 for greater than average.

Dynamic Ratio
A much more complex method of load balancing where particular brands of servers can be configured with special monitors and the load balancing method is based on various calculations of these metrics.

So that’s all of them. I tried to show examples of some but couldn’t show all of them in a lab setup. Next up is persistence. I might talk about profiles before that, not sure yet.

ClusterXL shows Active Attention / Interface Active Check Error

http://www.fir3net.com/Firewalls/Checkpoint/clusterxl-shows-active-attention-interface-active-check.html

Checkpoint FW SPLAT Cluster XL Troubleshooting (NGX Versions)

In this blog, let us see a Step by Step approach that you would take to troubleshoot a Cluster XL problem in Checkpoint.

Normally, this problem comes of after a reboot or an Upgrade or as a result on some change in the underlying network. When troubleshooting the CPHA, the following commands are very helpful

• cphaprob state
• cphaprob list
• cphaprob –a if

The status of the CPHA is shown by the first command. First thing that you need to do is verify basic connectivity between the firewall interfaces. Allow the cluster members to ping each other (if not already allowed by the policy) and ping away, you should be able to verify the basic connectivity in this way.

If the connectivity exists, then find out which firewall has the problem, it will normally be the down firewall

Number Unique Address Assigned Load State
1 (local) 10.0.0.1 100% Active
2 10.0.0.2 0% Down

Here as you can see the second firewall is down, you need to first go ahead and just execute ‘cpstop’ and ‘cpstart’ commands on the box. The CPHA should be back up.

Also execute the command ‘cphaprob –a if’ that should give you the interface status and Cluster Xl status.

If this doesn't work, try pushing the policy from the CMA/SC server and then execute cpstop / cpstart commands. If this doesn’t clear out the problem, reboot the box. 90% of the CPHA problems will be resolved in the above given steps, but if still its not resolved then read on.

The above steps were given with the assumption that the CPHA was working and it stopped working suddenly. If this is the first time you are trying to make it happen or some major policy/network changes broke it, then here is what you need to keep in mind.

• CPHA uses multicast, so make sure the switches you have in the path don’t drop multicast traffic, if you are using Cisco gear, then you might want to configure igmp snoop.
• It also uses the port ‘8116’ in UDP, so make sure that the port is open between the devices. (This is crucial if you have played around with the global properties and implied rules.
• RIB uses port 2010 so make sure that is also open between the firewalls.

After checking that your switches, execute the command, ‘cphaprob list’ and make sure both the sides have the same registration and the states of all of them are OK. If the state shows problem, then you should work in the direction of resolving that problem.

Device Name: FIB
Registration number: 4
Timeout: none
Current state: problem
Time since last report: 9.3 sec

Then you can do the snoop using the ‘fw monitor’ command and make sure the communication between the firewalls is happening.

Use the following command

fw monitor –e ‘accept dport=8116;’

1. You will see the source 0.0.0.0 and the destination as the network ID of the network over port 8116.
2. On port 2010 (change the dport to 2010 in above capture), you should see FIB communicating between the firewalls.

You should also check the /var/log/messages for error messages that can help you troubleshoot this further.

And yes, I forgot to mention, in this case, i was seeing that the FIB on one firewall had switched itself off after the upgrade, so went ahead and switched on advanced routing using ‘cpconfig’ command and all went well.

http://3-4-5-6.blogspot.com/2010/04/checkpoint-fw-splat-cluster-xl.html