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


Friday, July 11, 2008

BIG-IP RADIUS Login Authentication Checklist

Our network BIG-IP suddenly had login problems after a firmware upgrade. I'd confirm at a later date (i.e., after upgrade of another F5 BIG-IP) if an upgrade indeed causes a authentication problems. The good thing is that the local root password was not affected. Anyway, here are some points to consider when troubleshooting remote RADIUS login authentication on BIG-IP via CLI (and some UNIX/Linux servers).

REQUIRED INFORMATION:
- RADIUS server IP address(es)
- RADIUS server port (default is TCP 1812)
- RADIUS server secret key


BIG-IPv4 Checklist:
  • RADIUS server IP address and TCP port is configured in /etc/login.conf.

      radius-defaults:auth=radius,bploc,passwd:\
         :radius-server=10.10.10.10:\
         :radius-port=1812:\
         :radius-server-alt=10.10.20.10:\
         :radius-port-alt=1812:


  • RADIUS server IP address and secret key is configured in /etc/raddb/servers.

      MyBIGIP:~# cat /etc/raddb/servers
      10.10.10.10 myKey123
      10.10.20.10 myKey123
      MyBIGIP:~#


BIG-IPv9 Checklist:
  • RADIUS server IP address, port, and secret key are in /etc/raddb/server.

      MyBIGIPv9:~# cat /etc/raddb/server
      10.10.10.10:1812 myKey123 3
      10.10.20.10:1812 myKey123 3
      MyBIGIPv9:~#


  • RADIUS server IP address and secret key are defined in the /config/bigip.conf under the radius server sections.

    radius server system_auth_name1 {
       server "10.10.10.10"
       secret "myKey123"
    }
    radius server system_auth_name2 {
       server "10.10.20.10"
       secret "myKey123"
    }
    auth radius system-auth {
       server system_auth_name1 system_auth_name2
    }


    You can opt to modify this file via the GUI, in System > Users > Authentication.


Thursday, July 10, 2008

SNMP ifIndex persistence






Your network monitoring application, such as MRTG, is configured to monitor a specific interface. Since there are more than one interface on a device, monitoring will be based on the specific interface's assigned ifIndex.

However, after a hard device reboot, the ifIndex has changed, causing problems with MRTG reporting. This may occur intermittently; sometimes, ifIndex are the same after a reboot, sometimes they change (especially after adding logical interfaces and/or FastEthernet or GigabitEthernet modules).

This has been addressed in RFC2863 (updatint the ifIndex definition under RFC1213). As such, Cisco introduced SNMP ifIndex persistence; simply put, the current ifIndex assigned to the interface will be the permanent.

Configuration:

SNMP ifIndex persistence can be applied globally to all interfaces, or only to specific ones. The syntax are as follows:

 MyDevice(config)# snmp-server ifindex persist
 MyDevice(config-if)# snmp ifindex persist


Note: The actual syntax may vary depending on the IOS version; older versions use snmp-server ifindex persist instead of just snmp ifindex persist.

After that, you need to save the configuration via write mem or copy run start.

Verification

To retain the ifIndex values, like the configuration and vlan information in some older devices, it will be saved in the nvram. Check the NVRAM for a file called ifIndex-table.

MyDevice#dir nvram:ifIndex-table
Directory of nvram:/ifIndex-table

   3 -rw- 6712 <no date> ifIndex-table

1964024 bytes total (1752173 bytes free)
MyDevice#


Once that is configured, the changing ifIndex problem should be resolved and reporting tools such as MRTG will have no problems monitoring the correct interface.

References:
Interface Index (ifIndex) Persistence

Monday, July 7, 2008

TCP/UDP Ports for XBOX360

As you know, XBOX360 is one of the latest console gaming platforms available with network capability. Suppose you are network security consultant and you want restrict the ports used in the subnet used by your XBOX360 devices, which ports are you going to open?

Here are the required ports for the XBOX360 to properly connect to the network/Internet:

Outgoing ports:Description
UDP 53DNS queries
UDP 88Kerberos
UDP/TCP 3074XBox live
UDP 6500Peer queries
UDP 13139Peer ping
UDP 22042Server queries
TCP/UDP 22043-22050Voice chat


Incoming ports:Description
UDP/TCP 3074Xbox live


Given the above information, you can then create the access-lists as necessary.


EXAMPLE with Cat6000 as the gateway:
Below is a snippet of an actual access-list configured on a real-live Cat6000 device serving as the gateway for subnet 10.10.180.0/25:

ip access-list extended SUBNET_XBOX_IN
 remark <<Permit outbound XBOX360 ports>>
 permit udp 10.10.180.0 0.0.0.127 any eq 88
 permit tcp 10.10.180.0 0.0.0.127 any eq 3074
 permit udp 10.10.180.0 0.0.0.127 any eq 3074
 permit udp 10.10.180.0 0.0.0.127 any eq 6500
 permit udp 10.10.180.0 0.0.0.127 any eq 13139
 permit udp 10.10.180.0 0.0.0.127 any range 22042 22050
 permit tcp 10.10.180.0 0.0.0.127 any range 22043 22050
 deny ip any any

...

ip access-list extended SUBNET_XBOX_OUT
 remark <<Permit inbound XBOX360 ports>>
 permit tcp 10.10.180.0 0.0.0.127 any eq 3074
 permit udp 10.10.180.0 0.0.0.127 any eq 3074
 deny ip any any

...

interface Vlan180
 description "XBOX360 Subnet"
 ip address 10.10.180.254 255.255.255.128
 ip access-group SUBNET_XBOX_IN in
 ip access-group SUBNET_XBOX_OUT out
...


Note that in the above examples, outbound XBOX ports are in the inbound switch access-list; likewise, inbound XBOX ports are in the outbound switch access-list. This is with respect to the point of view of the Cat6000 where the ACLs are defined. The XBox "outbound" ports go out from the Xbox into the switch, hence we use the inbound access-list. Similarly, Xbox inbound ports come from the switch out to the XBox subnet.

Of course, the access-lists would be slightly different if the subnet's default gateway is, say, a PIX/ASA, or a checkpoint firewall, or a CatOS switch. Regardless, the same requirements apply; the above listed ports should be permitted.

Wednesday, June 25, 2008

SSL Certificate Export in NetCache

KEY CONCEPT:
SSL Certificates do not work on its own. It requires the corresponding Key (i.e., the Key used to create the CSR in the first place) to be validated.

The NetCache appliance does not have an SSL Key and Certificate export capability. This is a very important consideration with possible financial impact: any User Certificate (paid for by you to any public Certificate Authority or CA) created from a Certificate Signing Request (CSR) from this NetCache appliance can be used for this device only.

Since this device cannot export out the Key, the new User Certificate cannot be used in any other devices in the network. If there are multiple devices in the network requiring a particular certificate, you could possibly be paying more; one for the SSL cert fo this NetCache appliance and at least one more SSL cert for the other devices.

WORKAROUND:
There is actually no other workaround or fix for this except to NOT use the NetCache appliance to generate the Certificate Signing Request (CSR). Use other network devices, if any, such as F5 BIG-IP, Cisco ASA, and others. Note that although the NetCache appliance cannot export out, it can import in SSL Keys and Certificates.

PERMANENT FIX:
Check with the NetCache website for the latest releases to verify if and when this product limitation is addressed.

Monday, June 23, 2008

Case Study: D51 BIGIPv9 cannot be accessed via Web User Interface

Device:
Hardware: BIG-IP 5100 (D51)
Software: BIG-IP 9.2.3 Build 34.3

Problem / Symptoms:
- Device access via the GUI results in a page containing only "Configuration Utility is restarting";
- Device access via SSH and console works as expected.

Error Messages Encountered:
- GUI: Only message is "Configuration Utility is restarting" and that's it;
- SSH/Console: repeatedly gets the message "tomcat4 can't start because /var is at 100%"

Root Cause:
Most UNIX (Linux)-based network devices use Tomcat as the webserver, which then enables any web-based service (in this case, the Management GUI) on the device.

In this case, an existing bug in the current OS version causes the system to create jar_cache files which accumulates in the /var/cache/tomcat4/temp directory, which may eventually lead to the Java Virtual Machine (JVM) halting unexpectedly.

As in this case, the 100% of the /var partition has been used up.

Workaround:
1. Login (via SSH or console) into the device. As soon as you login, you should see the tomcat4 failing to startup messages such as the following:

Jun 19 11:04:40 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.
Jun 19 11:04:50 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.
Jun 19 11:05:00 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.


2. Verify the available drive space using df:

[root@MyBigIP:Standby] config # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 373652 294142 60217 84% /
/dev/hda7 57481 7688 46825 15% /config
/dev/hda8 47900 47456 0 100% /var
none 190508 5828 184680 4% /shared/rrd.1.0
none 190508 40 190468 1% /dev/shm
none 190508 1356 189152 1% /var/tmpfs
[root@MyBigIP:Standby] config #


You can check the actual space used up by the /var/cache/tomcat4/temp directory using the du command:

[root@MyBigIP:Standby] config # cd /var/cache/tomcat4
[root@MyBigIP:Standby] tomcat4 # du -h
204K ./temp
1.0K ./work/Standalone/localhost/tmui
2.0K ./work/Standalone/localhost
3.0K ./work/Standalone
4.0K ./work
209K .


3. Stop the tomcat4 daemon: bigstart stop tomcat4

4. Delete out the files in /var/cache/tomcat4/temp directory. Alternatively, using any SFTP application such as WinSCP, copy out the jar_cache files, in case your vendor wants to take a look at them.

5. Restart the tomcat4 daemon: bigstart start tomcat4

6. Verify the disk space available using df:

[root@MyBigIP:Standby] cache # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 373652 295704 58655 84% /
/dev/hda7 57481 7711 46802 15% /config
/dev/hda8 47900 24600 20827 55% /var
none 190508 5828 184680 4% /shared/rrd.1.0
none 190508 40 190468 1% /dev/shm
none 190508 1356 189152 1% /var/tmpfs
[root@MyBigIP:Standby] cache #



Permanent Fix:
BIG-IP version upgrade.

References:
SOL7361: The BIG-IP system can create an excessive number of jar_cache files, filling up the /var directory (requires F5 login)

Wednesday, June 11, 2008

Trunking vs Etherchannel






Noticed several colleagues of mine are still confused with "trunking" and "etherchannel". These two -- some would argue grammatically similar -- have very different functions and implications.

Trunking refers to (multiple) VLANs that are going through an interface. That is, for example, if you say that "a Cat6500 with GigabitEthernet1/1 trunks VLANs 1, 50, and 100", it means that these VLANs (and only these VLANs) are permitted to go through Gi1/1. The implication is that this forms a basic security feature, by permitting only specific VLANs; other traffic belonging to other VLANs will be permitted on this trunk interface.

Etherchannel -- aka channel-group, port-channel, or port group -- on the otherhand, refers to multiple (physical) interfaces bundled together into a single (logical) interface. That is, for example, if you say that "Cat6500 Port-channel100 includes GigabitEthernet2/1-4", these means that Gi2/1 to Gi2/4 are configured together as a single logical interface. The implication is that the bandwidth of these interfaces are combined and shared -- hence, in this example, Port-channel has a total bandwidth of 4Gbps (1Gbps per interface x 4 interfaces ).

So to state the basic difference between the two:

Trunking "bundles" VLANs together that are permitted on any single interface.
Etherchannel "bundles" (physical) interfaces together into a single logical interface.


Question: Can you combine an interface to have both trunking and etherchannel?

Answer: This is question is a little vague. In a way, yes. Here's a typical scenario actually being used in many companies:

Topology:
DeviceA. GigabitEthernet1/1 <=====> DeviceB.GigabitEthernet1/1
DeviceA. GigabitEthernet1/2 <=====> DeviceB.GigabitEthernet1/2

Requirement:
Permit only VLANs 100 and 200 through the link between DeviceA and DeviceB. Also, increase the link bandwidth between these two devices to 2Gbps. To summarize:

DeviceA.GigabitEthernet1/1 - trunking for vlans 100 and 200, share bandwidth with Gi1/2;
DeviceA.GigabitEthernet1/2 - trunking for vlans 100 and 200, share bandwidth with Gi1/1;

DeviceB.GigabitEthernet1/1 - trunking for vlans 100 and 200, share bandwidth with Gi1/2; DeviceB.GigabitEthernet1/2 - trunking for vlans 100 and 200, share bandwidth with Gi1/1;

To achieve this, we arbitrarily assign a channel group number IDs. For this example, we select 300 for DeviceA, so we have Port-Channel300 which will group Gi1/1 and Gi1/2. The basic configuration for DeviceA, then, would look like the following:

interface GigabitEthernet1/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200

channel-group 300 mode desirable
!
interface GigabitEthernet1/2
switchport switchport trunk encapsulation dot1q

switchport trunk allowed vlan 100,200
channel-group 300 mode desirable

!
interface Port-Channel300
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
!


The device on the remote end, DeviceB, should be configured similarly as well.

Similarly, we select Port-Channel500 for DeviceB.

interface GigabitEthernet1/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 500 mode desirable
!
interface GigabitEthernet1/2
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 500 mode desirable
!
interface Port-Channel500
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
!

With that, you're done!

Here are some points you should take note of:

Important Note #1: The channel-group ID only has local significance. In this example, DeviceA assigns Port-channel300 while DeviceB uses Port-channel500.

Important Note #2: The VLANs trunked on the port-channel interface and the member interfaces should match. If there is a mismatch, the status of the interfaces will be down.

Important Note #3: The actual syntax would vary, depending on the IOS image currently being used. Here's a general hint: IOS 12.0 uses the "port group" interface command, while IOS 12.1 onwards uses the "channel-group" interface command.

Tuesday, May 13, 2008

VPN: Clearing IPSEC Tunnels

As per the IPSEC Checklist and Best Practices, whenever changes are going to be done to live IPSEC tunnels, it is a good practice to turn off the tunnels.

Cisco IOS Router:
clear crypto isakmp []
clear crypto sa entry

Cisco PIX 6.X / 7.X:
clear crypto isakmp sa
clear crypto ipsec sa

VPN Concentrator 3000:
Administration --> Administer Sessions --> Logout link of tunnel

PIX / ASA: %PIX|ASA-6-302014: Teardown TCP connection

%PIXASA-6-302014: Teardown TCP connection id for interface:real-address/real-port to interface:real-address/real-port duration hh:mm:ss bytes bytes [reason] [(user)]

Explanation: A TCP connection between two hosts was deleted. The following list describes the message values:
  • connection id is an unique identifier.
  • interface, real-address, real-port identify the actual sockets.
  • duration is the lifetime of the connection.
  • bytes bytes is the data transfer of the connection.
  • user is the AAA name of the user.
The reason variable presents the action that causes the connection to terminate.

Conn-timeout
Connection ended because it was idle longer than the configured idle timeout.

Deny Termiate
Flow was terminated by application inspection.

Failover primary closed
The standby unit in a failover pair deleted a connection because of a message received from the active unit.

FIN Timeout
Force termination after 10 minutes awaiting the last ACK or after half-closed timeout.

Flow closed by inspection
Flow was terminated by inspection feature.

Flow terminated by IPS
Flow was terminated by IPS.

Flow reset by IPS
Flow was reset by IPS.

Flow terminated by TCP Intercept
Flow was terminated by TCP Intercept.

Invalid SYN
SYN packet not valid.

Idle Timeout
Connection timed out because it was idle longer than timeout value.

IPS fail-close
Flow was terminated due to IPS card down.

SYN Control
Back channel initiation from wrong side.

SYN Timeout
Force termination after 30 seconds awaiting three-way handshake completion.

TCP bad retransmission
Connection terminated because of bad TCP retransmission.

TCP FINs
Normal close down sequence.

TCP Invalid SYN
Invalid TCP SYN packet.

TCP Reset-I
Reset was from the inside.

TCP Reset-O
Reset was from the outside.

TCP segment partial overlap
Detected a partially overlapping segment.

TCP unexpected window size variation
Connection terminated due to variation in the TCP window size.

Tunnel has been torn down
Flow terminated because tunnel is down.

Unauth Deny
Denied by URL filter.

Unknown
Catch-all error.

Xlate Clear
Command-line removal

Other Notes:
The "inside" in TCP RESET-I refers to the more secure interface (i.e., interface with higher security level). Consequently, "outside" in TCP RESET-O refers to the less secure interface (i.e., interface with lower security level).

This is useful indetermining the source of the TCP session disconnection. That is, on which interface the disconnection was received from. Usually, it is actually the host on the interface itself that tears down the connection (could be due to failed authentication). Whatever the case, you have narrowed down the cause of the error.

The other reasons are pretty straightforward.

Reference:
PIX 7.2: SYSLOG 302014

Thursday, March 27, 2008

IOS: %CRYPTO-4-PKT_REPLAY_ERR replay check failed







%CRYPTO-4-PKT_REPLAY_ERR : [chars] connection id=[dec]




IOS 12.4 --> Syslogs --> CRYPTO Messages
http://www.cisco.com/en/US/products/ps6350/products_system_message_guide_chapter09186a0080462676.html#wp164939
Error Message:
%CRYPTO-4-PKT_REPLAY_ERR : [chars] connection id=[dec]

Explanation: The replay processing has failed. The failed replay processing may be a temporarycondition caused by the wait for new SAs to be established. In the inbound case, this error might also be caused by an actual replay attack. This activity can be considered a hostile event.

Recommended Action: If the problem appears to be more than a transient one, contact the peer administrator.




CSCeg43855 - Router generated traffic causes anti-replay errors
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeg43855&Submit=Search

Symptoms: An encrypting router may send traffic that is locally originated (such as keepalive packets or routing update packets) out of order after the packets have been encrypted. Because of the anti-replay check failure, these packets are dropped on the receiving router.

Conditions: This symptom is observed when a multipoint GRE (mGRE) and IPSec tunnel is built between two routers.

Workaround: Turn off packet authentication for the configured IPSec transform.

Further Problem Description: On a Cisco 7200 series that functions as the receiving router, you can observe the symptom in the output of the show crypto ipsec sa detail or show pas isa interface command.




IOS 12.4 --> IPSec Anti-Replay Window: Expanding and Disabling
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455ad4.html
Troubleshooting Tips:
If your replay window size has not been set to a number that is high enough for the number of packets received, you will receive a system message such as the following:

*Nov 17 19:27:32.279: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=1

The above message is generated when a received packet is judged to be outside the anti-replay window.




Additional Notes:

If there's no interruption of service, it could just be a normal and temporary condition, especially if the SAs (IPSEC tunnels) are still being established.

Otherwise, I suggest setting the anti-replay window to, say, 1024.

crypto ipsec security-association replay window-size 1024

Take note that the above command is introduced in 12.3(14)T; older versions do not support this command.

IOS: %HW_VPN-1-HPRXERR Packet Encryption/Decryption Errors

%HW_VPN-1-HPRXERR : [chars]: Packet Encryption/Decryption error, status=[int]



CSCdt40220 - AIM encryption produces Packet Encryption/Decryption error
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdt40220&Submit=Search

Symptoms:
A router displays one of the following error messages:

HW_VPN-1-HPRXERR: Hardware VPN0/2: Packet Encryption/Decryption error, status=4612

This is a notification message seen on the console of the DECRYPTING PEER that tells the user that IPSEC packets have been received out of order. Re-ordering can occur in one of 3 places:
1. encrypting peer
2. network
3. decrypting peer

Only in rare cases can this occur in the decrypting peer.

The only known way for this to occur in the decrypting peer is for a packet to be bumped to process switch while the following packets from the same tunnel are fast or cef switched. This could happen if the packet is fragmented and needs re-assembly.

The following lists some of the common scenarios that might introduce out-of-order IPSEC packets. These scenrios are considered normal behaviors:

1. Fragmentation - the decrypting peer uses process switching to fragmented packets. To minimize the impact of this, Look-Ahead-Fragmentation should be enabled. This feature was added to IOS via CSCdw77514.

2. QoS: QoS scheduling mechanism happening after IPSec encryption could cause packets in the same IPsec SAs to be transmitted out-of-order.

3. Pak_priority: pak_priority is an internal flag set by the IOS to some of the router generated packets that are considered critical, e.g., routing updates, interface keepalives. When output interface queue is congested, router will honor the pak_priority flags to make sure the high priority packets are transmitted first. So in the GRE over IPsec and dynamic routing protocol design, the ESP packets could become out-of-order if the egress interface is congested and the router has to transmit the encrypted routing update first.

Conditions:
Either of the messages may be displayed depending on whether Authentication Header (AH) or Encapsulation Protocol (ESP) encapsulation is used. In addition, the ah_seq_fail or esp_seq_fail error counts increment in the output of the show crypto engine accelerator statistic privileged EXEC command.

Workaround:
- Set the maximum transmission unit (MTU) size of inbound streams to less than 1400 bytes.
- enable Look-Ahead-Fragmentation



WORKAROUND:

1. Adjust the interface MTU (preferably below 1400):

interface type mod/port
ip mtu byte


2. Adjust Fragmentation (See Pre-Fragmentation for IPSEC VPNs):

crypto ipsec df-bit clear
crypto ipsec fragmentation before-encryption

-- OR --

crypto ipsec df-bit clear
interface type mod/port
crypto ipsec fragmentation before-encryption




REFERENCES:

Pre-fragmentation for IPSec VPNs
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080115533.html

PIX/ASA 7.X: Policy NAT

TOPOLOGY:
10.10.10.10 ---- YourASA ======= RemoteDevice ---- 20.20.20.20

SCENARIO:
- Host 10.10.10.10 is translated to 172.16.0.10 when going to host 20.20.20.20 (VPN traffic)
- Host 10.10.10.10 is translated through NAT/PAT normally elsewhere.

CONFIGURATION:

access-list NONAT permit ip host 172.16.0.10 host 20.20.20.20
access-list VPN10 permit ip host 172.16.0.10 host 20.20.20.20
access-list POLICY_NAT extended permit ip host 10.10.10.10 host 20.20.20.20

static (inside, outside) 172.16.0.10 acl POLICY_NAT
nat (inside) 0 access-list NONAT

nat (inside) 1 0 0
global (outside) 1 in interface
...

! DEFINE PHASE1 / ISAKMP PARAMETERS !
! DEFINE PHASE2 / IPSEC PARAMETERS !
...
crypto map OUTSIDE_MAP 10 match address VPN10
...
crypto map OUTSIDE_MAP interface outside

isakmp enable outside





NOTES:
In the above example, note that the source IP address of the VPN traffic is the translated IP address (172.16.0.10), not the inside/original source address.

The static statement is evaluated first before the crypto match statement. Hence, if the traffic matches acl "POLICY_NAT", the traffic is translated first, before it will be evaluated against the crypto map policy. (See NAT Order of Operation)

Due to the software requirements, this is available only to ASA and PIX capable of supporting 7.x and later.





REFERENCES:
PIX/ASA 7.X: Policy NAT:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9950.shtml
NAT Order of Operation:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

Tuesday, March 25, 2008

PIX: Dynamic Site-to-Site IPSEC Configuration

SCENARIO:

Configure a tunnel between 10.2.2.0/24 to 10.1.1.0/24, between one static and one dynamic VPN peers.

This is a typical scenario when one device has a dynamic "outside" IP address (such as DHCP).

Notes:
The configuration can be expanded to include remote access VPN on either peer;
The configuration can be expanded to include more than one dynamic peer;
In case of multiple VPN devices, there should always be at least one static peer.




TOPOLOGY:

10.2.2.0 --- STATIC ==== (( INTERNET )) ===== DYNAMIC ---- 10.1.1.0

STATIC.inside = 10.2.2.1/24
STATIC.outside = 203.1.1.1/24
DYNAMIC.outside = DHCP
DYNAMIC.inside = 10.1.1.1/24




CONFIGURATIONS:
- several possible simple configurations, depending on the PIX OS running on either device.

PHASE 1 / ISAKMP PARAMETERS:
- authentication = pre-shared key (MY_ISAKMP_KEY)
- encryption = 3DES
- hash = MD5
- group = 2

PHASE 2 / IPSEC PARAMETERS:
- ESP-3DES, ESP-MD5



STATIC PIX 6.X:

access-list NONAT permit ip 10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity address
isakmp nat-traversal

isakmp key MY_ISAKMP_KEY address 0.0.0.0 netmask 0.0.0.0 no-xauth

isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map DYN_MAP 1 set transform-set ESP-DES-MD5
crypto map MY_STATIC_MAP 20 ipsec-isakmp dynamic DYN_MAP

crypto map MY_STATIC_MAP interface outside
isakmp enable outside



STATIC PIX 7.0/7.1:

access-list NONAT extended permit ip 10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity address
isakmp nat-traversal

isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map DYN_MAP 1 set transform-set ESP-3DES-MD5
crypto map MY_STATIC_MAP 20 ipsec-isakmp dynamic DYN_MAP

tunnel-group MY_GROUP type ipsec-l2l
tunnel-group MY_GROUP general-attributes
tunnel-group MY_GROUP ipsec-attributes
pre-shared-key MY_ISAKMP_KEY

crypto map MY_STATIC_MAP interface outside
isakmp enable outside




STATIC PIX 7.2:

access-list NONAT extended permit ip 10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-vpn

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map DYN_MAP 1 set transform-set ESP-3DES-MD5
crypto map MY_STATIC_MAP 20 ipsec-isakmp dynamic DYN_MAP

crypto isakmp nat-traversal
crypto isakmp identity address

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400

tunnel-group MY_GROUP type ipsec-l2l
tunnel-group MY_GROUP general-attributes
tunnel-group MY_GROUP ipsec-attributes
pre-shared-key MY_ISAKMP_KEY

crypto map MY_STATIC_MAP interface outside
crypto isakmp enable outside



DYNAMIC PIX 6.X:

access-list NONAT permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0
access-list VPN permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity hostname
isakmp nat-traversal

isakmp key MY_ISAKMP_KEY address 203.1.1.1 netmask 255.255.255.255

isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 1000

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto map DYNAMIC_MAP 10 ipsec-isakmp
crypto map DYNAMIC_MAP 10 match address VPN
crypto map DYNAMIC_MAP 10 set peer 203.1.1.1
crypto map DYNAMIC_MAP 10 set transform-set ESP-3DES-MD5

crypto map DYNAMIC_MAP interface outside
isakmp enable outside




DYNAMIC PIX 7.0/7.1:

access-list NONAT permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0
access-list VPN permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity hostname
isakmp nat-traversal

isakmp key MY_ISAKMP_KEY address 203.1.1.1 netmask 255.255.255.255

isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 1000

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map DYN_MAP 1 set transform-set ESP-3DES-MD5
crypto map DYNAMIC_MAP 10 ipsec-isakmp dynamic DYN_MAP
crypto map DYNAMIC_MAP 10 match address VPN
crypto map DYNAMIC_MAP 10 set peer 203.1.1.1


tunnel-group MY_GROUP type ipsec-l2l
tunnel-group MY_GROUP general-attributes
tunnel-group MY_GROUP ipsec-attributes
pre-shared-key MY_ISAKMP_KEY

crypto map DYNAMIC_MAP interface outside
isakmp enable outside


DYNAMIC PIX 7.2:

access-list NONAT permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0
access-list VPN permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

crypto isakmp identity hostname
crypto isakmp nat-traversal

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map DYN_MAP 1 set transform-set ESP-3DES-MD5
crypto map DYNAMIC_MAP 10 ipsec-isakmp dynamic DYN_MAP
crypto map DYNAMIC_MAP 10 match address VPN
crypto map DYNAMIC_MAP 10 set peer 203.1.1.1

tunnel-group MY_GROUP type ipsec-l2l
tunnel-group MY_GROUP general-attributes
tunnel-group MY_GROUP ipsec-attributes
pre-shared-key MY_ISAKMP_KEY

crypto map DYNAMIC_MAP interface outside
isakmp enable outside


REFERENCE

PIX 6: http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_configuration_example09186a0080094680.shtml
PIX 7: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00805733df.shtml

Wednesday, March 12, 2008

IPSEC Checklist and Best Practices

Basic Checklist for VPN Configuration:
- IP address of the static VPN peers

- IP addresses/networks that will be tunneled
--> networks behind each VPN peer (site-to-site)
--> network behind VPN and pool (remote access)

- PHASE I / ISAKMP parameters
--> authentication (pre-shared key/certificate)
--> encryption (DES, 3DES, AES)
--> hash (SHA, MD5)
--> group (2, 5)

- PHASE II / IPSEC Parameters
--> transform set

- VPN Group (remote access only)
--> VPN Group Name
--> VPN Group Password

_____________________________________________________

Best Practices:

* MIRROR TRAFFIC: The traffic (IP addresses/networks) defined on the two VPN peers should be mirror images of each other. That is, the source and destination on one end becomes the destination and source on the other end, respectively. Example:

10.10.10.0 ---- PIX1 ======== PIX2 ---- 20.20.20.0

access-list PIX1_TUNNEL permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
access-list PIX2_TUNNEL permit ip 20.20.20.0 255.255.255.0 10.10.10.0 255.255.255.0

* SEPARATE ACLS for NAT and CRYPTO: (For Cisco PIX/ASA): To facilitate expansion, define the same traffic twice; one used for defining the tunnel traffic (in the crypto map match statement), and another for preventing the translation of this traffic (nat (inside) 0 or similar statement). Here's a scenario showing the advantage of having separate access-lists:

(Note: The ASCII drawing below best viewed using Courier New)

PIX2 --- 20.20.20.0
 +
 +
PIX1 --- 10.10.10.0
 +
 +

PIX3 --- 30.30.30.0

PIX1 Configuration
access-list NONAT permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
access-list NONAT permit ip 10.10.10.0 255.255.255.0 30.30.30.0 255.255.255.0
nat (inside) 0 access-list NONAT

access-list TUNNEL1-2 permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
access-list TUNNEL1-3 permit ip 10.10.10.0 255.255.255.0 30.30.30.0 255.255.255.0

crypto map MYMAP 10 match address TUNNEL1-2
crypto map MYMAP 20 match address TUNNEL1-3

What if you need to form another tunnel to a new network, 40.40.40.0, behind another device, PIX4?

* CHANGES to LIVE VPN TUNNELS: When crypto and/or isakmp statements are changed while a VPN tunnel exists, chances are, the device where the change was made will hang. To avoid this, (1) disable the tunnel on the interface and (2) tear down existing tunnels before doing any changes.

* PRE-SHARED KEY FIRST, BEFORE CERTIFICATES: When configuring IPSEC tunnels using digital certificates, it is best to configure first using pre-shared keys. This way, you can eliminate all the errors which does not involve certificates. Later, when errors occur after placing certificates, you only need to deal with the certificate-part of the configuration. (Unless, of course, if you messed up the basic configurations somehow while adding the certificates.)

* ORDER of CRYPTO MAP POLICIES: For devices with both static and dynamic crypto map configurations, ensure that the static ones are evaluated first (usually, by specifying a lower sequence number) before the dynamic ones. Otherwise, all static tunnel configurations are useless as they will NEVER be used.

* NO XAUTH for SITE-TO-SITE with REMOTE ACCESS: For devices with both Site-to-Site and Remote Access VPN, ensure that extended authentication (XAUTH) is disabled for the site-to-site configuration. This is a common issue: a working VPN device cannot form L2L tunnel after adding remote access configurations.

PIX 7.0: Simple Remote Access VPN

TOPOLOGY:

192.168.201.0 ---- PIX --- (( INTERNET )) ---- home_user

VPN Client Pool = 172.16.1.1 to 172.16.1.254



PIX 7.0/7.1 CONFIGURATION:

access-list SPLIT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list NONAT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity address
isakmp nat-traversal

isakmp policy 200 authentication pre-share
isakmp policy 200 encryption des
isakmp policy 200 hash sha
isakmp policy 200 group 2
isakmp policy 200 lifetime 86400

crypto ipsec transform-set MYSET esp-des esp-md5-hmac
crypto dynamic-map CISCO 1 set transform-set MYSET
crypto map MYMAP 65535 ipsec-isakm dynamic CISCO

ip local pool CLIENTPOOL 172.16.1.1-172.16.1.254

tunnel-group REMOTEACCESS type ipsec-ra
tunnel-group REMOTEACCESS general-attributes
address-pool CLIENTPOOL
tunnel-group REMOTEACCESS ipsec-attributes
pre-shared-key CISCO123

group-policy REMOTEACCESS internal
group-policy REMOTEACCESS attributes
wins-server value 10.1.1.3
dns-server value 10.1.1.3
vpn-idle-timeout 30

crypto map MYMAP interface outside
isakmp enable outside




PIX 7.2 CONFIGURATION:

access-list SPLIT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list NONAT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-vpn

crypto isakmp identity address
crypto isakmp nat-traversal

crypto isakmp policy 200
authentication pre-share
encryption des
hash sha
group 2
lifetime 86400

crypto ipsec transform-set MYSET esp-des esp-md5-hmac
crypto dynamic-map CISCO 1 set transform-set MYSET
crypto map MYMAP 65535 ipsec-isakm dynamic CISCO

ip local pool CLIENTPOOL 172.16.1.1-172.16.1.254

tunnel-group REMOTEACCESS type ipsec-ra
tunnel-group REMOTEACCESS general-attributes
address-pool CLIENTPOOL
tunnel-group REMOTEACCESS ipsec-attributes
pre-shared-key CISCO123

group-policy REMOTEACCESS internal
group-policy REMOTEACCESS attributes
wins-server value 10.1.1.3
dns-server value 10.1.1.3

crypto map MYMAP interface outside
isakmp enable outside

Saturday, March 8, 2008

PIX 6.X: Simple Remote Access VPN

Scenario:
User from internet should access the inside/corporate network 192.168.201.0. This is the perhaps the simplest remote access VPN scenario there is.

Topology:

192.168.201.0 ---- PIX --- (( INTERNET )) ---- home_user

VPN Client Pool = 172.16.1.1 to 172.16.1.254


Configuration:

access-list SPLIT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list NONAT permit ip 192.168.201.0 255.255.255.0 172.16.1.0 255.255.255.0

nat (inside) 0 access-list NONAT

sysopt connection permit-ipsec

isakmp identity address
isakmp nat-traversal

isakmp policy 200 authentication pre-share
isakmp policy 200 encryption des
isakmp policy 200 hash sha
isakmp policy 200 group 2
isakmp policy 200 lifetime 86400

isakmp key CISCO123 address 0.0.0.0 netmask 0.0.0.0

crypto ipsec transform-set MYSET esp-des esp-md5-hmac
crypto dynamic-map CISCO 1 set transform-set MYSET
crypto map MYMAP 65535 ipsec-isakm dynamic CISCO

ip local pool CLIENTPOOL 172.16.1.1-172.16.1.254

vpngroup VPNCLIENT address-pool CLIENTPOOL
vpngroup VPNCLIENT dns-server 4.2.2.2
vpngroup VPNCLIENT wins-server 24.24.24.24
vpngroup VPNCLIENT default-domain CISCO.COM
vpngroup VPNCLIENT idle-time 1800
vpngroup VPNCLIENT password CISCO123
vpngroup VPNCLIENT split-tunnel SPLIT

crypto map MYMAP interface outside
isakmp enable outside


Reference:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080884c2f.shtml
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009442e.shtml

PIX/ASA 7.X: Simple PIX-to-PIX VPN Tunnel

Secnario:
Typical site-to-site / LAN-to-LAN VPN tunnel between the respective inside networks of two PIX 7.X devices.

Topology:

10.10.1.0 ---- ThisPIX ========= OtherPix ---- 10.10.2.0

ThisPix.inside = 10.10.1.1
ThisPix.outside = 192.168.10.2

OtherPix.inside = 10.10.2.0
OtherPix.outside = 192.168.10.1

VPN Tunnel between 10.10.1.0/24 and 10.10.2.0/24

Configuration:
[The following only includes the configuration for the "ThisPix" device. The configuration of the "OtherPix" should be the "mirror-image" of that of "ThisPix" (that is, source address becomes destination address, and vice versa, while others, such as the PHASE1 properties are the same).]

[Also, note that several syntax changes have been made from one version to another. It is best to consult the "Command Reference Guide" for the PIX/ASA version running and/or use the "?" command from the command prompt.

PIX 7.0:

access-list NONAT extended permit ip 10.10.1.0 255.255.255.0 10.10.2.0 255.255.255.0
access-list VPN20 extended permit ip 10.10.1.0 255.255.255.0 10.10.2.0 255.255.255.0

nat (inside) 0 access-list NONAT
sysopt connection permit-ipsec

crypto ipsec transform-set MY-ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto map OUTSIDE_MAP 20 match address VPN20

crypto map OUTSIDE_MAP 20 set peer 192.168.10.1
crypto map OUTSIDE_MAP 20 set transform-set MY-ESP-AES-256-SHA

isakmp nat-traversal
isakmp identity address
isakmp policy 10 authentication pre-share

isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 86400

tunnel-group 192.168.10.1 type ipsec-l2l
tunnel-group 192.168.10.1 ipsec-attributes pre-shared-key CISCO

crypto map OUTSIDE_MAP interface outside
isakmp enable outside

PIX 7.2:
access-list NONAT extended permit ip 10.10.1.0 255.255.255.0 10.10.2.0 255.255.255.0
access-list VPN20 extended permit ip 10.10.1.0 255.255.255.0 10.10.2.0 255.255.255.0

nat (inside) 0 access-list NONAT
sysopt connection permit-vpn

crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto map OUTSIDE_MAP 20 match address VPN20

crypto map OUTSIDE_MAP 20 set peer 192.168.10.1
crypto map OUTSIDE_MAP 20 set transform-set ESP-AES-256-SHA

isakmp nat-traversal
isakmp identity address

isakmp policy 10
 authentication pre-share
 encryption aes-256
 hash sha group 5 lifetime 86400

tunnel-group 192.168.10.1 type ipsec-l2l
tunnel-group 192.168.10.1 ipsec-attributes
 pre-shared-key CISCO

crypto map OUTSIDE_MAP interface outside
isakmp enable outside

Reference:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00805a87f7.shtml

PIX 6.X: Simple PIX-to-PIX VPN Tunnel

Secnario:
Typical site-to-site / LAN-to-LAN VPN tunnel between the respective inside networks of two PIX 6.X devices.

Topology:

192.168.201.0 --- PIX1 <=======> PIX2 --- 192.168.202.0

- PIX1.outside = 10.199.248.46
- PIX1.inside = 192.168.201.1
- PIX2.outside = 10.199.248.47
- PIX2. inside = 192.168.202.1

- VPN between 192.168.201.0/24 network and 192.168.202.0/24

PIX1 Configuration:
access-list VPN permit ip 192.168.201.0 255.255.255.0 192.168.202.0 255.255.255.0
access-list NONAT permit ip 192.168.201.0 255.255.255.0 192.168.202.0 255.255.255.0

nat (inside) 0 access-list NONAT
sysopt connection permit-ipsec
management inside

isakmp identity address
isakmp nat-traversal
isakmp key CISCO123 address 10.199.248.47 netmask 255.255.255.255 no-xauth
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400

crypto ipsec transform-set MYSET esp-des esp-md5-hmac
crypto map MYMAP 10 ipsec-isakmp
crypto map MYMAP 10 match address VPN
crypto map MYMAP 10 set peer 10.199.248.47
crypto map MYMAP 10 set transform-set MYSET
crypto map MYMAP interface outsideisakmp enable outside


PIX2 Configuration:
access-list VPN permit ip 192.168.202.0 255.255.255.0 192.168.201.0 255.255.255.0
access-list NONAT permit ip 192.168.202.0 255.255.255.0 192.168.201.0 255.255.255.0

nat (inside) 0 access-list NONAT
sysopt connection permit-ipsec
management inside

isakmp identity addressisakmp nat-traversal
isakmp key CISCO123 address 10.199.248.46 netmask 255.255.255.255

isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400

crypto ipsec transform-set MYSET esp-des esp-md5-hmac
crypto map MYMAP 10 ipsec-isakmp

crypto map MYMAP 10 match address VPN
crypto map MYMAP 10 set peer 10.199.248.46
crypto map MYMAP 10 set transform-set MYSET

crypto map MYMAP interface outside
isakmp enable outside

Reference:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml

Thursday, March 6, 2008

PIX/ASA: Permit Pass-through IPSEC traffic

This is a scenario in which the PIX with NAT is not the VPN/IPSEC peer; it just serves as a pass-through VPN device.

Topology:


PIX 6.X Configuration:
ip address outside 10.99.99.1 255.255.255.0
ip address inside 10.1.1.1 255.255.255.0

global (outside) 1 interface
nat (inside) 0 0.0.0.0 0.0.0.0
static (inside,outside) 10.99.99.12 10.1.1.2 netmask 255.255.255.255 0 0

access-list acl-out permit esp host 10.99.99.2 host 10.99.99.12
access-list acl-out permit udp host 10.99.99.2 host 10.99.99.12 eq isakmp
access-list acl-out permit udp host 10.99.99.2 host 10.99.99.12 eq 4500

access-group acl-out in interface outside
isakmp enable outside
isakmp enable inside
isakmp nat-traversal



PIX 7.X and up Configuration:
interface Ethernet0
nameif outside
security-level 0
ip address 10.99.99.1 255.255.255.0
!
interface Ethernet1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!

global (outside) 1 interface
nat (inside) 0 0.0.0.0 0.0.0.0
static (inside,outside) 10.99.99.12 10.1.1.2 netmask 255.255.255.255 0 0

access-list acl-out permit esp host 10.99.99.2 host 10.99.99.12
access-list acl-out permit udp host 10.99.99.2 host 10.99.99.12 eq isakmp
access-list acl-out permit udp host 10.99.99.2 host 10.99.99.12 eq 4500

access-group acl-out in interface outside

Notes:
Configuration is very straighforward. Permit the traffic through an access-list, like how you would when permitting any other traffic. For IPSEC, permit ESP, ISAKMP, and UDP4500.

References:
PIX6: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009486e.shtml
PIX 7:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008045a2d2.shtml

Tuesday, March 4, 2008

PIX 7.X: SSH/Telnet on the Inside and Outside Interface

To manage it remotely, you need to configure PIX 7.X to permit incoming SSH and/or Telnet connections to it. Note that since Telnet sends all information including passwords in clear text, SSH is preferred the method.



Configuration Tasks:
1. Specify credentials:
  passwd mypassword
  -- or --
  username myusername password mypassword
  aaa authentication ssh local

2. [SSH only] Generate RSA key pair:
  crypto key zeroize rsa
  crypto key generate rsa modulus 1024


Note: The "zeroize" command is there just in case a previous RSA key has already been generated previously. You can set the modulus to any other value aside from 1024. The larger the modulus, the more secure the RSA key.

3. Specify the hosts allowed to connect to the PIX:

  ssh 0 0 inside
  ssh 10.199.248.0 255.255.255.0 outside
  -- or --
  telnet 0 0 inside
  telnet 10.199.248.0 255.255.255.0 outside

Note: Syntax parameters for either case is: source_ip_address subnet_mask source_interface. The 0 0 above indicates "any".

4. [Optional] Specify the telnet/ssh session timeout:
  ssh timeout 10
  -- or --
  telnet timeout 10


Reference:
For further reading, I suggest the following URL:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008069bf1b.shtml

PIX 6.X: SSH/Telnet on the Inside and Outside Interface

To manage it remotely, you need to configure PIX 6.X to permit incoming SSH and/or Telnet connections to it. Note that since Telnet sends all information including passwords in clear text, SSH is preferred the method.

Network Diagram:


Configuration Tasks:

1. Specify credentials:
  passwd mypassword
  -- or --
  username myusername password mypassword


2. [SSH only] Generate RSA key pair:
  ca zeroize rsa
  ca gen rsa key 1024
  ca save all


Note: The "zeroize" command is there just in case a previous RSA key has already been generated. You can set the modulus to any other value aside from 1024. The larger the modulus, the more secure the RSA key.

3. Specify the hosts allowed to connect to the PIX:

  ssh 0 0 inside
  ssh 10.199.248.0 255.255.255.0 outside
  -- or --
  telnet 0 0 inside
  telnet 10.199.248.0 255.255.255.0 outside


Note: Syntax parameters for either case is: source_ip_address subnet_mask source_interface. The 0 0 above indicates "any".

4. [Optional] Specify the telnet/ssh session timeout:

  ssh timeout 10
  -- or --
  telnet timeout 10

Basic PIX Configuration

This should be your most basic configuration if you want your PIX to have internet access, assuming there are no other blocking/filtering device that exists between the PIX and the internet:

Topology:
PIX inside: 192.168.102.254 /24
PIX outside: 10.199.248.50 /24
ISP/default gateway: 10.199.248.254 /24



PIX 6.X Configuration:
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
ip address outside 10.199.248.50 255.255.255.0
ip address inside 192.168.102.254 255.255.255.0
global (outside) 1 interface
nat (inside) 1 0 0
route outside 0 0 10.199.248.3 1


PIX 7.X Configuration
interface Ethernet0
 no shutdown
 nameif outside
 ip address 10.199.248.50 255.255.255.0
interface Ethernet1
 no shutdown
 nameif inside
 ip address 192.168.102.254 255.255.255.0
global (outside) 1 interface
nat (inside) 1 0 0
route outside 0 0 10.199.248.3


Notes:
Slight difference when dealing with different PIX OS, but principle is the same. First, configure the interfaces. Next, configure translation (shown here is the simplest NAT). Lastly, configure default route.

Welcome to my new project!

I've decided to put up a blog that will serve as my "dump site" of things I have learned about computer networking throughout the years.

I have two objectives here:

1. Preserve what I know; can't keep track of everything, especially since industry is changing every few years or so; why maintain all the papers and training materials when I keep them online, right?

2. Knowledge Sharing; I learn, you learn, everyone learns, everyone happy. :)

My initial posts will be everything I learned in my current and previous jobs. If you have any comments, suggestions, requests, or whatever, please feel free to email me at: raabad@gmail.com.

That's all for now. I'll post whatever I can post ASAP.

Cheers! :)