Posted on

Checkpoint: Long Delay When Logging In Via SSH or Console

How to mitigate the issue where this a long delay when logging in via SSH or console.

When an SSH session is initiated to a linux box, the SSH server tries to perform a lookup on the client’s IP; in certain situations this is not going to be possible, e.g.:

  • the configured DNS server is offline
  • the firewall / smartcentre cannot talk to the configured DNS because of a policy
  • the external internet connection is down etc.etc.

This DNS timeout manifests itself as an incredibly long delay for the user trying to log in – fortunately there is a very quick fix for this:

  • delete the nameservers entirely!
  • configure nameservers that the machine is able to reach
  • use internal nameservers if your internet connection is flaky

This is the case for all Checkpoint linux-based machines as well as IPSO and Gaia.

Related posts:

Posted on

Checkpoint: How To Reset “expert” Mode Password On SecurePlatform

This article describes how to reset the expert mode password on SecurePlatform for your Checkpoint appliance or open server.

For Open Servers

Obtain the live linux distribution Knoppix. You can download the current version from the Knoppix website: http://www.knoppix.net

1. Boot the machine from the Knoppix CD – you can use a built-in CD/DVD drive or an external one.

2. Once the desktop appears, click on the icon to open a terminal window, the run the following commands. See also the “Notes” section below.

$ su
# mkdir /checkpoint
# mount /dev/hda2 /checkpoint
# mount /dev/hda1 /checkpoint/boot
# chroot /checkpoint
# /bin/expert_passwd

3. At this point you are prompted to enter a password – type in the new password twice.

4. To change the regular cpshell admin users’s password:

# passwd admin

You are prompted to enter a password.

Type in the new password twice.

5. Run the “exit” and then the “reboot” command.

6. Remove the Knoppix CD and boot normally.

You can now log in as the user ‘admin’ and log in to Expert mode with each of the new passwords you just assigned.

———————

Notes for Point 2:

If the mount /dev/hda2/checkpoint command fails, use the following command instead:

/dev/hda3/checkpoint

If the system has SATA drives then use the following command:

mount /dev/sda8 /checkpoint and /dev/sda2 /checkpoint/boot

An easy way to find drive mappings is to use gparted from Knoppix “K menu” > system > gparted.

Knoppix will not let you run this unless you have root and a password for root.

To create valid passwords use sudo passwd, i.e.

# sudo passwd root

You need to mount the root partition on /checkpoint, and the boot partition on /checkpoint/boot

———————

For UTM-1 Appliances *AND* Open Servers

1. Obtain the Red Hat boot CD. (The current Fedora Core boot CD will as also work).

2. At the boot prompt, boot from the Red Hat boot CD with the following command: “linux rescue ”

3. When prompted, answer the questions presented by the boot process.

4. The system is mounted on the hard drive, and its location is indicated. Write down the system location (which should be: /mnt/sysimage/, or /mnt/sysimage/).

5. When the command prompt is displayed again, edit the following file (Vi editor should be available): /mnt/sysimage/boot/grub/grub.conf

Find the line that looks like this:

password --md5 <a bunch of scrambled numbers, letters, and symbols>

Add a ‘#‘ at the very beginning of that line. It should then look like this:

#password --md5 <a bunch of scrambled numbers, letters, and symbols>

6. Find a line that opens with the word ‘lock‘ and add a ‘#’ at the very beginning of that line.

7. Save and exit the editing session.

8. Reboot the machine.

9. Remove the boot CD from the CD-ROM drive before it boots from the CD (again).

10. When the following prompt appears:

GRUB … (the dots increase in number until it boots the default kernel)

Press the ‘Space‘ key. This should display the GRUB menu.

11. Select the line that has the word ‘Maintenance‘ in it and press ‘Enter‘ key.Note: if this step fails to boot into the Maintenance mode, do the following:

Select the line that contains ‘maintenance‘ and press ‘e‘ key.You are allowed to edit the GRUB options for this boot option.

  • Press ‘b‘ key to boot this option.
  • SecurePlatform boots until a prompt similar to the following appears:sh-bash 2.0.5#
  • Change the passwords for:
    • A user, like ‘admin‘, run:
      \ passwd admin
    • For Expert mode, run:
      /bin/expert_passwd
  • Reboot.

 

 

 

Related posts:

Posted on

f5 VE on ESXi: “The requested media for interface 1.1 is invalid.”

This article addresses the following error: “The requested media for interface 1.1 is invalid” when using the f5 virtual edition on ESXi.

Once possible reason for this error is mentioned under “Known Issues” in the release notes for 11.x e.g. : http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ve-11-4-0.print.html

The entry reads as follows:

ID 352856 “If an SCF is migrated between BIG-IP VE running on non-similar hypervisor software, a validation error may prevent configuration loading. Loading the configuration … BIGpipe interface creation error: 01070318:3: “”The requested media for interface 1.1 is invalid.”” When this condition is encountered on BIG-IP Virtual Edition, configuration may be fixed for import by removing the entire line that contains “”media fixed”” statements for each interface.”

If however, like me, you cannot find the “media fixed” anywhere in your bigip_base.conf file then it is most likely to be an issue with the vmxnet3 network adapters that are deployed by default.

My management adapter, also vmxnet3, came up fine but the other 1.1, 1.2 and 1.3 interfaces remained uninitialised and any attempts to edit just threw the error above.

My solution was to change the adapter types in the .vmx file for the virtual machine:

1. Shut down the machine2. SSH / console into your ESXi host and change directory to /vmfs/volumes/<datastore_name>/<vm_directory>

 

 

 

 

 

3. Use the “vi” command to edit the <your_vm>.vmx file and change the “vmxnet3” entries to “e1000.” Note: you can generally leave the first interface (management) as vmxnet3.

 

 

 

 

 

 

 

 

 

 

4. Save the file and start up your machine – you should now be able to initialise and edit your interfaces under “Network” -> “Interfaces”

Job done, let me know if this works / doesn’t work for you!

Related posts:

Exit mobile version
%%footer%%