Showing posts with label ios. Show all posts
Showing posts with label ios. Show all posts

Monday, November 8, 2010

Cisco IOS Site-to-Site IPSec VPN using Certificates

After a couple of weeks trying to get a Site-to-Site IPSec tunnel to work using a Watchguard firewall, I decided to simply do it with a Cisco Router.

These are the steps involved in the configuration, hopefully this will help someone else or myself in the future.

In my particular case, the remote end uses certificates for the VPN and has a Certification Authority, so first we have to generate a certificate and ask them to sign it, the CSR can be generated on the IOS but for backup purposes I always tend to use openssl, that way if the router/firewall dies, we have backups:

openssl req -new -nodes -keyout example.key -out example.csr

Generating a 1024 bit RSA private key
.............++++++
............++++++
writing new private key to 'example.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Now that the CSR its done, the CA has to sign it.

After the CA does the signing, we need to import the certificates into the IOS device. There are many ways of doing this, but I prefer the PKCS#12 method since it's self-contained and simpler.

To use PKCS#12, we need to create the p12 file, I do this with openssl:

openssl pkcs12 -export -in example.cer -inkey example.key -certfile ca.cer -name "name" -out example.p12
Enter Export Password:
Verifying - Enter Export Password:

Now that we have the certificate signed and in PKCS#12 format, we have to import it to the IOS device, for that we have to create a pki trustpoint:

R1(config)#crypto pki trustpoint EXAMPLE-VPN
R1(ca-trustpoint)#revocation-check none

With the trustpoint created, we can import the certificate. There are several methods, I use TFTP:

R1(config)#crypto ca import EXAMPLE-VPN pkcs12 tftp: PASSWORD
% Importing pkcs12…
Address or name of remote host []? 1.1.1.1
Source filename [trustpoint]? example.p12
Reading file from tftp://1.1.1.1/example.p12
Loading example.p12 from 1.1.1.1 (via FastEthernet0/0): !
[OK - 1245 bytes]

CRYPTO_PKI: Imported PKCS12 file successful

We can verify that everything was imported correctly with the commands:

show crypto pki trustpoints
show crypto pki certificates

Now that the certificates are out of the way, we can focus on the VPN configuration itself.

The tunnel parameters for this example are:

IKE Phase 1
  • Encryption 3DES
  • Hash SHA
  • DH-Group 2

IKE Phase 2
  • ESP-3DES-MD5
  • Local Network: 192.168.2.1/32
  • Remote Network: 192.168.1.0/24

IKE Phase 1:

crypto isakmp policy 1
encr 3des
authentication rsa-sig
hash sha
group 2

This can be verified using show crypto isakmp policy

Transform-Set(s):

crypto ipsec transform-set TRANSFORM-SET-NAME esp-3des esp-md5-hmac

This can be verified using show crypto ipsec transform-set

Interesting traffic and NATing the source:

Lets assume that my network is 192.168.0.0/24, the remote network 192.168.1.0/24 and that the remote side has told me that all of my traffic has to come from 192.168.2.1

ip access-list extended NAT-IP-VPN
permit ip host 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

ip nat pool VPN-NAT 192.168.2.1 192.168.2.1 prefix-length 30

ip nat inside source list NAT-IP-VPN pool VPN-NAT overload

ip access-list extended TRAFFIC-VPN
permit ip host 192.168.2.1 192.168.1.0 0.0.0.255

Be careful with the NAT because if you have more than one statement the order matters. This can be verified using show ip nat translations, show access-lists

Crypto Map:

This is where we put it all together for the IKE Phase 2

crypto map VPN-Map-1 10 ipsec-isakmp
set peer 1.1.1.1
set security-association lifetime seconds 86400
set transform-set TRANSFORM-SET-NAME
match address TRAFFIC-VPN

Apply the crypto map/nat on the interfaces:

interface FastEthernet0/0
description LAN
ip nat inside

interface ATM0.1 point-to-point
description WAN
ip nat outside
crypto map VPN-Map-1

Verification:

Now all we have to do is generate interesting traffic and test what happens, some useful commands are show crypto isakmp sa and show crypto ipsec sa.

Useful Links:

Thursday, September 30, 2010

Cisco Catalyst 2950 HTTP: out of lines

This week I have being working on a lab setup to test some new features on an ACS deployment for a customer. For the lab, I took a couple of Catalyst 2950s/3550s and did some AAA configuration on them, so that pretty much everything AAA related went to the ACS servers.

After everything was done, I was doing verification on different things and everything was working as it should and then it was HTTP turn on the 2950s, the configuration was there but nothing was happening, all I got was a blank page every time I tried to enter the Web GUI.

Doing a debug ip http transactions showed:

000605: Sep 30 09:58:32.736 CEST: HTTP: out of lines
000606: Sep 30 09:58:32.748 CEST: HTTP: out of lines
000607: Sep 30 09:58:32.768 CEST: HTTP: out of lines
000608: Sep 30 09:58:32.780 CEST: HTTP: out of lines

My first thought was check to see if indeed the switch was out of lines, but that wasn't the case:

SW1#sh users all
    Line       User       Host(s)              Idle       Location
   0 con 0                                     00:00:00
*  1 vty 0     lab        idle                 00:00:00 1.1.1.1
   2 vty 1                                     00:00:00
   3 vty 2                                     00:00:00
   4 vty 3                                     00:00:00
   5 vty 4                                     00:00:00
   6 vty 5                                     00:00:00
   7 vty 6                                     00:00:00
   8 vty 7                                     00:00:00
   9 vty 8                                     00:00:00
  10 vty 9                                     00:00:00
  11 vty 10                                    00:00:00
  12 vty 11                                    00:00:00
  13 vty 12                                    00:00:00
  14 vty 13                                    00:00:00
  15 vty 14                                    00:00:00
  16 vty 15                                    00:00:00

Some searching later I found that apparently on the 2950s (Version 12.1(22)EA13) if you have transport input ssh on the vty lines, HTTP doesn't work, the issue was solved changing the vty  lines configuration to transport input ssh telnet.

I wasn't able to reproduce the same behavior on the 3550s (Version 12.2(53)SE).

Monday, September 20, 2010

TCAMINTERRUPT

The name of the blog comes from an odd error I got on a customer 4510R-E switch running 12.2(50)SG1, the log showed:

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2464 dPErr: 1 mPErr: 0 valid: 1

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2464 dPErr: 1 mPErr: 0 valid: 1

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2464 dPErr: 1 mPErr: 0 valid: 1

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2976 dPErr: 1 mPErr: 0 valid: 1

The device was not affected, even though according to the docs, this is supposed to mean "A parity error in a TCAM entry was detected. Contents of the log register are printed out Software will automatically perform error recovery on the defective TCAM entry"

It the end it was the result of the following IOS bug:

CSCsv17545 %C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt
Externally found severe (Sev2) bug: R-Resolved

Symptoms
Under normal operation we see the following messages appearing frequently in the logs:

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2947 dPErr: 1 mPErr: 0 valid: 1

%C4K_SWITCHINGENGINEMAN-4-TCAMINTERRUPT: flCam0 aPErr interrupt. errAddr: 0x2B59 dPErr: 1 mPErr: 0 valid: 1

Conditions
The issue appears to happen under normal operation, so far this has been observed after around two weeks of uptime, but needs to be confirmed.

Workaround
None At Present.

Solution
Upgrade software to IOS version 12.2(52)SG or later OR 12.2(50)SG4 or later.