nat0 » Cisco IOS

Stuck with an auth-proxy task

Jimmy Larsson — Tue, 03 Jan 2012 09:34:12 +0000

Hello

I am currently working on a task (INE CCIE Security WB 1 Task 2.9) where I am supposed to configured an radius-based IOS auth-proxy. The task is this:

Configure Authentication PRoxy settings on R3 per the following requirements.

US the radius server at 10.0.0.100 with the authentication key CISCO.
The authentication proxy should apply to the users sessions initiated from VLAN23 towards VLAN13.
Authentication users should be allowed to send ICMP packets and initate TCP sessions.
Configure the ACS server with the user named PROXY and the password of CISCO1234.

In ACS I have added the R3 as AAA client (Cisco IOS Radius). I have also added the user PROXY with the following cisco av pair´s:

auth-proxy:priv-lvl=15 auth-proxy:proxyacl#1=permit icmp any any auth-proxy:proxyacl#1=permit tcp any any

In R3 I have added the following config:

aaa new-model aaa authen login CON none line con 0 login authen CON aaa authen login default group radius aaa author auth-proxy default group radius ! ip http server ip http authen aaa ip auth-proxy name AUTHPROXY http ! ip access-l ext INBOUND permit udp any any eq rip permit tcp any host 136.1.23.3 eq www deny ip any any log ! int fa0/1.23 ip access-group INBOUND in ip auth-proxy AUTHPROXY

This is what happens when I fire up a browser and http´s to the R3 interface:

(debug aaa authen, aaa author, auth-proxy and radius is on)

Rack1R3# *Jan 3 01:15:40.229: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:15:40.229: SYN SEQ 984706124 LEN 0 *Jan 3 01:15:40.229: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103 *Jan 3 01:15:40.237: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:15:40.237: ACK 4057202766 SEQ 984706125 LEN 0 *Jan 3 01:15:40.237: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103 *Jan 3 01:15:40.241: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:15:40.241: PSH ACK 4057202766 SEQ 984706125 LEN 282 *Jan 3 01:15:40.241: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103 Rack1R3# *Jan 3 01:15:40.245: Router interested packet returning src 136.1.23.123, dst 136.1.23.3 *Jan 3 01:15:40.257: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:15:40.261: ACK 4057202967 SEQ 984706407 LEN 0 *Jan 3 01:15:40.261: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103 Rack1R3# Rack1R3#! I fired up IE, entered the url and it is now showing a login prmpt "level_15 or view_access" Rack1R3# Rack1R3#! I enter the credentials PROXY/CISCO1234 and hit enter... Rack1R3# Rack1R3# *Jan 3 01:16:52.743: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:16:52.743: FIN ACK 4057202967 SEQ 984706407 LEN 0 *Jan 3 01:16:52.743: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103 *Jan 3 01:16:52.748: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:16:52.748: SYN SEQ 1525595421 LEN 0 *Jan 3 01:16:52.748: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104 *Jan 3 01:16:52.756: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:16:52.756: ACK 2275096303 SEQ 1525595422 LEN 0 *Jan 3 01:16:52.756: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104 *Jan 3 01:16:52.756: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:16:52.760: PSH ACK 2275096303 SEQ 1525595422 LEN 325 *Jan 3 01:16:52.760: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104 *Jan 3 01:16:52.764: Router interested packet returning src 136.1.23.123, dst 136.1.23.3 *Jan 3 01:16:52.772: AAA/BIND(00000006): Bind i/f *Jan 3 01:16:52.772: AAA/AUTHEN/LOGIN (00000006): Pick method list 'default' *Jan 3 01:16:52.776: RADIUS/ENCODE(00000006):Orig. component type = HTTP *Jan 3 01:16:52.776: RADIUS/ENCODE(00000006): dropping service type, "radius-server attribute 6 on-for-login-auth" is off *Jan 3 01:16:52.776: RADIUS(00000006): Config NAS IP: 0.0.0.0 *Jan 3 01:16:52.776: RADIUS/ENCODE(00000006): acct_session_id: 4 *Jan 3 01:16:52.776: RADIUS(00000006): sending *Jan 3 01:16:52.776: RADIUS/ENCODE: Best Local IP-Address 10.0.0.3 for Radius-Server 10.0.0.100 *Jan 3 01:16:52.780: RADIUS(00000006): Send Access-Request to 10.0.0.100:1645 id 1645/4, len 71 *Jan 3 01:16:52.780: RADIUS: authenticator 63 22 AD D4 03 CA 91 6C - 71 F8 27 E9 70 12 2A 18 *Jan 3 01:16:52.780: RADIUS: User-Name [1] 7 "PROXY" *Jan 3 01:16:52.784: RADIUS: User-Password [2] 18 * *Jan 3 01:16:52.784: RADIUS: NAS-Port-Type [61] 6 Virtual [5] *Jan 3 01:16:52.784: RADIUS: Calling-Station-Id [31] 14 "136.1.23.123" *Jan 3 01:16:52.784: RADIUS: NAS-IP-Address [4] 6 10.0.0.3 *Jan 3 01:16:52.796: RADIUS: Received from id 1645/4 10.0.0.100:1645, Access-Accept, len 181 *Jan 3 01:16:52.796: RADIUS: authenticator 4E 80 7B 47 1A 03 96 83 - BA 01 FE 83 9E A6 BB A6 *Jan 3 01:16:52.800: RADIUS: Framed-IP-Address [8] 6 255.255.255.255 *Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 30 *Jan 3 01:16:52.800: RADIUS: Cisco AVpair [1] 24 "auth-proxy:priv-lvl=15" *Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 49 *Jan 3 01:16:52.800: RADIUS: Cisco AVpair [1] 43 "auth-proxy:proxyacl#1=permit icmp any any" *Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 48 *Jan 3 01:16:52.804: RADIUS: Cisco AVpair [1] 42 "auth-proxy:proxyacl#2=permit tcp any any" *Jan 3 01:16:52.804: RADIUS: Class [25] 28 *Jan 3 01:16:52.804: RADIUS: 43 41 43 53 3A 30 2F 31 37 34 39 66 2F 61 30 30 [CACS:0/1749f/a00] *Jan 3 01:16:52.804: RADIUS: 30 30 30 33 2F 50 52 4F 58 59 [0003/PROXY] *Jan 3 01:16:52.808: RADIUS(00000006): Received from id 1645/4 *Jan 3 01:16:52.812: AAA/AUTHOR (00000006): Method list id=0 not configured. Skip author *Jan 3 01:16:54.815: AUTH-PROXY:proto_flag=4, dstport_index=4 *Jan 3 01:16:54.815: ACK 2275096504 SEQ 1525595747 LEN 0 *Jan 3 01:16:54.815: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104 Rack1R3# Rack1R3#! ... and the browser give me another login prompt... Rack1R3# Rack1R3#

See those lines in bold? What is happening here? They are not in the output from the solution guide. The “radius-server attribute 6 on for login-auth”-message can be tweaked away with a specific command but why should that be neccesary? And what about “AAA/AUTHOR Metod list id=0 not configured. Skip author”, that feels like a fatal error. But I do have “aaa authorization auth-proxy default group radius”-command.

Anyone?

EzVPN Server on IOS in three different flavous

Jimmy Larsson — Thu, 13 May 2010 20:06:16 +0000

Comparizon between 3 different ways to configure EzVPN on IOS.

Example 1: EzVPN-server vanilla-style

aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! username cisco password 0 cisco ! ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto dynamic-map DYNMAP 10 set transform-set TSET reverse-route ! ! crypto map CMAP client authentication list AAA-AUTHEN crypto map CMAP isakmp authorization list AAA-AUTHOR crypto map CMAP client configuration address respond crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! interface GigabitEthernet0/1 crypto map CMAP ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any ! !

Example 2: Vanilla-style with ISAKMP profile on top

aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto dynamic-map DYNMAP 10 set transform-set TSET set isakmp-profile ISAKMP-PROFILE reverse-route ! ! crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! ! interface GigabitEthernet0/1 crypto map CMAP ! ip local pool LOCALPOOL 8.9.24.201 8.9.24.254 ! ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any ! !

Differences between Example 1 and Example 2:
crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond ! crypto dynamic-map DYNMAP 10 set isakmp-profile ISAKMP-PROFILE ! crypto map CMAP client authentication list AAA-AUTHEN crypto map CMAP isakmp authorization list AAA-AUTHOR crypto map CMAP client configuration address respond

Example 3: DVTI
aaa new-model ! ! aaa authentication login default none aaa authentication login AAA-AUTHEN local aaa authorization network default none aaa authorization network AAA-AUTHOR local ! ! username cisco password 0 cisco ! crypto keyring EZVPN-KEYRING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp policy 10 encr aes authentication pre-share group 2 ! crypto isakmp client configuration group MYGROUP key cisco dns 8.8.8.8 pool LOCALPOOL acl SPLITTUNNEL save-password ! crypto isakmp profile ISAKMP-PROFILE keyring EZVPN-KEYRING match identity group MYGROUP client authentication list AAA-AUTHEN isakmp authorization list AAA-AUTHOR client configuration address respond virtual-template 1 ! ! crypto ipsec transform-set TSET esp-aes esp-sha-hmac ! crypto ipsec profile IPSEC-PROFILE set transform-set TSET set isakmp-profile ISAKMP-PROFILE ! interface Virtual-Template1 type tunnel ip unnumbered GigabitEthernet0/1 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROFILE ! ip local pool LOCALPOOL 8.9.24.201 8.9.24.254 ! ! ip access-list extended SPLITTUNNEL permit ip 8.9.5.0 0.0.0.255 any permit ip 8.9.6.0 0.0.0.255 any

Differences between Example 2 and Example 3
crypto isakmp profile ISAKMP-PROFILE virtual-template 1 ! crypto ipsec profile IPSEC-PROFILE set transform-set TSET set isakmp-profile ISAKMP-PROFILE ! crypto dynamic-map DYNMAP 10 set transform-set TSET set isakmp-profile ISAKMP-PROFILE reverse-route ! ! crypto map CMAP 1 ipsec-isakmp dynamic DYNMAP ! interface GigabitEthernet0/0 crypto map CMAP ! interface Virtual-Template1 type tunnel ip unnumbered GigabitEthernet0/1 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROFILE !

Config example: Vanilla static ipsec vpn with crypto map

Jimmy Larsson — Fri, 19 Mar 2010 13:37:16 +0000

(Topology here)

This is the far most common implementation of IPSEC Lan2Lan (at least in my world). It uses static crypto-maps applied to outbound interface of each router. A proxy-acl defines interresting traffic, authentication is done with a pre-shared key and it uses isakmp main-mode for setting up the tunnel.

Ok. First thing first. Make sure that the peer router is reachable before doing anything else:

r1#ping 10.10.30.3

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.30.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great. Now for the config. Start with r1. What traffic need to be protected? Create the crypto acl.
ip access-list extended acl_vpn permit ip host 192.168.1.50 host 10.3.3.3

Next. Create an isakmp policy defining the parameters for phase 1.
crypto isakmp policy 10 encr aes authentication pre-share group 5

For phase 1 we also need to set the pre-shared key.
crypto isakmp key cisco address 10.10.30.3

For phase 2 we need to create an ipsec transform-set.
crypto ipsec transform-set TSET esp-aes esp-sha-hmac

Now this needs to be put together in a crypto map.
crypto map CMAP 10 ipsec-isakmp set peer 10.10.30.3 set transform-set TSET match address acl_vpn

Last step is to assign this crypto-map to the outside interface.
interface FastEthernet0.11 crypto map CMAP

On the other router the exact thing needs to be defined, except for the crypto access-list that of course must be mirrored because of the reverse point of view. Also the peer ip must be the correct one. Here is the config for r3 with modifications from above highlighted.
ip access-list extended acl_vpn permit ip host 10.3.3.3 host 192.168.1.50 crypto isakmp policy 10 encr aes authentication pre-share group 5 crypto isakmp key cisco address 10.10.11.1 crypto ipsec transform-set TSET esp-aes esp-sha-hmac crypto map CMAP 10 ipsec-isakmp set peer 10.10.11.1 match address acl_vpn reverse-route static crypto map CMAP interface FastEthernet0.30 crypto map CMAP

In this example there is only one thing left to do: make sure that there are routes for the remote-end network. In my daily work I´ve setup lots of tunnels like this. It´s almost always the same: the router (or firewall) is connected to internet on outside with a default-route to the isp. But what if there is no default route? In my XXXXXXXXXXXXXXXXXXXXXXtopology the isn´t. Look:

r1#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route


Gateway of last resort is 10.10.10.1 to network 0.0.0.0
     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D EX    10.2.2.2/32 [170/1285120] via 10.10.10.1, 17:32:22, FastEthernet0.10

C       10.10.10.0/24 is directly connected, FastEthernet0.10

C       10.10.11.0/24 is directly connected, FastEthernet0.11

C       10.1.1.1/32 is directly connected, Loopback0

S       10.10.30.3/32 [1/0] via 10.10.11.2

D EX 192.168.1.0/24 [170/1285120] via 10.10.10.1, 17:32:22, FastEthernet0.10

D*EX 0.0.0.0/0 [170/1285120] via 10.10.10.1, 17:32:23, FastEthernet0.10
r3#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.3.3.3/32 is directly connected, Loopback0 S 10.10.11.1/32 [1/0] via 10.10.30.1 C 10.10.30.0/24 is directly connected, FastEthernet0.30 r3#

As you can see r1 has no route for 10.3.3.3 but only a default-route pointing in the wrong direction. R3 has no default-route at all, and certanly not a route for 192.168.1.50.

That means that even thou the vpn-peers have connectivity to establish a VPN-tunnel AND there is a definition of crypto traffic in the acl bound to the crypto map on outside interface the router is not clever enough to understand to send it that way. The route is not in the routing table. So, we need to add that. The cheapest way to do it is with static routes:

r1:
ip route 10.10.30.3 255.255.255.255 10.10.11.2

r3:
ip route 10.10.11.1 255.255.255.255 10.10.30.1

Now we are good to go. Lets ping 10.3.3.3 from our 192.168.1.50-host:

C:>ping 10.3.3.3


Skickar ping-signal till 10.3.3.3 med 32 byte data:

Svar från 10.3.3.3: byte=32 tid=2ms TTL=254

Svar från 10.3.3.3: byte=32 tid=2ms TTL=254

Svar från 10.3.3.3: byte=32 tid=2ms TTL=254

Svar från 10.3.3.3: byte=32 tid=2ms TTL=254
Ping-statistik för 10.3.3.3:

    Paket: Skickade = 4, Mottagna = 4, Förlorade = 0 (0 %),

Ungefärlig överföringstid i millisekunder:

    Lägsta = 2 ms, Högsta = 2 ms, Medel = 2 ms

C:>
(I apologize for the swedish OS )

But what if we are not allowed to use static routes. In real world noone would ever care but remember that in CCIE lab they will often throw a “and besides, you are not allowed to do it the easy way!” at you.

One solution could be to make the crypto map to insert a route for the remote networks into the local routing table. By doing that we can later on modify our crypto access-list without the need to care about static routes. Let´s do it!

r1#conf t Enter configuration commands, one per line. End with CNTL/Z. r1(config)#no ip route 10.3.3.3 255.255.255.255 10.10.11.2 r1(config)#crypto map CMAP 10 ipsec-isakmp r1(config-crypto-map)#reverse-route static This will remove previously installed VPN routes and SAs r1(config-crypto-map)# r1# r3#conf t Enter configuration commands, one per line. End with CNTL/Z. r3(config)#no ip route 192.168.1.50 255.255.255.255 10.10.30.1 r3(config)#crypto map CMAP 10 ipsec-isakmp r3(config-crypto-map)#reverse-route static r3#

The magic is that, in each router, a static route has appeared in the routing-table without a corresponding static route in the config:

r1#sh ip route 10.3.3.3 Routing entry for 10.3.3.3/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.10.30.3 Route metric is 0, traffic share count is 1

r1#sh run | incl ip route ip route 10.10.30.3 255.255.255.255 10.10.11.2 r1#

So. What is happening on the wire? First we see the ISAKMP-negotiation and then the encrypted ESP-traffic. Here, the output from wireshark placed in-transit between r1 and r3:

No. Time Source Destination Protocol Info 1 2010-03-19 07:44:28.799137 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode) 2 2010-03-19 07:44:28.805942 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode) 3 2010-03-19 07:44:28.810611 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode) 4 2010-03-19 07:44:28.911985 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode) 5 2010-03-19 07:44:29.022719 10.10.11.1 10.10.30.3 ISAKMP Identity Protection (Main Mode) 6 2010-03-19 07:44:29.027372 10.10.30.3 10.10.11.1 ISAKMP Identity Protection (Main Mode) 7 2010-03-19 07:44:29.032072 10.10.11.1 10.10.30.3 ISAKMP Quick Mode 8 2010-03-19 07:44:29.037702 10.10.30.3 10.10.11.1 ISAKMP Quick Mode 9 2010-03-19 07:44:29.042142 10.10.11.1 10.10.30.3 ISAKMP Quick Mode 10 2010-03-19 07:44:33.532046 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd) 11 2010-03-19 07:44:33.533282 10.10.30.3 10.10.11.1 ESP ESP (SPI=0x43fe1aba) 12 2010-03-19 07:44:34.533694 10.10.11.1 10.10.30.3 ESP ESP (SPI=0x9793dfcd) .. ..

A key to success in configuring VPN is to interprete the debug output. The most common debug-commands are “debug crypto isakmp” and “deb crypto ipsec”. But the output is massive and it takes some exercise to learn to read it. Here is the output from r1 in our example above when establishing the VPN. Let´s see what happens:

r1#clear crypto session r1#deb crypto isakmp Crypto ISAKMP debugging is on r1#deb crypto ipsec Crypto IPSEC debugging is on r1# r1# *Mar 19 08:50:47.623: IPSEC(sa_request): , (key eng. msg.) OUTBOUND local= 10.10.11.1, remote= 10.10.30.3, local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1), remote_proxy= 10.3.3.3/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel), lifedur= 3600s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Above we see that our ping triggered a request to setup a VPN (
*Mar 19 08:50:47.623: ISAKMP:(0): SA request profile is (NULL) *Mar 19 08:50:47.623: ISAKMP: Created a peer struct for 10.10.30.3, peer port 500 *Mar 19 08:50:47.623: ISAKMP: New peer created peer = 0x840A5978 peer_handle = 0x80000008 *Mar 19 08:50:47.623: ISAKMP: Locking peer struct 0x840A5978, refcount 1 for isakmp_initiator *Mar 19 08:50:47.623: ISAKMP: local port 500, remote port 500 *Mar 19 08:50:47.623: ISAKMP: set new node 0 to QM_IDLE *Mar 19 08:50:47.623: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 8515F140 *Mar 19 08:50:47.623: ISAKMP:(0):Can not start Aggressive mode, trying Main mode. *Mar 19 08:50:47.623: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3 *Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID *Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-07 ID *Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-03 ID *Mar 19 08:50:47.623: ISAKMP:(0): constructed NAT-T vendor-02 ID *Mar 19 08:50:47.623: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM *Mar 19 08:50:47.623: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1Going into the next state…IKE_I_MM1 is “we are sending main mode msg 1″*Mar 19 08:50:47.623: ISAKMP:(0): beginning Main Mode exchange *Mar 19 08:50:47.623: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_NO_STATE *Mar 19 08:50:47.623: ISAKMP:(0):Sending an IKE IPv4 Packet. *Mar 19 08:50:47.627: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_NO_STATE *Mar 19 08:50:47.627: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Mar 19 08:50:47.627: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2Going into the next state…IKE_I_MM2 means “we got a reply on our first message”*Mar 19 08:50:47.627: ISAKMP:(0): processing SA payload. message ID = 0 *Mar 19 08:50:47.627: ISAKMP:(0): processing vendor id payload *Mar 19 08:50:47.627: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch *Mar 19 08:50:47.627: ISAKMP (0): vendor ID is NAT-T RFC 3947 *Mar 19 08:50:47.627: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3We have a pre-shared key configured for remote peer. That´s good…*Mar 19 08:50:47.627: ISAKMP:(0): local preshared key found *Mar 19 08:50:47.627: ISAKMP : Scanning profiles for xauth ... *Mar 19 08:50:47.627: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy *Mar 19 08:50:47.627: ISAKMP: encryption AES-CBC *Mar 19 08:50:47.627: ISAKMP: keylength of 128 *Mar 19 08:50:47.627: ISAKMP: hash SHA *Mar 19 08:50:47.631: ISAKMP: default group 5 *Mar 19 08:50:47.631: ISAKMP: auth pre-share *Mar 19 08:50:47.631: ISAKMP: life type in seconds *Mar 19 08:50:47.631: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 *Mar 19 08:50:47.631: ISAKMP:(0):atts are acceptable. Next payload is 0We have match on ISAKMP policies. This example is simple since both peers has only one isakmp policy defined so the first try is a match. Remember, both peers try to find a match among all their localy configured isakmp policies and their buddies. In more complex configurations or when dealing with vpn-clients it´s not uncommon to see tenths of policies from each end. Then the previous lines will be repeated for all attempts.*Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:actual life: 0 *Mar 19 08:50:47.631: ISAKMP:(0):Acceptable atts:life: 0 *Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa vpi_length:4 *Mar 19 08:50:47.631: ISAKMP:(0):Fill atts in sa life_in_seconds:86400 *Mar 19 08:50:47.631: ISAKMP:(0):Returning Actual lifetime: 86400 *Mar 19 08:50:47.631: ISAKMP:(0)::Started lifetime timer: 86400. *Mar 19 08:50:47.631: ISAKMP:(0): processing vendor id payload *Mar 19 08:50:47.631: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch *Mar 19 08:50:47.631: ISAKMP (0): vendor ID is NAT-T RFC 3947 *Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE *Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2 *Mar 19 08:50:47.631: ISAKMP:(0): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_SA_SETUP *Mar 19 08:50:47.631: ISAKMP:(0):Sending an IKE IPv4 Packet. *Mar 19 08:50:47.631: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Mar 19 08:50:47.631: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3Ok. IKE_I_MM3 means that we send the third packet (our second as a sender)

*Mar 19 08:50:47.731: ISAKMP (0): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_SA_SETUP *Mar 19 08:50:47.731: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Mar 19 08:50:47.731: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4And we got a reply. The fourth packet in the 6-packet main-mode flow


*Mar 19 08:50:47.731: ISAKMP:(0): processing KE payload. message ID = 0

*Mar 19 08:50:47.827: ISAKMP:(0): processing NONCE payload. message ID = 0

*Mar 19 08:50:47.827: ISAKMP:(0):found peer pre-shared key matching 10.10.30.3

*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload

*Mar 19 08:50:47.827: ISAKMP:(2007): vendor ID is Unity

*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload

*Mar 19 08:50:47.827: ISAKMP:(2007): vendor ID is DPD

*Mar 19 08:50:47.827: ISAKMP:(2007): processing vendor id payload

*Mar 19 08:50:47.827: ISAKMP:(2007): speaking to another IOS box!

*Mar 19 08:50:47.827: ISAKMP:received payload type 20

*Mar 19 08:50:47.827: ISAKMP (2007): His hash no match - this node outside NAT

*Mar 19 08:50:47.827: ISAKMP:received payload type 20

*Mar 19 08:50:47.827: ISAKMP (2007): No NAT Found for self or peer

*Mar 19 08:50:47.827: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

*Mar 19 08:50:47.827: ISAKMP:(2007):Old State = IKE_I_MM4  New State = IKE_I_MM4

*Mar 19 08:50:47.827: ISAKMP:(2007):Send initial contact *Mar 19 08:50:47.827: ISAKMP:(2007):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR *Mar 19 08:50:47.827: ISAKMP (2007): ID payload next-payload : 8 type : 1 address : 10.10.11.1 protocol : 17 port : 500 length : 12 *Mar 19 08:50:47.827: ISAKMP:(2007):Total payload length: 12 *Mar 19 08:50:47.827: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) MM_KEY_EXCH *Mar 19 08:50:47.827: ISAKMP:(2007):Sending an IKE IPv4 Packet. *Mar 19 08:50:47.827: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Mar 19 08:50:47.827: ISAKMP:(2007):Old State = IKE_I_MM4 New State = IKE_I_MM5So. the fifth packet is where we send our pre-shared key*Mar 19 08:50:47.831: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) MM_KEY_EXCH *Mar 19 08:50:47.831: ISAKMP:(2007): processing ID payload. message ID = 0 *Mar 19 08:50:47.831: ISAKMP (2007): ID payload next-payload : 8 type : 1 address : 10.10.30.3 protocol : 17 port : 500 length : 12 *Mar 19 08:50:47.831: ISAKMP:(0):: peer matches *none* of the profiles *Mar 19 08:50:47.831: ISAKMP:(2007): processing HASH payload. message ID = 0 *Mar 19 08:50:47.831: ISAKMP:(2007):SA authentication status: authenticated *Mar 19 08:50:47.831: ISAKMP:(2007):SA has been authenticated with 10.10.30.3 *Mar 19 08:50:47.831: ISAKMP: Trying to insert a peer 10.10.11.1/10.10.30.3/500/, and inserted successfully 840A5978. *Mar 19 08:50:47.831: ISAKMP:(2007):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Mar 19 08:50:47.831: ISAKMP:(2007):Old State = IKE_I_MM5 New State = IKE_I_MM6We got a reply, the sixth (and last) packet of Main mode phase 1

*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE *Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_I_MM6 *Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETESo. Phase 1 is completed. *Mar 19 08:50:47.835: ISAKMP:(2007):beginning Quick Mode exchange, M-ID of -1445410418 Quick mode = Phase 1 *Mar 19 08:50:47.835: ISAKMP:(2007):QM Initiator gets spi *Mar 19 08:50:47.835: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLE *Mar 19 08:50:47.835: ISAKMP:(2007):Sending an IKE IPv4 Packet. *Mar 19 08:50:47.835: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_INTERNAL, IKE_INIT_QM *Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_QM_READY New State = IKE_QM_I_QM1IKE_QM_I_QM1 means that we´ve sent our first phase 2 packet*Mar 19 08:50:47.835: ISAKMP:(2007):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE *Mar 19 08:50:47.835: ISAKMP:(2007):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

*Mar 19 08:50:47.843: ISAKMP (2007): received packet from 10.10.30.3 dport 500 sport 500 Global (I) QM_IDLEWe got an answer. The reply is the second of three packets in phase 2. The content of this received packet is SA-data for ipsec SA:s. Which traffic to protect (proxies), encryption parameters and so on. What happens next is that this information is compared to our local configuration to make sure that it matches. Then the SA:s are being setup…
*Mar 19 08:50:47.843: ISAKMP:(2007): processing HASH payload. message ID = -1445410418 *Mar 19 08:50:47.843: ISAKMP:(2007): processing SA payload. message ID = -1445410418 *Mar 19 08:50:47.843: ISAKMP:(2007):Checking IPSec proposal 1 *Mar 19 08:50:47.843: ISAKMP: transform 1, ESP_AES *Mar 19 08:50:47.843: ISAKMP: attributes in transform: *Mar 19 08:50:47.843: ISAKMP: encaps is 1 (Tunnel) *Mar 19 08:50:47.843: ISAKMP: SA life type in seconds *Mar 19 08:50:47.843: ISAKMP: SA life duration (basic) of 3600 *Mar 19 08:50:47.843: ISAKMP: SA life type in kilobytes *Mar 19 08:50:47.843: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 *Mar 19 08:50:47.843: ISAKMP: authenticator is HMAC-SHA *Mar 19 08:50:47.843: ISAKMP: key length is 128 *Mar 19 08:50:47.843: ISAKMP:(2007):atts are acceptable. *Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1 *Mar 19 08:50:47.843: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 10.10.11.1, remote= 10.10.30.3, local_proxy= 192.168.1.50/255.255.255.255/0/0 (type=1), remote_proxy= 10.3.3.3/255.255.255.255/0/0 (type=1), protocol= ESP, transform= NONE (Tunnel), lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0 *Mar 19 08:50:47.843: Crypto mapdb : proxy_match src addr : 192.168.1.50 dst addr : 10.3.3.3 protocol : 0 src port : 0 dst port : 0 *Mar 19 08:50:47.843: ISAKMP:(2007): processing NONCE payload. message ID = -1445410418 *Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418 *Mar 19 08:50:47.843: ISAKMP:(2007): processing ID payload. message ID = -1445410418 *Mar 19 08:50:47.843: ISAKMP:(2007): Creating IPSec SAs *Mar 19 08:50:47.843: inbound SA from 10.10.30.3 to 10.10.11.1 (f/i) 0/ 0 (proxy 10.3.3.3 to 192.168.1.50) *Mar 19 08:50:47.843: has spi 0xCB15AC0E and conn_id 0 *Mar 19 08:50:47.843: lifetime of 3600 seconds *Mar 19 08:50:47.843: lifetime of 4608000 kilobytes *Mar 19 08:50:47.843: outbound SA from 10.10.11.1 to 10.10.30.3 (f/i) 0/0 (proxy 192.168.1.50 to 10.3.3.3) *Mar 19 08:50:47.843: has spi 0xBA3D8C69 and conn_id 0 *Mar 19 08:50:47.843: lifetime of 3600 seconds *Mar 19 08:50:47.847: lifetime of 4608000 kilobytes *Mar 19 08:50:47.847: ISAKMP:(2007): sending packet to 10.10.30.3 my_port 500 peer_port 500 (I) QM_IDLEWe send our third and last packet in phase 2 packet exchange…*Mar 19 08:50:47.847: ISAKMP:(2007):Sending an IKE IPv4 Packet. *Mar 19 08:50:47.847: ISAKMP:(2007):deleting node -1445410418 error FALSE reason "No Error" *Mar 19 08:50:47.847: ISAKMP:(2007):Node -1445410418, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH *Mar 19 08:50:47.847: ISAKMP:(2007):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE *Mar 19 08:50:47.847: IPSEC(key_engine): got a queue event with 1 KMI message(s) *Mar 19 08:50:47.847: Crypto mapdb : proxy_match src addr : 192.168.1.50 dst addr : 10.3.3.3 protocol : 0 src port : 0 dst port : 0 *Mar 19 08:50:47.847: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 10.10.30.3 *Mar 19 08:50:47.847: IPSEC(rte_mgr): VPN Route Event static keyword or dynamic SA create for 10.10.30.3 *Mar 19 08:50:47.847: IPSEC(policy_db_add_ident): src 192.168.1.50, dest 10.3.3.3, dest_port 0

*Mar 19 08:50:47.847: IPSEC(create_sa): sa created, (sa) sa_dest= 10.10.11.1, sa_proto= 50, sa_spi= 0xCB15AC0E(3407195150), sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 59 sa_lifetime(k/sec)= (4453107/3600) *Mar 19 08:50:47.847: IPSEC(create_sa): sa created, (sa) sa_dest= 10.10.30.3, sa_proto= 50, sa_spi= 0xBA3D8C69(3124595817), sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 60 sa_lifetime(k/sec)= (4453107/3600) *Mar 19 08:50:47.847: IPSEC(update_current_outbound_sa): updated peer 10.10.30.3 current outbound sa to SPI BA3D8C69 *Mar 19 08:50:48.027: ISAKMP:(2006):purging SA., sa=8515E77C, delme=8515E77C r1#

Voila!

And just to make sure all looks good let´s check our SA:s:

r1#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 10.10.30.3 10.10.11.1 QM_IDLE 2007 ACTIVE r1#As you can see there is one isakmp SA created. State QM_IDLE is good, it means that all is fine in isakmp/phase 1r1#sh crypto ipsec sa


interface: FastEthernet0.11

    Crypto map tag: CMAP, local addr 10.10.11.1
   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.1.50/255.255.255.255/0/0)

   remote ident (addr/mask/prot/port): (10.3.3.3/255.255.255.255/0/0)

   current_peer 10.10.30.3 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7

    #pkts decaps: 7, #pkts decrypt: 7, #pkts verify: 7

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 1, #recv errors 0
     local crypto endpt.: 10.10.11.1, remote crypto endpt.: 10.10.30.3

     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0.11

     current outbound spi: 0xBA3D8C69(3124595817)

     PFS (Y/N): N, DH group: none
     inbound esp sas:

      spi: 0xCB15AC0E(3407195150)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 59, flow_id: Onboard VPN:59, sibling_flags 80000046, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4453106/1047)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:

      spi: 0xBA3D8C69(3124595817)

        transform: esp-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 60, flow_id: Onboard VPN:60, sibling_flags 80000046, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4453106/1047)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE
     outbound ah sas:

outbound pcp sas: r1# There are 2 ipsec SA:s established. One in each direction. That´s just the way it is. Looking at the number of encaps/decaps packets gives us a hint that we are both sending traffic and receiving traffic thru the tunnel.

That´s all for now. This was a massive post. I will use this exampel as a template for the next VPN configurations so hopefully they will not be as massive as this.

Please feel free to comment if there is anything I´ve missed or if I got something the wrong way…

Configs for r1 and r3 here…

Configuration examples for VPN solutions

Jimmy Larsson — Fri, 19 Mar 2010 11:37:19 +0000

IPsec. Gre. Ipsec/Gre. Crypto maps. Isakmp profiles. Ipsec profiles. Dynamic crypto maps. DMVPN Phase 1, phase 2, phase 3. GET VPN. Easy VPN. NHRP. X-auth. PKI. AnyConnect. Portal. RRI. I could continue forever.

In my journey of investigating all weird flavours of VPN I´ve decided to try each of them in my home-lab and make a blog-post of each one. I will use a common base topology like this:

The scenario is this: Two routers, r1 and r3, are connected to a transit-network. It might be internet, it might be anything else. It might be a crossover ethernet-cable and it might be a multi-hop MPLS-cloud. The host 192.168.1.50 needs to access 10.3.3.3 in a secure way over the transit-network.

To make sure that the routers have connectivity they have host-routes of eachother into the transit-network.

This is a blog post to collect the different configurations together. In the list below I will add each configuration example as I go…

GRE-tunneling between two IOS-routers.

Jimmy Larsson — Tue, 16 Mar 2010 21:23:18 +0000

The last days I´ve been playing with GRE-tunnels (just to prepare myself for testing DMVPN). I did a simple GRE-tunnel between two routers (split apart with a firewall simulating internet) and made EIGRP flow thru the the tunnel. It´s really cool and simple. Just create a Tunnel-interface and assign source and destinations:

interface Tunnel0 ip address 10.99.99.1 255.255.255.0 tunnel source FastEthernet0.11 tunnel destination 10.10.30.3

and the same on the other router:

interface Tunnel0 ip address 10.99.99.3 255.255.255.0 tunnel source FastEthernet0.30 tunnel destination 10.10.11.1

the 10.10.11.1 and 10.10.30.3 ip:s are the physical interface-ip of respective router. The tunnel-interfaces shares a common subnet, 10.99.99.0/24.

After doing that I just added the interface to the EIGRP process:

router eigrp 11 network 10.99.99.0 0.0.0.255

Since the GRE-tunnel handles multicast the EIGRP-enabled routers become neighbours and exchange routes.

The next step is to encrypt the traffic. Sending this tunnel-traffic in clear text is not a really good idea, is it? What needs to be done is to create an ipsec profile and isakmp policy on each router.

crypto ipsec transform-set TSET esp-aes esp-sha-hmac mode transport crypto ipsec profile IPSECPROF set transform-set TSET set pfs group2 crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.10.30.3

After doing that the only remaining step is to apply the ipsec profile to the tunnel interface, and voila, all traffic thru that interface will be encrypted:

interface Tunnel0 ip address 10.99.99.1 255.255.255.0 tunnel source FastEthernet0.11 tunnel destination 10.10.30.3 tunnel protection ipsec profile IPSECPROF

One thing to remember. Never use gre keepalives when ipsec-encrypting your GRE-traffic. This got me stuck in troubleshooting for a while before a kind guy on a mailing-list told me so and referred to this article.

Here and here are the complete configs for ipsec-protected GRE-tunnels in my home lab environment.

Lab notes – WB1 Lab4 Part 1

Jimmy Larsson — Fri, 26 Feb 2010 13:46:22 +0000

Today I started to work with IPExpert CCIE Security workbook 1 Lab 4a – VPN-solutions. During my work I made the following notes which might be interresting to read for other CCIE-candidates. I will also from now on continue to do these notes and post them on this blog. Explaining and writing is simply a great way for me to learn.

Also, if my boss some day ask me what the heck I am doing all these work-hours, I will gladly give him a link to this blog.

Task 4.1 – IOS CA

This was quite straight-forward. Make an IOS become a root certificate authority for later use.

What confuses me is that there is nothing in the configuation telling it to authenticate with certificates. All there is compared to “normal” preshared-key-auth is a missing “authen pre-share”. Which ofcours means that authentication is done with the certificates by default. I understand, I just have to get used to the fact that there is no command visible in the crypto isakmp policy saying “authentication MY-CA-TRUSTPOINT”.
When entering a wrong peer in the crypto map, it´s not just enough to re-enter a new ip. Since a crypto map sequence can have multiple peers for redundancy the old one doesnt go away. The effect is that the tunnel goes up, after a while, since it first tries with the bad peer ip before trying the second one. Remove the first.
Me being more used to vpns in asa than in ios usually tear down vpn-tunnels with the commands “clear crypto isakmp sa” and “clear crypto ipsec sa”. In IOS the corresponding command is “clear crypto session”. Cool.

Task 4.2 – IOS L2L

This is all about enrollment of certificates from the CA in previous task to two IOS-routers and setup an ipsec-tunnel.

What confuses me is that there is nothing in the configuation telling it to authenticate with certificates. All there is compared to “normal” preshared-key-auth is a missing “authen pre-share”. Which ofcours means that authentication is done with the certificates by default. I understand, I just have to get used to the fact that there is no command visible in the crypto isakmp policy saying “authentication MY-CA-TRUSTPOINT”.
When entering a wrong peer in the crypto map, it´s not just enough to re-enter a new ip. Since a crypto map sequence can have multiple peers for redundancy the old one doesnt go away. The effect is that the tunnel goes up, after a while, since it first tries with the bad peer ip before trying the second one. Remove the first.
Me being more used to vpns in asa than in ios usually tear down vpn-tunnels with the commands “clear crypto isakmp sa” and “clear crypto ipsec sa”. In IOS the corresponding command is “clear crypto session”. Cool.

Task 4.3 – VPN IOS-ASA

The task was to setup a tunnel between IOS and ASA. Preshared-key, all straight-forward. However, I was asked to prioritize to certan traffic going into the tunnel from the IOS-router. This was done by creating a service-policy on outside-interface like this:

class-map match-all VPN-CLASS

match access-group 150 ! The ACL that defines the traffic to prioritize

policy-map VPN-POLICY

class VPNCLASS


priority 200 (I was also assign to restrict the prioritized traffic to 200kbps)
interface Fa1/1

service-policy output VPN-POLICY

And, dont forget to do “qos pre-classify” on the crypto map! Otherwise your class-map has to look for ESP-traffic and that is not very granular, is it?
“create lo3 on r2, assign it ip 192.168.3.2/24″ and “create a vpn tunnel between Vlan100 and the newly created loopback network”. I used “host 192.168.3.2″ in acl, but it clearly states “the loopback _network_”. Darn!

Task 4.4 L2L Aggressive mode with PSK

Stuck Twice.

I PROMISE NEVER TO FORGET TO APPLY THE CRYPTO MAP TO THE INTERFACE AGAIN

I PROMISE NOT TO FORGET TO APPLY THE CRYPTO MAP TO IF AGAIN

I PROMISE NOTTO FORGET TO APPLY THE CRYPTO MAP TO IF AGAIN

Stuck again. Couldn´t get the tunnel up even when comparing my configs with the solution guide. After getting help from OSL I made it:

I am struggling with this task, I simply cannot get the tunnel up. And I cant see what Ive done wrong.

Background: Make a tunnle between r2 and r5. Assume that r5-ip is dynamic, the tunnel should only be initiated from r5. (that is: dynamic map on r2).

The relevant parts of the config looks like this:

Answer from Brandon:

Not sure if this is it or not but you have crypto isakmp key ipexpert
hostname r5.ipexpert.com and the debug shows FQDN name : R5.ipexpert.com

Voila! Changed the “r5″ to “R5″ and it started working!

Task 4.5 L2L Overlapping subnets.

The task was to create a tunnel between 4 routers to protect traffic between internal nets. The restrictions was: no static routing, no crypto maps and no GRE.

I havent worked very much with tunnel-interfaces but this was a pleasant first date. It´s kind of magic making a virtual interface and make the router route traffic thru it. Even more coolish when you encrypt the traffic and make a routing protocol talk thru the tunnel.
Since I wasn´t allowed to use static routing I had to create loopback-interfaces to force knowledge of that local networks translated address-space into the routing-protocol. I was thinking of some kind of “add-reverse-route”-option for the “ip nat source static network”-command but I guess there is no such solution? Or could this routing-issue be solved in another way?

Task 4.6 – Easy VPN Server on IOS

This task deals with connecting a plain ipsec-client from XP workstation to an VPN-server on ios. First step was to verify connectivity on XP. Wrong IP, changing it. Now, a good advice from someone “who knows”: Do NOT add a default route on the student NIC of the labb pc:s. It has 2 nics and the other one is convinently named “Outside NIC – Do not Touch!” which is fine because thats how you reach the machine over internet. But if you add a default “gateway” on the student nic (which you are allowed to fool with) you will convert that kind little XP-machine into an unpredicible beast. If you are lucky u will reach it after a while and remove that default gw. So I´ve heard.
IOS auto-enroll and the enroll-feature of ipsec vpn client is cool. Just point it to http:///cgi-bin/pkiclient.exe and request a certificate.
I had to look at the solution guide quite alot in this case. Even when doing that I couldnt get the vpn-client to connect. I just got these error messages:


Feb 26 12:35:24.740: ISAKMP:(1011):deleting SA reason "Recevied fatal informational" state (R) CONF_XAUTH    (peer 8.9.2.200)
Feb 26 12:35:24.740: ISAKMP:(1011):deleting SA reason "Recevied fatal informational" state (R) CONF_XAUTH    (peer 8.9.2.200)

Suddenly I looked at the bottom right corner of my screen and saw tht the time was 3 minutes until the lab-period was over. I have never backed up a bunch of routers this fast before. First thing next lab-attempt will be to load the configs and troubleshoot the EasyVPN-config of R4.

Conclusion of this lab so far: It´s intense! I´ve been configuring plenty of VPN-solutions before, but I guess that my experience covers only 20-30% of the VPN-related topics in this lab. All these profiles-configurations in IOS are all new to me. I guess I have some CCO-chapters to read during the weekend…

Here are my current configurations: asa1, r2, r4, r5 and r6.

Cisco IOS Zone Based Policy Firewall

Jimmy Larsson — Thu, 04 Feb 2010 18:37:57 +0000

The last days I have been testing Zone Based Policy Firewall in Cisco IOS. It´s a feature much like CBAC. It´s using the same basics of inspection-configuration. The major difference between CBAC and ZBFW is that while the first is built upon inspection at specific interfaces, the latter defines zones of one or many interfaces and then defines inspection in a single direction from one zone to another.

Task 1

To make a somewhat realistic scenario I take a router in my home-lab. It´s preconfigured for basic routing without filtering anything. The goal is to make the router stateful with ZBFW. I want to block all traffic thru the router except from outbound telnet. Lets rock.

Step 1. Define zones

Each interface participating in a Zone Based Firewall-setup needs to be added to a zone. In this basic setup I have 2 zones: INSIDE and OUTSIDE

zone security OUTSIDE zone security INSIDE

Step 2. Applying zones to interfaces

I have three interfaces in my setup: two internal an one external. The zone-membership is configured on interface-level.

interface FastEthernet0 zone-member security OUTSIDE ! interface FastEthernet1 zone-member security INSIDE ! interface Vlan13 zone-member security INSIDE

3. Define allowed traffic

Let´s focus on outbound traffic. We want to allow all telnet-traffic from our INSIDE-zone. This is done with a class-map type inspect. This class-map will later be reused for all other outbound traffic to be inspected, so remember to name it wisely.

class-map type inspect match-any class-INSIDE-TO-OUTSIDE match protocol telnet

4. Decide what do do with it

Next step is configuring the policy-map. Since only one policy-map can be assigned at each function (in this case for traffic from INSIDE to OUTSIDE) it might be reused later. This policy-map will put together all actions we want to take on all traffic in the direction. For now we want to tell our router to inspect all traffic defined by the class-map created in the previous step.

The policy-map is processed in top-down order. At the end of the policy-map there is a class class-default that by default drops “all other” traffic, just the way the implicit deny ip any any does in access-lists.

policy-map type inspect policy-INSIDE-TO-OUTSIDE class type inspect class-INSIDE-TO-OUTSIDE inspect class class-default drop !

5. Apply it

Now the final step is to apply this configuration. We have zones, let´s create a zone-pair. It is a definition of traffic from one zone to another, in one direction. Traffic in opposit direction (that is in our case: traffic initiated on OUTSIDE going to INSIDE) needs to be taken care of with another setup of class-map, policy-map and zone-pair.

zone security OUTSIDE zone security INSIDE zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE service-policy type inspect policy-INSIDE-TO-OUTSIDE

6. Logging

Also, a really good command to remember is the “ip inspect log drop-pkt”. Without it you will not see traffic that gets dropped by the firewall. So remember to add it and maybe remove it as the last step before leaving the building…

ip inspect log drop-pkt

7. Verify

Lets verify that I can telnet from INSIDE to OUTSIDE:

r1#telnet 10.0.11.1 Trying 10.0.11.1 ... Open

User Access Verification

Password: Password: Password: [Connection to 10.0.11.1 closed by foreign host] r1#

Great. It works.

What we have accomplished is to make a chain of “maps” that looks like this on a flow chart:

Task 2. Also allow specific pings outbound

The next task for me is to enable ping from inside hosts to the outside. To make it a bit trickier I decide to make an exception for the internal host 10.13.13.13 who should not be able to ping.

Step 1. Define traffic

First define what traffic will be allowed. Since we need to specify traffic on a per-host-level we cannot just “match protocol icmp” like we did with telnet, but instead do it with an access-list that is referred to in our previous created class-map (which is type match-any which mean that it can have multiple match-statements and it´s enough to match one of them).

ip access-list extended acl-INSIDE-TO-OUTSIDE-inspect deny icmp host 10.13.13.13 any echo permit icmp any any echo !

2. Add it to the class-map.

class-map type inspect match-any class-INSIDE-TO-OUTSIDE match protocol telnet (<--- Already there!) match access-group name acl-INSIDE-TO-OUTSIDE-inspect

3. Verify.

Since the class-map were already in the policy-map with the action “inspect” I dont need to do anything else. We´re all done. Lets verify:

r3#ping 10.0.11.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.11.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms r3#ping 10.0.11.1 sou lo0

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.11.1, timeout is 2 seconds: Packet sent with a source address of 10.13.13.13 ..... Success rate is 0 percent (0/5) r3#

Yes! We can ping an outside host, but not when sourcing from 10.13.13.13. This is verified by the log-output (remember the ip inspect log drop-pkt-command?):

%FW-6-LOG_SUMMARY: 5 packets were dropped from 10.13.13.13:8 => 10.0.11.1:0 (target:class)-(INSIDE-TO-OUTSIDE:class-default)

Now the flow of configuration building-blocks looks like this:

So, why did I specify the telnet-traffic with “match protocol telnet” but the icmp-traffic with an access-list? First of all, the end-result is the same; it will inspect the state of the traffic. Even the pings are inspected and handled in a session-alike fashion.

When doing “match protocol telnet” i rely upon the PAM-table (Port Application Mapping) which by default saids that “telnet” equals tcp/23. If I add a PAM-entry that adds tcp/2323 to the telnet-application, traffic on that port should also have been inspected. But the granularity of just specifying the port or application was not good enough for the ping since we needed to define an exception for a single host.
Of course I could also put the telnet-traffic into the access-list, it would have the exact same end result:

class-map type inspect match-any class-INSIDE-TO-OUTSIDE no match protocol telnet ! ip access-list extended acl-INSIDE-TO-OUTSIDE-inspect deny icmp host 10.13.13.13 any echo permit icmp any any echo permit tcp any any eq 23

Notes:

I have had a REALLY hard time trying to fully understand the concept of class-maps and policy-maps when doing inspection. This simple rule has made it so much easier to understand how to do and not: ALL class-maps and Policy-maps should be “type inspect” when working with inspection. Doing “class-map yadayo” without “type inspect” in between (and the same for policy-maps) just made me confused. Plain (as in not type inspect) policy-maps and class-maps are for other purposes than making the router stateful.
Security-zones doesnt cooperate very well with interface access-lists. Actually, the idea behind ZBFW is to replace acls on that router. That means that ZBFW doesn´t make any “holes” in any existing access-lists. Since interface-acls in inbound direction gets processed before zbfw you need to have access-lists “wide-open” enough to make sure that all ZBFW-traffic gets thru. I recommend not applying acls to interfaces when using ZBFW.
Traffic to and from the router itself are wide open in this example. There is a self-zone that takes care of this. Hopefully this will be covered in a later post.
Traffic between interfaces in the same zone are permitted.

Conclusion:

ZBFW is cool if you have to secure a Cisco-router which have many interfaces that can be treated with the same security-policy.

PAM-table – a sheat-sheet for well known port numbers

Jimmy Larsson — Wed, 03 Feb 2010 21:35:22 +0000

Do you have a hard time remembering all those port-numbers? Most of them are probably burned-in to the back of your head. But some of them can be hard remembering. For me for instance, I can never remember which port BGP uses. The problem is that when doing your CCIE-lab you have no access to your best friend; Google.

The solution? Use the PAM-table in the routers. This port-to-application-mapping is used for inspection engines that need to know which ports to inspect when doing http inspection as an example. This table can be tweaked but the default mapping can give you a huge load of information about most protocol. The command is “show ip port-map”:

r1#sh ip port-map Default mapping: snmp udp port 161 system defined Default mapping: echo tcp port 7 system defined Default mapping: echo udp port 7 system defined Default mapping: telnet tcp port 23 system defined Default mapping: wins tcp port 1512 system defined Default mapping: n2h2server tcp port 9285 system defined Default mapping: n2h2server udp port 9285 system defined Default mapping: nntp tcp port 119 system defined Default mapping: pptp tcp port 1723 system defined Default mapping: rtsp tcp port 554,8554 system defined Default mapping: bootpc udp port 68 system defined Default mapping: gdoi udp port 848 system defined r1#

The table is quite extensive so I recommend piping the output to find what you are looking for. Like this…

BGP?
r1#sh ip port-map | incl bgp Default mapping: bgp tcp port 179 system defined r1#

These Netbios-ports. Which is which?
r1#sh ip port-map | incl netbios Default mapping: netbios-dgm udp port 138 system defined Default mapping: netbios-ssn tcp port 139 system defined Default mapping: netbios-ns udp port 137 system defined r1#

And finally, what is that udp/520-traffic that shows up in my logs?
r1#sh ip port-map | incl 520 Default mapping: router udp port 520 system defined r1#
(Well. It would have been clearer if they just said “RIP” instead of “router”, but you get the point…)

IOS Archive feature

Jimmy Larsson — Fri, 22 Jan 2010 10:33:58 +0000

What changes have been done since last “wr mem”? Or more like; what differences are there between running-config and startup-config?

Use the archive-feature!

r2#sh arch conf diff nvram:startup-config system:running-config Contextual config diffs: line vty 0 4 +transport input all +transport output all line vty 0 4 -transport input telnet -transport output all

Wanna make periodic backups of the router config to local flash?

Use the archive-feature!

r1#sh run | sect archive archive log config record rc logging enable hidekeys path flash:backup time-period 86400 r1#

You can of course archive the config to an external server instead...

r1(config)#archive r1(config-archive)#path ? flash: Write archive on flash: file system ftp: Write archive on ftp: file system http: Write archive on http: file system https: Write archive on https: file system pram: Write archive on pram: file system rcp: Write archive on rcp: file system scp: Write archive on scp: file system tftp: Write archive on tftp: file system

r1(config-archive)#

Cisco ACL logging with cookies

Jimmy Larsson — Fri, 15 Jan 2010 11:29:40 +0000

The cookie-feature of logging in router access-lists is new for me and I fell in love with it at first sight! I don´t know how often I debug complexe acls trying to find where specific traffic hits. By adding a “cookie” after the log-statement in an ace you get that cookie tagged to all log-events. Look:

R5(config-ext-nacl)#deny ip any any log ? WORD User defined cookie (max of 64 char)

Applied to an acl:

ip access-list extended acl_vlan1256 permit icmp any any echo permit icmp any any echo-reply permit icmp any any traceroute deny tcp any host 9.4.45.4 eq www time-range MAINT permit tcp any host 9.4.45.4 eq www deny tcp any eq bgp any log SOURCE-BGP deny tcp any any eq bgp log DEST-BGP deny udp any any eq ntp log BLOCKING_THAT_DAMN_NTP_THINGIE deny ip any any log BLOCK-ALL

And the logging looks like this:

*Jan 14 22:25:59.246: %SEC-6-IPACCESSLOGP: list acl_vlan1256 denied tcp 9.9.156.9(25402) -> 9.9.156.5(179), 1 packet [DEST-BGP] *Jan 14 22:26:23.586: %SEC-6-IPACCESSLOGP: list acl_vlan1256 denied tcp 9.9.156.9(18382) -> 9.9.156.5(23), 1 packet [BLOCK-ALL] *Jan 14 22:26:28.438: %SEC-6-IPACCESSLOGP: list acl_vlan1256 denied tcp 9.9.156.9(179) -> 9.9.156.5(14918), 1 packet [SOURCE-BGP] *Jan 14 22:26:33.267: %SEC-6-IPACCESSLOGP: list acl_vlan1256 denied tcp 9.9.156.9(26842) -> 9.9.156.5(179), 1 packet [DEST-BGP]

Cool!

To: Santa


Hi, dude!
Next christmas I wish the logging-cookie-feature-thing in ASA. Can I have it, please?

Regards Jimmy