Got a situation which has to remotely configure a factory reset checkpoint 2205 appliance. Unfortunately I have to do basic configuration from remote first until get internal interface configured proper ip, then I am able to run first time wizard to continue set up with new ip address. As we know after checkpoint appliance reset to factory, internal interface is 192.168.1.1.which usually not reachable for my remote access.
Good thing is I have a remote console access through Avocent Console Server 5000 series. I was thinking I can configure internal interface ip first through console. But after entered into console, I found I got into a stuck situation which is no way to issue sysconfig / cpconfig before finish first time wizard through web GUI interface.
After a google search, quickly found this post at
https://www.cpug.org/forums/check-point-utm-1-appliances/10713-setup-utm-1-via-serial-console.html
Two commands can easily resolve my problem now. Get into expert mode, then touch two magic files.
touch /opt/spwm/conf/wizard_accepted
touch /opt/spwm/conf/wizard_post_install.accepted
Then I am able to issue sysconfig to set up Internal interface ip and gateway. After all done, remove those two touched files from expert mode:
rm /opt/spwm/conf/wizard_accepted
rm /opt/spwm/conf/wizard_post_install.accepted
Then I am able to remotely run first time wizard with new ip address. CPUG saved my life again.
Tuesday, April 24, 2012
Sunday, April 1, 2012
Checkpoint SPLAT Manual Proxy ARP Configuration Example
Checkpoint manual NAT configuration is a quite useful method to remedy the weakness of auto nat . For me, I always mix them according to different scenarios although there are quite discussion which is better in a dispute CPUG post. Use auto nat as possible as I can when starting projects or network, then slowly to roll out manually NAT when complexity components added.
Here is a recent scenario which manual NAT used. Client need to use 10.94.30.53 to access DMZ sftp server 172.17.3.53. Auto NAT should be able to resolve it in 30 seconds configuration. Unfortunately, sftp server 172.17.3.53 is facing multiple checkpoint firewalls and it has to be nat-ed to another segment as well. So manually nat will be the only choice here.
1. Enable Manual NAT from global properties
2. Create Manual NAT rule
3. Add manual proxy arp entry into local.arp file
echo "10.94.30.53 AA:BB:CC:DD:EE" >> $FWDIR/conf/local.arp
note: AA:BB:CC:DD:EE is the mac address of your SPLAT firewall 10.94.30.42 interface. If use clustering implementation, all of cluster members local.arp file need to be modified based on member's interface mac address.
4. Push policy to enable NAT rule and merge this manual NAT record into arp table.
5. Verify with fw ctl arp command
[CP-FW]# fw ctl arp
(10.94.30.53) at AA:BB:CC:DD:EE
Here is a recent scenario which manual NAT used. Client need to use 10.94.30.53 to access DMZ sftp server 172.17.3.53. Auto NAT should be able to resolve it in 30 seconds configuration. Unfortunately, sftp server 172.17.3.53 is facing multiple checkpoint firewalls and it has to be nat-ed to another segment as well. So manually nat will be the only choice here.
1. Enable Manual NAT from global properties
2. Create Manual NAT rule
3. Add manual proxy arp entry into local.arp file
echo "10.94.30.53 AA:BB:CC:DD:EE" >> $FWDIR/conf/local.arp
note: AA:BB:CC:DD:EE is the mac address of your SPLAT firewall 10.94.30.42 interface. If use clustering implementation, all of cluster members local.arp file need to be modified based on member's interface mac address.
4. Push policy to enable NAT rule and merge this manual NAT record into arp table.
5. Verify with fw ctl arp command
[CP-FW]# fw ctl arp
(10.94.30.53) at AA:BB:CC:DD:EE
Subscribe to:
Posts (Atom)