Captive Portal Fails to Load Properly or Returns 404

Captive Portal Fails to Load Properly or Returns 404

This article describes how to fix the issue whereby captive portal fails to load, is returned only partially without the user / pass fields or returns a 404 error. This also mitigates issues with:slow access to a Mobile Access gateway on wireless or lossy networks.

The mechanism responsible for the problems is “SACK” – an acronym for Selective ACKknowledgment. The “SACK-permitted” option and “SACK” option alter the acknowledgment behavior of TCP:

SACK-permitted

The SACK-permitted option is offered to the remote end during TCP setup as an option to an opening SYN packet. The SACK option permits selective acknowledgment of permitted data. The default TCP acknowledgment behavior is to acknowledge the highest sequence number of in-order bytes. This default behavior is prone to cause unnecessary retransmission of data, which can exacerbate a congestion condition that may have been the cause of the original packet loss.

A packet capture on the client or gateway will typically show many retransmitted packets and ends with the client eventually sending RST packets to the gateway.

SACK

The SACK option allows the receiver to modify the acknowledgment field to describe noncontinuous blocks of received data, so that the sender can retransmit only what is missing at the receiver’s end.

Solution

Disable Selective-ACK by setting the value of cpas_tcp_do_sack kernel parameter to “0” (zero).

Procedure:

To Disable Selective-ACK on-the-fly, run:

[Expert@gateway]# fw ctl set int cpas_tcp_do_sack 0

Check that the value was accepted:

[Expert@gateway]# fw ctl get int cpas_tcp_do_sack

To disable the parameter permanently:

Edit the $FWDIR/boot/modules/fwkern.conf file using Vi editor to add a line with the format “parameter_name=value", in this case:

cpas_tcp_do_sack=0

Reboot the gateway after any changes to the $FWDIR/boot/modules/fwkern.conf file.

Notes:

  • Disabling Selective-ACK can impact networking throughput when client/server are using large TCP Windows and there is packet loss between these hosts.
  • In Cluster, perform the procedure on all cluster members.

Checkpoint: Find The Serial Number of IP Appliances Via CLI

Find The Serial Number of IP Appliances Via CLI

Sometimes it is necessary to find the serial number of IP appliances but you either don’t have physical access to the machine or someone has removed the sticker from the side or bottom. This article lists methods to retrieve the serial via the command line interface (CLI).

1. If you are physically next to the device, look for a label on the physical box.

2. If you are remotely accessing the firewall, log into Voyager, then look for “Unit SN” under the “Basic IPSO Information” section of the homepage.

3. On the CLI (either SSH or console), run the following IPSO command:

ipso[admin]# ipsctl hw:eeprom:serial_number

hw:eeprom:serial_number = 7Hxxxxxxxx4

OR

ipso[admin]# ipsctl -a | grep serial

ipso[admin]# ipsctl -a | grep "serial"
hw:eeprom:motherboard:serial_number = 94072202114
hw:eeprom:cpci_1:serial_number = 94072301073
hw:eeprom:cpci_2:serial_number = 94072301093
hw:eeprom:power_a:serial_number = SH52618
hw:eeprom:power_b:serial_number = SH52471
hw:eeprom:wx_3:serial_number = 94072202755
hw:eeprom:viper_4:serial_number = 94072300835
hw:eeprom:wx_1_1:serial_number = 94073601141
hw:eeprom:serial_number = 7Hxxxxxxxx4
hw:motherboard:serialnumber = 0
hw:chassis:serialnumber = 7Hxxxxxxxx4

This will give you all serial numbers related to different parts – the chassis is the last in the list and it is this serial number which is most commonly used.

4. In the clish shell (enter “clish” on the command line):

NokiaIP1260:102> show asset hardware
Chassis Serial Number: 7Hxxxxxxxx4
CPU Model: Pentium 4/XEON
CPU MFR: GenuineIntel
CPU Frequency: 2794587100
Memory: 1073741824
Disk 0 Model: STI Flash 8.0.0
Disk 0 Capacity: 128MB
Disk 1 Model: FUJITSU MHV2040AS
Disk 1 Capacity: 40007MB
Platform: IP1260
Bios Vendor: Hilo BIOS
Bios Version: 5.0-1.5
Bios Date: 10-19-2004
Motherboard Serial Number: 0
Motherboard Revision: B01
Motherboard Model: HILO-RCC1

5. For Nokia IP VPN devices:

hostname> show fru

MAIN (MOTHERBOARD) EEPROM FRU INFO:
-----------------------------------
Product Name: 10i
EEPROM info format rev num: 6
Number of slots: 0
MAC address count: 3
Base MAC address: 00:A0:8E:XX:XX:XX
System serial number: 7HXXXXXXXXX
System Agile part number: N806189001
System Agile H/W rev: C
Onboard MAC count: 3
System PCA Agile P/N base: 6187
System PCA Agile P/N suffix: 1

6. For former Nokia IPS platforms, please run the following command:

ip390ips ~ # cat /proc/nokia/nvram/serial_num

7. For UTM-1 EDGE devices, you can also use run the command:

EDGE:XX> show asset hardware

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.