Management Interface (eth0) assigned via DHCP - cannot remove the static IP of the interface

[NoodleOps]

Hello,

For a project that I am working on, where the Check Point VM can be destroyed and brought back up, I am trying to automatically assign the Management interface via DHCP client. This works fine, so when my VM boots, it will get the IP address via DHCP as I would expect.

Now my problem, is when I go to https://<dhcp-assigned-ip>/smartconsole, I can see a different IP, which was the one I entered when I went through the First Time Wizard.

Here are some logs from the device:

cpfw> show interface eth0
state on
mac-addr 08:4f:a9:01:00:00
type ethernet
link-state link up
mtu 1500
auto-negotiation off
speed N/A
ipv6-autoconfig Not configured
monitor-mode Not configured
duplex N/A
link-speed Not configured
comments
ipv4-address 10.194.59.200/24 (dhcp)
ipv6-address Not Configured
ipv6-local-link-address Not Configured

Statistics:
TX bytes:30073470 packets:211552 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:29424053 packets:219016 errors:0 dropped:3 overruns:0 frame:0

SD-WAN: Not Configured
cpfw> show configuration interface
set interface eth0 state on
set interface eth0 auto-negotiation off
set interface eth0 ipv4-address 192.168.122.105 mask-length 24
set interface eth1 state off
set interface eth1 auto-negotiation off
set interface eth2 state off
set interface eth2 auto-negotiation off
set interface lo state on
set interface lo ipv4-address 127.0.0.1 mask-length 8
cpfw> show configuration dhcp-client
add dhcp client interface eth0
set dhcp client interface eth0 timeout 60
set dhcp client interface eth0 retry 300
set dhcp client interface eth0 reboot 10
cpfw>

You can see the command `show interface eth0` display the correct IP address, the one assigned by DHCP. Which is great.

But when I look at the configuration, there is the line: `set interface eth0 ipv4-address 192.168.122.105 mask-length 24`

I have tried to remove this line, but without success.

cpfw> delete interface eth0 ipv4-address
NMSETH0029  Management interface must have an IP address.
cpfw>

You will see attach the screenshot showing the view from a SmartConsole, where we have the same static IP, but not the one assigned via DHCP.

Now my question is pretty simple: is this something that can work, and if so, how can I do it? 

Many thanks!
Seb

[NoodleOps]

Actually, even when trying to fix it manually, by changing the IP address, it doesn't work:

cpfw> set interface eth0 ipv4-address 10.194.59.200 mask-length 24
NMSETH0029  Dhcp client is enabled for this interface, IP address can't be configured.

[_Val_]

Your management server should not have a DHCP address in the first place. SIC with the security GWs will not work properly if the IP of your SMS is changing all the time

You need to rethink your design.

[NoodleOps]

Thank you for your reply.

I was able to connect to the SmartConsole and manually update the IP address there, and it worked. Is there a way I can perform this operation via CLI, or worse case via API call?

[NoodleOps]

It's only at the creation of the VM that I want to use DHCP to assign the IP address, once the VM is created, that IP will not change. But the disk I am using to create the VM has already gone through the First Time Wizard. It was easier for me to do it this way, rather than using the script described in this discussion, which makes it a more complex solution.

[the_rock]

Maybe this?

clish> add interface eth0 alias <dhcp-ip>/24
clish> save config

[NoodleOps]

This is a great idea, I forgot about this command, I saw it a little while ago. It does work pretty well, but it doesn't solve my problem.

What I've now realised, is when I delete and recreate my VM based on the vagrant box I have created, I have the following:

1. In the UI (https://dhcp-ip/) I can see the correct IP is showing, but when I look in the CLI, I do have the static IP I used when creating the box, which is no longer used...

cpfw> show configuration interface
set interface eth0 state on
set interface eth0 auto-negotiation off
set interface eth0 ipv4-address 192.168.122.105 mask-length 24
cpfw> show configuration dhcp-client
add dhcp client interface eth0
set dhcp client interface eth0 timeout 60
set dhcp client interface eth0 retry 300
set dhcp client interface eth0 reboot 10

So this is pretty good, but a bit annoying that I can't remove the line: set interface eth0 ipv4-address 192.168.122.105 mask-length 24

2. On the SmartConsole, this is where I need to do a manual update, but I would like to do it via API. If I go to https://<dhcp-ip>/smartconsole I can see the IP of my firewall is showing the one of the old address, not the dhcp. I need to change it from the UI, using a proper SmartConsole, as the WebUI doesn't allow me to change this. Is there a way to do this via API?

It also seems that I need to do it in two places (as per the screenshot), I would really appreciate some help on where to find the API documentation to do those actions programmatically, instead of manually.

 

[Bob_Zimmerman]

You can, it's just a headache because you have to include all the interfaces in the object you pass in the API call.

What exactly are you building? You mentioned Vagrant. Is this about reproducible lab environments?

[NoodleOps]

---

What exactly are you building? You mentioned Vagrant. Is this about reproducible lab environments?

---

It's exactly this! I am using netlab (https://netlab.tools) to create a virtual lab, similar to Eve-NG or GNS3, but quite different as well. I have a number of different vendors and platform, and the goal is to have a lab fully automated, so there is no manual action to get it to its intended state. netlab deals with a huge amount of that configuration for the supported vendors, and for the other, I am using some script to apply what I want.

My issue with Check Point, is related to the First Time Wizard, so I decided to create a vagrant box after completing the FTW. This way, when I create a new VM based on the vagrant box, it would have already completed this step, ready to be used in the lab, and for the script to apply the specific configuration that I want (ospf/lldp/ntp...)

But obviously, there is now the issue with the management IP address, as the VM used to create the box is not on the same subnet as the subnet for the lab, and I'm not sure if I can do this, hence I am playing with DHCP. I understand DHCP is not recommended for the management interface, but once the VM is created, the DHCP address will not change. So it will stay the same for the life of that VM.

I also attempted to use automation for the FTW, but without success, and it's not my preferred option, as I would prefer the FW to be ready once created and booted.

You can, it's just a headache because you have to include all the interfaces in the object you pass in the API call.

---

I don't mind this too much, if that could solve my problem, I'd be happy to find a way to generate the payload based on all the interfaces.

Unless of course, there is another (simpler?) approach I haven't considered!

[Bob_Zimmerman]

I would just use cloud-init to handle the first-time config when the VM is built. I did something similar a while ago and documented my process for building Check Point VMs in a repeatable way. The advantage of doing the first-time config from scratch is you get a new 15-day plug-and-play license each time.

[NoodleOps]

This is interesting, I tend to disregard every mention of `cloud-init` because I struggle with it, but maybe it's now time to embrace it...

If I understand correctly, I need to:

1. check this page to create my cloud-init config: https://support.checkpoint.com/results/sk/sk179752, somehow adding all the management and gateway config together as I am using the standalone mode. I will later need to find a way of generating this file automatically to ensure it has the correct variables (password, IP addresses...)

2. Then I need to create my VM, using the disk image and the ISO created from the cloud-init config, following the instructions here. I will search for the `virt-install` command to do so (it would have been nice to have this in the instructions page, but with a bit of AI, and some testing it shouldn't be too hard)

3. Now my VM should be pretty much good to go, I will want to add the option to allow the API from any IP, if I'm not doing this as part of the cloud-init, I could run the following:

# Set up the API to allow connections from remote clients.
login "System Data"
mgmtCmd set api-settings accepted-api-calls-from "All IP addresses"
logout
api restart

Does this sound good, am I missing something? I would be more than happy to share the details on how to do it, step by step, to make it easy to reproduce, once I get to the bottom of it (but I'm not there yet!)

Last comment, I have read something about Blink image, is this something I should investigate/consider, would this make the process easier, or is this just to use a more recent version (with hotfixes) of the OS?

Thanks for your help on this!

[Bob_Zimmerman]

1. Exactly. The cloud-init config is basically config_system, but in YAML. It has a few options which aren't in config_system.

2. You can try building a config drive like that, but I never got it to work for me. Might have just been a quirk of my VM environment. I ended up taking the web service option.

3. Note that 'login', 'mgmtCmd', and 'logout' there are not normal commands. They're functions defined earlier in the script.

You may be able to use Blink to skip some of the initial installation (and to save time installing a jumbo). I personally haven't had much luck with that, but again, might have been a quirk of my environment.

[Bob_Zimmerman]

Actually, it looks like Vagrant has some support for providing data to cloud-init. Looks almost undocumented, but that could be a better option than building a config drive.

[NoodleOps]

Thanks, I will investigate both approach, it might (and likely will) take me some time. At the moment, I don't think there is one approach that looks easier than another at the moment, so it'll be a slow ramp up on my side to understand each options, and play with those.

Thank you very much for your inputs and advice, it gives me a lot to think of, and also a good guidance on what to investigate next!

[_Val_]

Once again, I want to stress my previous message:

Dynamic IP address for the management server is not supported. Even if you find a reliable way to update your MGMT IP address on the management object itself, this situation is not covered by the product design.

Once your MGMT server IP changes, you will lose the ability to install policy and to maintain certificates. MGMT to GW communication is covered by the implied rules, and the SMS IP is hardcoded there when you install the policy. The CRL distribution point will not be available for certificate validation, and SIC will also not work once the MGMG IP shifts.

In my opinion, this is a very bad idea. I urge you to rethink the design and the conditions. Today, you cannot have your security management server using DHCP.

[the_rock]

EXCELLENT points @_Val_ 

[NoodleOps]

I understand the management address is not designed to be using DHCP, but in my case, I don't know what the management subnet will be where the management interface will be connected to. This is the part that can vary.

I only want to be able to auto assign this IP when the VM gets created, then I'm more than happy to keep it as a fix IP and perform the rest of the configuration with this fixed IP.

For all other devices in this virtual lab, DHCP is used to assigned the management address, but when the lab is up, there is no change in the management IP. Behind the scene it is a static assignment, based on a subnet which may vary from one server to another.

I will test the cloud-init method (with config drive or using the Vagrant cloud-init), mixed with the script mentioned above to see if I can achieve what I want. I just want a ready to use Check Point FW in my lab, with zero manual configuration, and knowing that I am not sure what the management subnet will be until I start the lab... easier said than done 😀

If this is too difficult, my other option would be to create the vagrant box with the IP address that the lab will use. I need to create easy to use instructions on how to create such box (knowing that the IP we want to use, may not be reachable at the time of the box creation...)

[Chris_Atkinson]

For those playing along at home is the Firewall management interface being confused with the Security Management (SMS) IP address?

I assume these are gateways being deployed correct?

[the_rock]

As they say, its a bit of "catch 22" situation...

Andy

[_Val_]

Got it, lab environment, not production. It was not clear at the start. Good luck with that. When you figure this out, do share the process with the community.

Thanks,
Val

[NoodleOps]

Yes exactly, it's a pure virtual lab environment, I'm deploying on openserver (kvm) image with both Security Gateway and Security Management installed.

I'll be happy to share once/if I manage to get something🤞

[the_rock]

Please do, it would be really good to know!

[NoodleOps · Accepted solution]

I did not forget about the topic, I've just been slow to work on it... and I think I now have something interesting. Not yet in its final form, but getting a lot closer.

## Cloud-init file

#cloud-config
#
# user-data file for Check Point R81.20
#
# For more information, see:
# - https://support.checkpoint.com/results/sk/sk179752
# - https://community.checkpoint.com/t5/General-Topics/Management-Interface-eth0-assigned-via-DHCP-cannot-remove-the/m-p/259712

# Set the hostname
hostname: checkpoint-gw
# Set the admin password
password: admin123

# Login banner (shown at login prompt)
banner: |
  ======================
  Check Point CloudGuard
  This system is for authorized use only.
  ======================

# Message of the day (shown after successful login)
motd: |
  ==================================================================
  Welcome to Check Point CloudGuard Network Security
  ==================================================================
  This is a LAB/TEST environment created for educational and
  testing purposes.
  
  Security Gateway and Security Management components are
  installed on this system, you can access both portals:
    - GAiA Portal GUI    : https://<eth0-ip-address>/
    - SmartConsole WebGUI: https://<eth0-ip-address>/smartconsole
  
  By using this product you agree to the terms and conditions
  as specified in https://www.checkpoint.com/download_agreement.html
  ==================================================================


# Configure the network
# (DHCP is used by default if this section is commented out)
#
# To use a static IP, uncomment the following lines:
# network:
#   version: 1
#   config:
#     - type: physical
#       name: eth0
#       subnets:
#         - type: static
#           address: 192.168.1.10
#           netmask: 255.255.255.0
#           gateway: 192.168.1.1

# Run First Time Wizard in standalone mode (Security Gateway + Security Management)
# This will be executed on the first boot
runcmd:

  # Step 1: set expert password (non-interactive)
  - |
    cat > /tmp/expert_pwd.txt << 'EOF'
    admin123
    admin123
    EOF
    clish -c "set expert-password" < /tmp/expert_pwd.txt
    rm /tmp/expert_pwd.txt

  # Step 2: Run First Time Wizard configuration
  # maintenance_hash was generated with the password admin123
  # You can generate a new hash by using the command `grub-mkpasswd-pbkdf2`, before recreating the VM.
  - |
    config_system -s "install_security_gw=true\
    &install_security_managment=true\
    &install_mgmt_primary=true\
    &mgmt_admin_radio=gaia_admin\
    &mgmt_gui_clients_radio=any\
    &maintenance_hash='grub.pbkdf2.sha512.10000.721029F548E36425A9E20E1454D0946E4A0C2ECE23250E6817C31556251C3F47BE7CE164114279E18C9D9783DCD2E3418C68AE0CD9007E437716195FC16CF005.EA75DE1D489B04E5EAEDB8010D60F4CE929F455E61B4EF9CB2E5E133BD974A2EEFC4F89EDD1A17CCDC448FDCDC711804FC04DB14E68CDCD70FA3881C0AB346E3'\
    &ftw_sic_key=aaaa\
    &primary=1.1.1.1\
    &timezone='Etc/GMT'\
    &upload_info=false\
    &upload_crash_data=false\
    &download_from_checkpoint_non_security=false\
    &download_info=false\
    &reboot_if_required=false"

  # Wait for the API to become available
  - sleep 60
  
  # Step 3: Configure API settings to accept calls from any IP
  - |
    API_PORT=$(api status | grep 'APACHE Gaia Port' | awk '{print $NF}')
    SESSION_FILE=$(mktemp)
    mgmt_cli --port "${API_PORT}" -d "System Data" -r true login > "${SESSION_FILE}"
    mgmt_cli --port "${API_PORT}" -s "${SESSION_FILE}" set api-settings accepted-api-calls-from "All IP addresses that can be used for GUI clients"
    mgmt_cli --port "${API_PORT}" -s "${SESSION_FILE}" publish
    mgmt_cli --port "${API_PORT}" -s "${SESSION_FILE}" logout
    rm "${SESSION_FILE}"
  
  # Step 4: restart the SmartConsole (I had problem where it wasn't accessible)
  # https://support.checkpoint.com/results/sk/sk173968
  # - $MDS_FWDIR/webconsole/mwc.sh restart

  # Final step: reboot due to First Time Wizard
  - reboot

Create the file `user_data` with the content above, inside `file_structure/openstack/2015-10-15`

Once you have this file, you can create the ISO file:

`genisoimage -r -V config-2 -o /your-folder/cp_r81_20_config.iso /yourfolder/file_structure/`

And finally you can run the virt-install (using the qcow2 disk, maybe do a copy of the original disk, so you can start again in the future)

virt-install \
  --name=checkpoint-r8120-standalone \
  --ram=8192 \
  --vcpus=2 \
  --disk path=/yourfolder/cp_r81_20_disk.qcow2,bus=ide,format=qcow2 \
  --disk path=/yourfolder/cp_r81_20_config.iso,device=cdrom,readonly=on \
  --network=network:default,model=virtio \
  --graphics none \
  --import

I am still doing a few more tests, and afterwards I will check how to do this with vagrant, but right now it works exactly how I wanted!!

[the_rock]

Awesome!

[the_rock]

I have all the confidence what @Bob_Zimmerman  gave you will work. He is after all, API king.