Introduction
After using Cisco System’s PIX firewall for some time, I decided to give Check Point firewalls a go. Probably most of you might be aware of how efficient and user-friendly it is to configure Check Point ZoneAlarm firewall for endpoint security. This is exactly what you get even with their Enterprise-level products! Configuring Check Point VPN-1 NGX65 is such a breeze and its GUI never comes in the way. On the contrary, SmartDashboard, the GUI for manipulating Check Point firewalls, gives you access to advanced features with relative ease. For instance, the use of Database Revision Control allows you to revert to a previous firewall policy as easily as it is to install new ones!
In this blog, I will describe about my experience working with this firewall deployed as a VMware virtual machine and tested using a couple of Cisco routers on Dynamips, all using just two Windows XP laptops (say Laptop A & B). This is consistent with all my other postings here. This setup may provide you with the necessary hands-on experience, if you are interested in pursuing any Check Point certification (such as CCSA). This is however NOT a tutorial on how to install and configure Check Point. Instead, I aim to show how you can setup a Check Point firewall in a lab setting and see it in action filtering traffic between two networks.
Scenario
The objective of this lab is to enable Check Point VPN-1 firewall in a mostly virtual environment, but still observe the firewall in live action. Using VMware ESX 2.0, I created a virtual machine with 512 MB RAM, 15 GB disk, and mostly importantly two bridged network adapters for inside and outside access, respectively. I ensured that the bridged interface (by default vmnet0) is bridged to Laptop A’s physical NIC port.
To represent the inside network, a Cisco 3640 router is used. This router will provide Telnet as well as Http services to the outside network. To allow the interaction between the Dynamips hypervisor and the Check Point virtual machine (CPVM), I linked my NIC’s NIO device to Dynamips’s Ethernet switch S1, since CPVM is already bridged to the NIC. Also, as I will run SmartDashboard from Laptop A, I need to connect a loopback adapter to S1 as well. Some of you might have noticed that this actually places both CPVM’s inside and outside interfaces on the same broadcast domain! (Good, at least you are alert..) Here, comes the magic of VLANs! I will place the inside interface in the native VLAN 1, and assign the outside interface to VLAN 100. This completes the setup in Laptop A (consists of cpfirewall, WEB1 and S1 objects from Fig. 1).
Laptop B is physically connected to Laptop A using a crossover UTP cable (shown as a red line in Fig. 1). It is mainly used to represent the outside network to CPFW. In order to assign suitable addresses both laptop’s NICs, there are many ways to approach this. I decided to use another Cisco 3640 router as the DHCP server to run on Laptop B to dynamically assign addresses in VLAN 100 to both NICs. As before, to link router D1 to the physical NIC, I connected the appropriate NIO device to Ethernet switch S2, which is further linked to Fastethernet0/0 of the router. That is the full scenario! Phew.. It might appear a bit convoluted, but try to use the following figure to assist understanding and to visualise.
Fig.1: Network diagram for this setup (link pattern shows VLAN membership). cpfirewall runs on a VMware virtual machine.
Check Point Virtual Machine
It does not matter which virtualisation software you use to create this virtual machine. You can use anything at your disposal. I had VMware ESX 2.0 installed on my machine, so just used its VI Web Access management console to create the virtual machine, as shown in Fig. 2. For the Check Point installation, I chose the Standalone deployment, which means the firewall as well as the management application (i.e. SmartCenter Server) will be installed on the same VM.
Fig. 2: The VMware ESX management console after CPFW is created.
Before you install the firewall program, you need to have an OS installed first. You can use the standard server OSes or use Check Point’s own OS called SecurePlatform, which is a modified version of Redhat Enterprise Linux 3.0. I went with the latter option. To get access to Check Point’s software, you can download the ISO images from their website or get the evaluation CD from their office. The installation of both OS and firewall product is rather straightforward. Just follow their Getting Started Guide. It took me around an hour to complete this step. During the installation, you need to specify firewall’s host name, domain name, interface information and routing. The followings are what I used:
host name: cpfirewall
domain name: km.net
eth0 IP: 192.168.100.1/24
eth1 IP: 192.168.124.7/24
Once you have installed and bring up the firewall VM, you can now install the SmartConsole applications (GUIs for firewall configuration and tracking) on the host machine itself, NOT in the VM. Just follow the setup wizard through a series of questions to complete the installation. Before you can access the firewall configuration through SmartConsole, you need to add your host’s IP to the allowed client list on the firewall (use cpconfig and choose option 3). In Fig. 3, I have included an address range 192.168.100.1 – 30 as trusted GUI client hosts.
Fig. 3: Add a trusted client host for remote access.
When you start SmartDashboard, you will be prompted to provide login details that you have already configured during the firewall installation, as follows.
Fig. 4: SmartDashboard login window.
Dynagen .net files
To enable the inside network of the CPFW, I have used the following Dynagen setup on Laptop A.
autostart = false
ghostios = true
sparsesmem = true
mmap = true
model = 3640
[localhost:7200]
[[3640]]
image = \Program Files\Dynamips\images\C3640-JK.image
ram = 96
idlepc = 0x603bc51c
[[ROUTER WEB1]]
f0/0 = S1 1
[[ETHSW S1]]
1 = access 1
2 = dot1q 100 NIO_gen_eth:\Device\NPF_{DCF3D8E4-D5BB-4E84-A712-97D6393034B8} #NIC
3 = access 1 NIO_gen_eth:\Device\NPF_{192F6952-5AEA-4B4A-8AC0-B07086BA6FAC} #lo0
Router WEB1 will be used as the Telnet and Web server for the inside network, and linked to S1. S1 is also connected to Laptop A’s NIC port and a loopback adapter, loopback0. S1’s port 1 and 3 are on VLAN 1, whereas port 2 is a trunk port with native VLAN 100. This port is used to link to Laptop B.
As for Laptop B, a simple environment to provide DHCP service to the physical NIC of both laptops is needed. I have used a similar setup as above.
autostart = false
ghostios = true
sparsesmem = true
mmap = true
model = 3640
[localhost:7200]
[[3640]]
image = \Program Files\Dynamips\images\C3640-JK.image
ram = 96
idlepc = 0x603bc51c
[[ROUTER D1]]
f0/0 = S1 1
[[ETHSW S2]]
1 = access 100
2 = dot1q 100 NIO_gen_eth:\Device\NPF_{A91A2A20-659A-4291-8C10-E727878AEFF7} #NIC
The most important thing to note here is S2’s port 1 is in VLAN 100 and port 2 is a trunk port with native VLAN 100.
Router WEB1 Configuration in Laptop A
1. Configure IP address and bring up fa 0/0.
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0
2. Configure a default route to CPFW, which acts the gateway for the inside network.
ip route 0.0.0.0 0.0.0.0 192.168.100.1
3. Enable DHCP service for the laptop’s loopback0 interface. I also ensured that only 1 address is available for lease. This interface will serve as the inside interface for Laptop A’s GUI access to CPFW.
ip dhcp excluded-address 192.168.100.1 192.168.100.10
ip dhcp excluded-address 192.168.100.12 192.168.100.254
!
ip dhcp pool forloopback
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
4. Verify that the HTTP service is enabled, and then enable Telnet access.
ip http server
!
line vty 0 4
password mypass
login
Router D1 Configuration in Laptop B
1. Configure IP address and bring up fa 0/0.
interface FastEthernet0/0
ip address 192.168.124.5 255.255.255.0
2. Configure a default route to CPFW’s outside interface.
ip route 0.0.0.0 0.0.0.0 192.168.124.7
3. Enable DHCP service for both laptop’s physical NICs on VLAN 100. I ensured just two addresses are available for lease.
ip dhcp excluded-address 192.168.124.1 192.168.124.99
ip dhcp excluded-address 192.168.124.102 192.168.124.255
!
ip dhcp pool extlan
network 192.168.124.0 255.255.255.0
default-router 192.168.124.7
Check Point Firewall Configuration
To write about VPN-1 configuration is at least a book in it itself! Here, I can only discuss about the basics of object definition and their subsequent usage in the security policy creation and deployment for firewall filtering. Figure 5 depicts the SmartDashboard interface that can be used to enable remote configuration and tracking of Check Point firewalls. The screen layout shows a rather standard Windows application layout. Below the toolbars, you can see the Network Objects tree on the left and the security rules on the right. Since we are interested in the firewall features of VPN-1, these are the relevant content panes for our discussion.
Fig. 5: A screen-shot of SmartDashboard for Check Point firewall configuration.
In our scenario, we want to allow all outgoing traffic from inside network to outside, and selectively allow outside traffic inside. A rule has at least five elements, namely source, destination, service, action and track. SmartDashboard makes it very easy to create network objects, which can then be referred in the rules. In Fig. 5, you can see that there is a Check Point object for the firewall, two Nodes objects (one for Laptop B and one for router WEB1) and two Networks objects (one each for the inside and outside network addresses). To allow all outbound traffic, rule 2 is created. As you can see, the Internal object is referred in rule 2 as the source. If the internal network number is changed for whatever reason, you just need to update the Internal network object on the Network Object tree. Any reference to it in the security policy will be automatically updated! To selectively allow inbound traffic, rules 3 and 4 are created. Rule 3 allows Laptop B to access WEB1 for telnet service only, and this will be logged. Rule 4 allows all traffic from Partner_Net to WEB1 for telnet and TFTP only, which is also logged.
Configuration Verification
The setup is now complete! If you have followed all the above steps carefully, it should work. Let’s try a couple of verification steps to ensure all works as expected.
1. Verify that both NICs have received addresses from D1. On D1, execute:
WAN#sh ip dhcp bindings
Bindings from all pools not associated with VRF:
IP address Client-ID Lease expiration Type
192.168.124.100 0108.0046.bfc0.3d Mar 02 2002 12:05 AM Automatic
192.168.124.101 0100.a0d1.31f0.f5 Mar 02 2002 12:05 AM Automatic
2. From inside the CPFW virtual machine, ping both inside and outside endpoints to ensure connectivity. You can’t ping the firewall from any of the endpoints because it drops any ICMP packets sent to itself (Rule 1).
3. On Laptop B, open the browser and access WEB1 with its IP address. If firewall rules are set as above, you should see the following.
Fig. 6: Basic Web server of WEB1 as seen from Laptop B.
To verify that web access is logged as per the rule definition, open SmartView Tracker, which is a log tracking application of the SmartConsole suite. In Fig. 7, the last three lines of logs in green represent the allowed access to www.km.net web traffic from 192.168.124.100.
Fig. 7: Logs from the firewall accessed using SmartView Tracker.
4. Now, try to access a service that is not allowed from the outside network. I tried to traceroute from Laptop B to WEB1, and this is what happened:
C:\tmp>tracert 192.168.100.2
Tracing route to 192.168.100.2 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 ^C
The firewall has dropped the traffic as expected. Check the logs and verify that Cleanup Rule has kicked in!
That’s it! I hope this assists you in your journey. I would love to hear your experience as well..
Sunday, June 7, 2009
Thursday, June 4, 2009
IP over ATM Configuration on Dynamips
Introduction
After searching everywhere with limited success for a tutorial on ATM configuration on Dynamips, I decided to write one here bringing together the whole process to make it easier for others. In this virtual lab, I will setup a lab for IP over ATM configuration on a single laptop running Windows XP, dual-core 1.8 GHz CPU with 1.5 GB RAM.
Scenario
In this lab, I will show how to configure IP over ATM using two Cisco 7200 routers and one ATM switch provided by Dynamips. Since the ATM function is only simulated at a simplistic level, we will not be able to get full ATM switch functionalities. However, this is still useful for someone to have some hands-on ATM experience. I will setup one PVC for data access. I will also connect one router to an Ethernet switch, which is linked to my laptop's loopback adapter. This permits testing from the command prompt, as well as to use the TFTP client on my XP to download the configs from the routers. Finally, once the IP connection is established, OSPF routing protocol is enabled to allow end-to-end access.
Dynagen .net file
To map the above network design for emulation, you need to understand the syntax of dynagen’s .net. I have realized the setup using the following:
autostart = false
ghostios = true
sparsesmem = true
mmap = true
model = 7200
[localhost]
[[7200]]
image = \Program Files\Dynamips\images\C7200-AD.image
ram = 256
idlepc = 0x62b0b568
[[ROUTER R1]]
f0/0 = S1 1
a4/0 = A1 1
[[ETHSW S1]]
1 = access 1
2 = dot1q 1 NIO_gen_eth:\Device\NPF_{192F6952-5AEA-4B4A-8AC0-B07086BA6FAC} #loopback0
[[ATMSW A1]]
1:0:5 = 2:0:5 # qsaal (pvc 0/5)
1:0:16 = 2:0:16 # ilmi (pvc 0/16)
1:1:10 = 2:1:20 # user (pvc 1/10 at R1 and pvc 1/20 at R2)
[[ROUTER R2]]
a4/0 = A1 2
The most important part of this setup is the VPI:VCI details of the ATM switch. There are three lines of VCs here, which represent a PVC for ATM signalling, a PVC for ILMI messages and a PVC for user data connection, respectively. These numbers must then match accordingly with the device configuration.
Detail Device Configuration
Since this is a rather simple and straightforward process, I will go direct to the specific configurations.
1. Configure the IP address of ATM interfaces of R1 and R2. Then bring up those interfaces. Here is R1’s interface configuration:
interface ATM4/0
ip address 10.1.1.1 255.255.255.0
atm ilmi-keepalive 10
2. Configure the QSAAL and ILMI PVCs on both routers. QSAAL is not necessary for PVCs but included here for completeness. On R1:
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
3. Configure the PVC for data access. The PVC must match the values you have specified in the .net file. Specify IP protocol and remote peer's IP address. Then, specify the encapsulation. On R1, it will look like this:
pvc Data 1/10
protocol ip 10.1.1.2 broadcast
encapsulation aal5snap
4. Verify the configurations.
R1#sh atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
4/0 1 0 5 PVC SAAL UBR 155000 UP
4/0 2 0 16 PVC ILMI UBR 155000 UP
4/0 Data 1 10 PVC SNAP UBR 155000 UP
The following output shows that ILMI state is UpAndNormal and the peer address. In this case, the peer is actually R2. In a real setting, this should be the ATM switch providing the UNI interface.
R1#sh atm ilmi-status
Interface : ATM4/0 Interface Type : Private UNI (User-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled/Up (10 Sec 4 Retries)
ILMI State: UpAndNormal
Peer IP Addr: 10.1.1.2 Peer IF Name: ATM4/0
Peer MaxVPIbits: 8 Peer MaxVCIbits: 10
5. If all appears as above, ATM configuration is complete! Ping the remote ATM interface for verification.
R1#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/88 ms
6. You now have an IP link across the ATM cloud. So you can run anything else above it. Let’s try a routing protocol, like OSPF, which will then allow R2 to be reachable from XP’s loopback. On R1, you will have:
interface FastEthernet0/0
ip address 192.168.10.1 255.255.255.0
!
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 1
To enable XP’s loopback to get a dynamic address, I enabled DHCP server on R1 (configuration is not shown here). Also, as OSPF supports different types of network, we need to designate a suitable type for the ATM interface, which is a non-broadcast multi-access (NBMA) medium. In this network, we only have two routers, so a point-to-point type is sufficient.
interface ATM4/0
ip address 10.1.1.1 255.255.255.0
ip ospf network point-to-point
7. Verify that OSPF is working.
R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.10.1 0 FULL/ - 00:00:38 10.1.1.1 ATM4/0
R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
...text snipped...
Gateway of last resort is not set
O IA 192.168.10.0/24 [110/2] via 10.1.1.1, 00:06:01, ATM4/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, ATM4/0
8. Ping the XP’s loopback interface from R2 to verify end-to-end connectivity.
R2#ping 192.168.10.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/35/84 ms
That’s it! Hope you find this useful.
After searching everywhere with limited success for a tutorial on ATM configuration on Dynamips, I decided to write one here bringing together the whole process to make it easier for others. In this virtual lab, I will setup a lab for IP over ATM configuration on a single laptop running Windows XP, dual-core 1.8 GHz CPU with 1.5 GB RAM.
Scenario
In this lab, I will show how to configure IP over ATM using two Cisco 7200 routers and one ATM switch provided by Dynamips. Since the ATM function is only simulated at a simplistic level, we will not be able to get full ATM switch functionalities. However, this is still useful for someone to have some hands-on ATM experience. I will setup one PVC for data access. I will also connect one router to an Ethernet switch, which is linked to my laptop's loopback adapter. This permits testing from the command prompt, as well as to use the TFTP client on my XP to download the configs from the routers. Finally, once the IP connection is established, OSPF routing protocol is enabled to allow end-to-end access.
Dynagen .net file
To map the above network design for emulation, you need to understand the syntax of dynagen’s .net. I have realized the setup using the following:
autostart = false
ghostios = true
sparsesmem = true
mmap = true
model = 7200
[localhost]
[[7200]]
image = \Program Files\Dynamips\images\C7200-AD.image
ram = 256
idlepc = 0x62b0b568
[[ROUTER R1]]
f0/0 = S1 1
a4/0 = A1 1
[[ETHSW S1]]
1 = access 1
2 = dot1q 1 NIO_gen_eth:\Device\NPF_{192F6952-5AEA-4B4A-8AC0-B07086BA6FAC} #loopback0
[[ATMSW A1]]
1:0:5 = 2:0:5 # qsaal (pvc 0/5)
1:0:16 = 2:0:16 # ilmi (pvc 0/16)
1:1:10 = 2:1:20 # user (pvc 1/10 at R1 and pvc 1/20 at R2)
[[ROUTER R2]]
a4/0 = A1 2
The most important part of this setup is the VPI:VCI details of the ATM switch. There are three lines of VCs here, which represent a PVC for ATM signalling, a PVC for ILMI messages and a PVC for user data connection, respectively. These numbers must then match accordingly with the device configuration.
Detail Device Configuration
Since this is a rather simple and straightforward process, I will go direct to the specific configurations.
1. Configure the IP address of ATM interfaces of R1 and R2. Then bring up those interfaces. Here is R1’s interface configuration:
interface ATM4/0
ip address 10.1.1.1 255.255.255.0
atm ilmi-keepalive 10
2. Configure the QSAAL and ILMI PVCs on both routers. QSAAL is not necessary for PVCs but included here for completeness. On R1:
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
3. Configure the PVC for data access. The PVC must match the values you have specified in the .net file. Specify IP protocol and remote peer's IP address. Then, specify the encapsulation. On R1, it will look like this:
pvc Data 1/10
protocol ip 10.1.1.2 broadcast
encapsulation aal5snap
4. Verify the configurations.
R1#sh atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
4/0 1 0 5 PVC SAAL UBR 155000 UP
4/0 2 0 16 PVC ILMI UBR 155000 UP
4/0 Data 1 10 PVC SNAP UBR 155000 UP
The following output shows that ILMI state is UpAndNormal and the peer address. In this case, the peer is actually R2. In a real setting, this should be the ATM switch providing the UNI interface.
R1#sh atm ilmi-status
Interface : ATM4/0 Interface Type : Private UNI (User-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled/Up (10 Sec 4 Retries)
ILMI State: UpAndNormal
Peer IP Addr: 10.1.1.2 Peer IF Name: ATM4/0
Peer MaxVPIbits: 8 Peer MaxVCIbits: 10
5. If all appears as above, ATM configuration is complete! Ping the remote ATM interface for verification.
R1#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/88 ms
6. You now have an IP link across the ATM cloud. So you can run anything else above it. Let’s try a routing protocol, like OSPF, which will then allow R2 to be reachable from XP’s loopback. On R1, you will have:
interface FastEthernet0/0
ip address 192.168.10.1 255.255.255.0
!
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 1
To enable XP’s loopback to get a dynamic address, I enabled DHCP server on R1 (configuration is not shown here). Also, as OSPF supports different types of network, we need to designate a suitable type for the ATM interface, which is a non-broadcast multi-access (NBMA) medium. In this network, we only have two routers, so a point-to-point type is sufficient.
interface ATM4/0
ip address 10.1.1.1 255.255.255.0
ip ospf network point-to-point
7. Verify that OSPF is working.
R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.10.1 0 FULL/ - 00:00:38 10.1.1.1 ATM4/0
R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
...text snipped...
Gateway of last resort is not set
O IA 192.168.10.0/24 [110/2] via 10.1.1.1, 00:06:01, ATM4/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, ATM4/0
8. Ping the XP’s loopback interface from R2 to verify end-to-end connectivity.
R2#ping 192.168.10.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/35/84 ms
That’s it! Hope you find this useful.
Subscribe to:
Posts (Atom)