My post from October 2011 about configuring SNMP settings on Secure Platform (SPLAT) is one of the most read in this blog.

Now I want to add a new How-To for configuring SNMP on Check Point GAIA – which is quite simple.

Just select SNMP menu item from System Management menu.

Then check the box for enabling the SNMP Agent, check the box for all the interfaces where you want the SNMP Agent to listen and press Apply.

Then configure your SNMP community as needed and press Apply under this section again.
 

Don’t forget to create a rule to allow SNMP access to your Security Gateway in your security policy and install it to get SNMP data.

If you don’t like the WebUI you might also configure the SNMP settings from the CLISH command line.

set snmp agent on
set snmp agent-version any
set snmp community ThisIsSoSecret read-only
add snmp address 192.168.1.1

We most recent SNMP MIB can be found on a GAIA installation with R75.45 at /opt/CPshrd-R75.40/lib/snmp/chkpnt.mib
 

Tobias Lachmann

In my last post I wrote a quick How-To on configuring BGP between a Security Gateway and a Cisco Router. Today we’re going to extend this setup to full High Availability.

As shown in the overview picture, we now have two routers involved in the BGP. These two routers provide a HSRP (Hot Standby Router Protocol) IP address for the Security Gateways as Default Gateway. The Security Gateways are clustered using ClusterXL.

When you install a R75.45 from scratch you will find that you run into trouble as the routed routing daemon in GAIA has a bug when it comes to a HA configuration.

Check Point has acknowledged this problem and provides a new version of routed since 20th November.

The old version has the following information:

[Expert@fw1]# cpvinfo /bin/routed

[** Version info attributes of '/bin/routed' **

[Build Number = 986000037
Major Release = NGX
Minor Release = gaia_fiber_adp_ea

 

The new version has the following information:

[[Expert@fw1]# cpvinfo /bin/routed

[** Version info attributes of '/bin/routed' **

[Build Number = 986003002
Major Release = NGX
Minor Release = foxx_hf_ha45_003

 
With the fixed version of routed there are only little changes that have to be done to configure the Security Gateways running GAIA for High Availability and BGP in addition to the configuration of a non redundant setup.

First thing is to configure the BGP Router-ID for every Security Gateway to have the ClusterXL IP address in it.

Then you have to edit the BGP peer group and add both Cisco Router aka BGP peers. Don't forget to set the local address to the physical IP address of the specific gateway.

To complete the description details here are the Cisco configuration for both routers in this scenario.

Router A:

interface Loopback0
ip address 192.168.200.2 255.255.255.255
!
interface GigabitEthernet0/0
ip address 192.168.100.2 255.255.255.0
standby 0 preempt
standby 1 ip 192.168.100.1
standby 1 priority 40
!
interface GigabitEthernet0/1
ip address 10.10.10.2 255.255.255.0
!
router bgp 12345
bgp router-id 192.168.200.2
bgp log-neighbor-changes
neighbor BGP_TEST peer-group
neighbor BGP_TEST remote-as 12345
neighbor BGP_TEST description iBGP Session between Core and Security Gateway
neighbor BGP_TEST update-source Loopback0
neighbor 192.168.100.100 peer-group BGP_TEST
!
address-family ipv4
redistribute connected
redistribute static
neighbor BGP_TEST soft-reconfiguration inbound
neighbor 192.168.100.100 activate
exit-address-family
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.10.1
ip route 192.168.200.3 255.255.255.255 192.168.100.3

Router B:
interface Loopback0
ip address 192.168.200.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.100.3 255.255.255.0
standby preempt
standby 1 ip 192.168.100.1
standby 1 priority 50
!
interface FastEthernet0/1
ip address 10.10.10.3 255.255.255.0
!
router bgp 12345
bgp router-id 192.168.200.3
bgp log-neighbor-changes
timers bgp 60 180 180
neighbor BGP_TEST peer-group
neighbor BGP_TEST remote-as 12345
neighbor BGP_TEST description iBGP Session between Core and Security Gateway
neighbor BGP_TEST update-source Loopback0
neighbor 192.168.100.100 peer-group BGP_TEST
!
address-family ipv4
redistribute connected
redistribute static
neighbor BGP_TEST soft-reconfiguration inbound
neighbor 192.168.100.100 activate
no auto-summary
no synchronization
exit-address-family
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.10.1
ip route 192.168.200.2 255.255.255.255 192.168.100.2

Tobias Lachmann

Today we’ll have a look at advanced routing and how we can exchange routing information using the BGP protocol between a Check Point Security Gateway running GAIA and a Cisco router.

It is common practice to use Internal Routing Protocols (IGPs) like ISIS or OSPF for carrying your infrastructure addresses and Border Gateway Protocol (BGP) for carrying Internet prefixes.

I found a very good presentation from Philip Smith who works for Cisco and explains BGP best practices in detail.

We assume that we have the following setup: a router, connected to the Internet on one hand and to a Security Gateway on the other hand. The Security Gateway should tell the router which network it protects using BGP.

In this setup we have the following routing information on the Security Gateway:

firewall> show route all
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed


S 0.0.0.0/0 via 192.168.100.100, eth1, cost 0, age 178
C 127.0.0.0/8 is directly connected, lo
C 192.168.100.0/24 is directly connected, eth1
C 200.200.200.0/24 is directly connected, Mgmt

And this is the routing table for the router:

router#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 10.10.10.2
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.100.0/24 is directly connected, GigabitEthernet0/1
L 192.168.100.100/32 is directly connected, GigabitEthernet0/1
192.168.200.0/32 is subnetted, 1 subnets
C 192.168.200.200 is directly connected, Loopback0

Note that the router is using a loopback IP address for establishing the BGP sessions. See the BGP best practices presentation referenced above for detailed explanation about this.

Now we configure our (Cisco) Router for an internal BGP (iBGP) session.

interface Loopback0
ip address 192.168.200.200 255.255.255.255
!
!
interface GigabitEthernet0/0
ip address 10.10.10.1 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 192.168.100.100 255.255.255.0
duplex auto
speed auto
!
router bgp 12345
bgp router-id 192.168.200.200
bgp log-neighbor-changes
neighbor BGP_TEST peer-group
neighbor BGP_TEST remote-as 12345
neighbor BGP_TEST description iBGP Session between Core and Security Gateway
neighbor BGP_TEST update-source Loopback0
neighbor 192.168.100.1 peer-group BGP_TEST
!
address-family ipv4
redistribute connected
redistribute static
neighbor BGP_TEST soft-reconfiguration inbound
neighbor 192.168.100.1 activate
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 10.10.10.2

At this point the router tries to establish a BGP session with our Security Gateway and tells it about his own connected and static routes.

But the Security Gateway isn’t answering the BGP requests so let’s move on to the configuration of GAIA.

There are different ways to configure BGP, in this example we use the WebUI for it.

First login and change the view to Advanced so that you’re able to see all the menu items in the WebUI.

Then choose BGP from Advanced Routing menu.

On the BGP menu, first check the configuration of the router ID. In our example we use the real IP address of the Security Gateways external interface.

The next part is to change the Local System Identification.

As shown in the lab setup overview, our AS is 12345.

Save the change. Configuration page looks now like this.

Now we will add a peer group which will contain our Cisco router as peer.

Enter the peer AS numer. If it is equal to your own AS number, the page will show the peer group type as Internal, otherwise as External.

Then we enter the IP address of the Security Gateways external interface again as Local Address.

And last we add the specific peer by clicking on add peer.

When you click on Show Advanced Settings you’ll see various options including Logging and Trace Options. I recommend to turn them all on. The information can be found in /var/log/routed.log and the output looks like this:

[Expert@firewall]# tail -f /var/log/routed.log
Nov 16 15:28:07 bgp_traffic_timeout: peer 192.168.200.200 (Routing AS 12345) last checked 60 last recv'd 48
Nov 16 15:29:07 bgp_traffic_timeout: peer 192.168.200.200 (Routing AS 12345) last checked 60 last recv'd 1
Nov 16 15:30:07 bgp_traffic_timeout: peer 192.168.200.200 (Routing AS 12345) last checked 60 last recv'd 6
Nov 16 15:31:07 bgp_traffic_timeout: peer 192.168.200.200 (Routing AS 12345) last checked 60 last recv'd 6
Nov 16 15:40:18 bgp_traffic_timeout: peer 192.168.200.200 (Routing AS 12345) last checked 60 last recv'd 60
Nov 16 15:40:18 bgp_send: sending 19 bytes to 192.168.200.200 (Routing AS 12345)
Nov 16 15:40:18
Nov 16 15:40:18 BGP SEND 192.168.100.1+43878 -> 192.168.200.200+179
Nov 16 15:40:18 BGP SEND message type 4 (KeepAlive) length 19

Close all configuration dialogs by clicking Save.

Now we’ll have a look at the routing table of our Cisco router. Will we see the routes from the Security Gateway?

router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 10.10.10.2
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.100.0/24 is directly connected, GigabitEthernet0/1
L 192.168.100.100/32 is directly connected, GigabitEthernet0/1
192.168.200.0/32 is subnetted, 1 subnets
C 192.168.200.200 is directly connected, Loopback0

Nothing has changed here????

Let’s have a look at the Security Gateway:

firewall> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

No learned routes here!

Checking the operating system routing table in expert mode:

[Expert@firewall]# ip route
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1
200.200.200.0/24 dev Mgmt proto kernel scope link src 200.200.200.200
default via 192.168.100.100 dev eth1 proto cprd

Nothing here, either. Let’s check again in CLISH:

firewall> show route all
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

S 0.0.0.0/0 via 192.168.100.100, eth1, cost 0, age 1117
B H 10.10.10.0/24 via 192.168.100.100, eth1, cost 0, age 294
C 127.0.0.0/8 is directly connected, lo
B H 192.168.100.0/24 via 192.168.100.100, eth1, cost 0, age 294
C 192.168.100.0/24 is directly connected, eth1
B H 192.168.200.200/32 via 192.168.100.100, eth1, cost 0, age 294
C 200.200.200.0/24 is directly connected, Mgmt

Here we see BGP routes learned from the router, but the routes are marked “hidden”. Which means the routing process knows about them because he got the information from the BGP peer, but is not passing this information along to the routing table of the Security Gateway.

To solve the task of distributing routes via BGP, we have to configure some more option in GAIA WebUI.

Select Route Redistribution from Advanced Routing menu.

In our example we want to redistribute the routes from the connected interfaces through BGP, so select Add from Redistibute Interfaces.

Then select to which routing process you want to distribute to.

Then select which interface(s) you want to redistribute.

Then enter a metric and click Save.

From this point on you will redistribute your routes over BGP to the Cisco router.

Let’s check with the router:

router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 10.10.10.2
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.100.0/24 is directly connected, GigabitEthernet0/1
L 192.168.100.100/32 is directly connected, GigabitEthernet0/1
192.168.200.0/32 is subnetted, 1 subnets
C 192.168.200.200 is directly connected, Loopback0
B 200.200.200.0/24 [200/100] via 192.168.100.1, 00:00:31

At this point we achieved our goals, routes from the Security Gateway are distributed to the router using BGP.

But what to do if we want to import routes from the router into the Security Gateway?

In this case we have to define Inbound Route Filters. Select the appropriate menu from WebUI.

Then we need to define a BGP Policy for routes to import. Click on Add BGP Policy.

Define which routes to accept. In our case we accept all routes from peers in AS 12345.

The summary show you the new BGP policy and from that point on your Security Gateway accepts routes send by BGP from the Cisco router.

The routing tables looks like this:

firewall> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

B 10.10.10.0/24 via 192.168.100.100, eth1, cost 0, age 58
B 192.168.200.200/32 via 192.168.100.100, eth1, cost 0, age 58

firewall> show route all
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

S 0.0.0.0/0 via 192.168.100.100, eth1, cost 0, age 669
B 10.10.10.0/24 via 192.168.100.100, eth1, cost 0, age 62
C 127.0.0.0/8 is directly connected, lo
B 192.168.100.0/24 via 192.168.100.100, eth1, cost 0, age 62
C 192.168.100.0/24 is directly connected, eth1
B 192.168.200.200/32 via 192.168.100.100, eth1, cost 0, age 62
C 200.200.200.0/24 is directly connected, Mgmt

The last thing I want to show to you are some helpful options or buttons.

Under Advanced Routing -> Routing Options you will find trace options for routing.

I suggest you turn them on increase the size for the trace files.

Don’t forget to apply the setting with the button on top of this page!

Last thing is the way to restart the routing daemon. The button can be found on the bottom of the Route Options page.

I hope you liked this little How-To on BGP.

Tobias Lachmann

If you want to install GAIA(+) with a USB flash drive using ISOmorphic, please make sure that you use a ISOmorphic version greater than build 67.

No idea which build your currently installed ISOmorphic has?

Download the latest version if in doubt.

Tobias Lachmann

Please have in mind that we have different GAIA versions out there.

We have GAIA and we have GAIA+ – which brings some new features and improvments and should be the one that is installed when building new systems from scratch.

On CLISH you can determine the version with the command show version all.

The following build numbers are know so far:

• latest EA: 264
• GA: 338
• 2nd GA: 339
• GAIA+: 65

To be honest: I’m not happy about this different versions. Makes life harder and when you connect to a system you don’t know, you have to make sure which version you’re on.

And for sure we can expect more version like GAIA++, GAIA enhanced or whatever Check Point wants to call it. Keeps confunsing engineers as we as customers.
Also, as seen with GAIA+, you can’t go from one version to another like that. So your GAIA installation cannot be upgraded to GAIA+. In worst case you have to re-do the installation.

Tobias Lachmann

Maybe you made your first steps with GAIA, the all new Check Point operating system, and found yourself at the point where you needed to go into “Expert mode” as used in SPLAT.

Just typing expert will give you the message that you need to define the expert password first by issuing set expert-password plain.

Having done that, you can enter expert mode as you like.

But unfortunately this configuration doesn’t survive a reboot.

Why? Because configuration made in CLISH are not persistent and survive a reboot unless you issue the save config command which writes the changes to the central configuration database.

When you work with the WebUI, changes are saved as soon as you press the button Apply.

Please have this in mind when configuring your GAIA from CLISH.

Tobias Lachmann

After we finished installation, it is time to configure the system over the WebUI using the First Time Configuration Wizard.

Step 1 – Login

Here we use the passwort defined during installation instead of “admin/admin” as in old installations.



Step 2 – Welcome Screen



Step 3 – Configure Date and Time

Step 4 – Device Name and DNS

Step 5 – Network Connection

Note that you can configure a DHCP Server for this interface to serve the clients



Step 6 – Product Selection

Here you can choose wether to do a standalone installation with gateway and management on the same machine, or a distributed installation. When your system is a security gateway and part of a cluster, you can choose wether to use ClusterXL for clustering or have a VRRP cluster. The later is a feature that Check Point took from the IPSO.

If you install a security management, you can choose if this a primary or secondary server – or a Log Server / SmartEvent Server.

Step 7 – Create a cpconfig_administrator for use in SmartConsole

Step 8 – Define the IP addresses of GUI clients

Step 9 – Review and Finish

Step 10 – Installation and configuration

I like that at this point the system gives you feedback what kind of action it is performing at the moment and what the progress is.

Step 11 – Configuration is finished



On this point you setup your system, in our case a Security Management server.

Now we can install SmartConsole and login to the server.

Tobias Lachmann

Today I received an E-Mail with the download links for the GAIA early availability packages.

It took Check Point over two weeks to check my “application” for the EA program.

I wonder how the select the ones who will get access to this program.

Still pissed that I had to wait until this day to get hands on GAIA.


Tobias Lachmann

PS.: my friend Valeri Loukine has a review on the GAIA EA in his blog

Check Point opened the registration for the GAIA public EA.



No actual information can be found on the pages as for now, but will be provided when the binaries are available in a few weeks.

Tobias Lachmann