Thursday, March 19, 2009

PIX 6.X - Configuring Logical / VLAN interfaces

Scenario:
The inside/ethernet1 interface of the PIX will be mapped to two VLANs, VLAN1 with IP address 192.168.1.2/24 and VLAN2 with IP address 192.168.2.2. The outside interface has IP address 10.199.248.225/24

Topology:



[Thanks to former colleague Dan for the image.]


PIX 6 Configuration:

interface ethernet1 auto
nameif ethernet1 inside security100
address inside 192.168.1.2 255.255.255.0

interface ethernet1 vlan2 logical
nameif vlan2 inside2 security50
address vlan2 192.168.2.2 255.255.255.0

Notes:
Your Physical Interface is (by default), your VLAN1.


PIX 7 Configuration:

interface Ethernet1
nameif inside
security-level 100
ip address 192.168.1.2 255.255.255.0
no shut

interface Ethernet1.2
vlan 2
nameif inside2
security-level 50
ip address 192.168.2.2 255.255.255.0
no shut

Tuesday, July 29, 2008

BIG-IP v4 - Common bigstart commands

The bigstart is the command used for controlling the F5 BIGIP daemons/services. For Windows users, this is synonymous to Control Panel -> Admin Tools -> Services. Here is BIG-IP v4.x bigstart command syntax dissected:


SYNTAX

bigstart [-d] action [id]

  • -d
    Lists the execution order of the services for the specified action command.

  • action
    Performs whatever action is specified. Values are startup, shutdown, active, standby, status, reinit and restart.

  • id
    The specific service on which the specified action would be acted upon. That is, for example, bigstart shutdown named will shutdown the service named.


ACTIONS
  • startup
    The target program commences. Bigstart startup is called from /etc/rc before rc.local is executed.

  • shutdown
    The target program should shut down gracefully.

  • active
    The target program takes any action necessary whenits host BIG-IP becomes the active unit. Bigstart active is called when the BIG-IP becomes the active
    BIG-IP.

  • standby
    The target program takes any action necessary when its host BIG-IP becomes the standby unit.

  • reinit
    The target program initializes itself from its configuration data.

  • restart
    The target program is to be restarted. Typically this means the program will be stopped then started.

  • status
    The target program responds by providing some status information.




SCRIPT AND ACTION DIRECTORIES

The scripts for each of the services are in the /etc/bigstart/scripts directory.

Each of the actions have their own individual action directories in /etc/bigstart/action. Files in the action directories are actually symbolic links pointing to the actual scripts in the /etc/bigstart/scripts directory.


SYMBOLIC LINK FORMAT

Each symbolic link in the action directories follow this naming convention:

SNNString

NN - two digit number that determines the execution order of the services.

String - name of the service

The contents of, say, /etc/bigstart/startup will correspond to the output of the command bigstart -d startup.


CASE STUDY: PREVENT A SERVICE FROM RUNNING ON STARTUP

Scenario: In our setup, the name service named of the BIG-IP is not being used. Hence, it was decided to be not started during device startup.

Procedure:
  1. Verify the status of the named service:

    bigip:# bigstart status named
    bigstart: status named
    status named: (pid=1130) is running
    bigip:#


  2. Shutdown the service:

    bigip:# bigstart shutdown named
    bigip:#


  3. Remove the named symbolic link in the startup action directory:

    bigip:# cd /etc/bigstart/startup
    bigip:/etc/bigstart/startup# ls *named*
    S10named
    bigip:/etc/bigstart/startup# rm S10named
    remove S10named? y
    bigip:/etc/bigstart/startup#


Verification
  • Verify that the service is not in the execution order for the startup action.

    bigip:# bigstart -d startup
    ...
    <output omitted>
    ...


  • Verify status of the current running status of the service:

    bigip:# bigstart status named
    bigstart: status named
    status named: is not running
    bigip:#



Friday, July 25, 2008

NetApp C6200: Configuring HTTP Acceleration

The NetCache NetApp C6200 appliance can be configured for web acceleration, aka reverse proxy. The following are the bare minimum steps to configure HTTP acceleration on this device.

Scenario:
Below are the details about the web server that will be proxied by the NetApp C6200.
  • Hostname : myWebServer01

  • IpAddress : 192.168.1.50

  • Public URL: www.xyz.com

  • Public IP : 10.20.1.50


Requirements:
  • DNS - Ensure that the DNS server resolves the URL to the NetCache appliance IP address (see below)

  • Accelerator IP Address - either the assigned IP address OR the aliased IP address of the NetCache appliance

  • Actual Server IP address


Procedure:
Note: In each page, ensure to click "Commit Changes" button in order to apply the changes.
  1. In Setup -> Network -> Interfaces, verify that the public IP address to use is configured as either the primary (Appliance Manager Primary IP address) or the alias(Appliance Manager Aliases) IP address.


  2. In Setup -> HTTP -> General, configure the following:
    • Check Enable HTTP services option.

    • Under the HTTP ACL, ensure that the server IP address is permitted:

      allow server-ip 192.168.1.50

    • HTTP Proxy PortsUsually, this is configured to port 80, the default HTTP port.

  3. In Setup -> HTTP -> Web Server Acceleration, General tab, configure the following:

    • Check Enables the Web accelerator function of the appliance option.

    • Under the Web Server Accelerator ACL, ensure that the server IP address is permitted:

      allow server-ip 192.168.1.50

  4. Configure a new accelerator rule in Setup -> HTTP -> Web Server Acceleration -> Acceleration Rules, New Rule button.

    For this scenario, you would have the following:
    AcceleratorWeb Server
    IPPortHostPathIPPortHostPath
    10.20.1.5080www.xyz.com*192.168.1.5080myWebServer01*


    Alternate Rule: You can use wildcards / asterisk, in case the webserver has multiple URLs.
    AcceleratorWeb Server
    IPPortHostPathIPPortHostPath
    10.20.1.5080**192.168.1.5080**





Thursday, July 17, 2008

SSH Connection Fails, Missing Key

One of the requirements to enable remote management via SSH on a device is the configured crypto RSA key. Hence, it is imperative that the RSA key be defined first before disabling other connections such as console and telnet.


Problem/Error Encountered:
So how do you know if your device doesn't have a crypto key enabled? Check the SSH attempt below:

-bash-3.00$ ssh 10.10.20.20 -1
ssh_exchange_identification: Connection closed by remote host
-bash-3.00$


To further confirm, check the SSH port via telnet:

-bash-3.00$ telnet 10.10.20.20 22
Trying 10.10.20.20...
Connected to 10.10.20.20.
Escape character is '^]'.
Could not load host key. Closing connection...Connection closed by foreign host.
-bash-3.00$


The output from the telnet 22 should be enough to confirm that the device has a missing (or possibly a corrupt) RSA key.

Solution:
Simply put, configure the RSA key.

However, here is a possible problem scenario: the device can only be accessed via SSH (console and telnet were disabled) AND the crypto key was (accidentally) erased. In this case, the only way to access the device is effectively disabled as well.

The "quickest" solution for this one is to recover the password recovery via console. Password recovery usually involves rebooting the device.

Verification:

Best way is, of course, to ssh to the device.

If testing via telnet 22, the should see something like this:

-bash-3.00$ telnet 10.10.20.20 22
Trying 10.10.20.20...
Connected to 10.10.20.20.
Escape character is '^]'.
SSH-2.0-Cisco-1.25