Tuesday 29 December 2015Tuesday 29 December 2015

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 receivers 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.

Thursday 24 December 2015

CLI: Create a Self IP to Allow BigIP Management

Create a Self IP to Allow BigIP Management via the CLI

This article details how to create a self ip to allow bigip management on the command line. The need arose when a primary firewall failed and the only entry to the network was an ssh session to the DR BigIP via a jump box.

For the purpose of this article we are using the following IP representations:

x.x.x.100 – eXternal IP

i.i.i.100 – Internal IP

1. Enter the traffic management shell tmsh:

[admin@bigip:Active:Standalone] tmsh
admin@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)#

2. If there is already a self IP on the external vlan you can modify the port lockdown settings to allow https to the machine but only if you have no virtual servers already using the https port.

admin@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify net self x.x.x.100 allow-service default

This will allow all the default ports, shown by “list net self-allow”:

admin@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net self-allow
net self-allow {
defaults {
ospf:any
tcp:domain
tcp:f5-iquery
tcp:https
tcp:snmp
tcp:ssh
udp:520
udp:cap
udp:domain
udp:f5-iquery
udp:snmp
}
}

3. In this case the self IP was already used by a virtual server with a pool of https machines behind it so a new self ip was necessary. Choose another ip on the same external subnet:

admin@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net self x.x.x.101/32 vlan external allow-service default

4. We can now list our self ips and the level of access associated with them:

admin@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net self
net self x.x.x.101/32 {
address 90.152.115.244/32
allow-service {
default
}
traffic-group traffic-group-local-only
vlan external
}
net self x.x.x.101 {
address 90.152.115.243/29
allow-service {
none
}
traffic-group traffic-group-local-only
vlan external
}
net self i.i.i.100 {
address i.i.i.100/24
allow-service {
default
}
traffic-group traffic-group-local-only
vlan internal
}

5. We can now access our BigIP on https://x.x.x.101 !

Wednesday 9 December 2015Sunday 24 July 2016