VPNCEPTION

A while back I was asked if it was possible to run a series of tunnels between three routers. The requirements were that routers A and B had a GRE over IPSec tunnel and routers A and C had a GRE tunnel that went inside the tunnel between A and B.

After a beer or two and spending some time on the white board I came up with a solution that used series VTIs and routing to control traffic flow. Everything looked plausible so it was time to lab out a proof of concept. After fiddling with the routing a little bit I was able to ping loopback interfaces between routers A and C and was able to verify complete traversal by checking the tunnel statistics and ipsec packet encaps and decaps. Success!

Had a lot of fun doing this one, never had to work with nested tunnels before so it was a great  experience.



Here is how it looked on the white board.

And now for the router configs.



-------------R1------------
Router(config)#do show run
Building configuration...

Current configuration : 1779 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
crypto isakmp key cisco address 10.10.50.2
!
!
crypto ipsec transform-set vpntransform esp-aes esp-sha-hmac
 mode transport
!
crypto ipsec profile vti-profile
 set transform-set vpntransform
!
!
!
!
!
interface Loopback0
 ip address 192.168.4.1 255.255.255.0
!
interface Tunnel0
 ip address 172.16.50.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 10.10.50.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile vti-profile
!
interface Tunnel1
 ip address 172.16.51.1 255.255.255.252
 tunnel source Tunnel0
 tunnel destination 172.16.50.2
!
interface Tunnel2
 ip address 172.16.52.1 255.255.255.252
 tunnel source Tunnel1
 tunnel destination 10.10.60.2
!
interface FastEthernet0/0
 ip address 10.10.50.1 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!        
ip forward-protocol nd
ip route 10.10.60.0 255.255.255.252 Tunnel1
ip route 192.168.6.0 255.255.255.0 Tunnel2
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!        
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
line vty 5 15
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
!
!
end






-------------R2------------
Router(config)#do show run
Building configuration...

Current configuration : 1549 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
crypto isakmp key cisco address 10.10.50.1
!
!
crypto ipsec transform-set vpntransform esp-aes esp-sha-hmac
 mode transport
!
crypto ipsec profile vti-profile
 set transform-set vpntransform
!
!
!
!
!
interface Loopback0
 ip address 192.168.5.1 255.255.255.0
!
interface Tunnel0
 ip address 172.16.50.2 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 10.10.50.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile vti-profile
!
interface Tunnel1
 ip address 172.16.51.2 255.255.255.252
 tunnel source Tunnel0
 tunnel destination 172.16.50.1
!
interface FastEthernet0/0
 ip address 10.10.50.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.10.60.1 255.255.255.252
 duplex auto
 speed auto
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!        
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
line vty 5 15
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
!
!
end





-------------R3------------
Router(config-if)#do show run
Building configuration...

Current configuration : 1177 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!        
!
interface Loopback0
 ip address 192.168.6.1 255.255.255.0
!
interface Tunnel2
 ip address 172.16.52.2 255.255.255.252
 tunnel source FastEthernet0/1
 tunnel destination 172.16.51.1
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.10.60.2 255.255.255.252
 duplex auto
 speed auto
!
ip forward-protocol nd
ip route 172.16.51.0 255.255.255.252 10.10.60.1
ip route 192.168.4.0 255.255.255.0 Tunnel2
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
line vty 5 15
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 no login
!
!
end

Why WEP Sucks

Before I go into the details on why WEP sucks its important to understand how it works. WEP was designed around the RC4 stream cypher and supports 64-bit or 128-bit keys. The first 24 bits of a WEP key is known as the initialization vector (IV) and is supposed to be a random and unique value for each packet. These IVs are then combined with the pre-shared key and fed into the RC4 algorithm to produce a pseudo-random stream or PRGA. WEP will then XOR the PRGA against a clear text packet and its integrity checksum to produce an encrypted packet.

Now here is where WEP starts to go down hill. Once the encrypted packet is generated the 24-bit IV that was used is then pre-pended to the encrypted packet in clear text before it’s sent to the destination. This means WEP only effectively provides 40 and 104 bits of protection.

If the IVs were never re-used it wouldn’t be nearly as big a problem. Now consider that the 24 bits used in an IV provides about 16.7 million possible combinations. This may sound like a lot but in reality the likelihood of having the same IV re-used is very high and is well illustrated by a situation known as the birthday paradox. On average it only takes about 5,000 packets to yield a 50% chance of seeing a collision; that is when two packets with the same IV are seen.

When two packets using the same pre-shared key have a colliding IV they will also share the same PRGA used to encrypt the packet. If the contents of a packet can be deduced or predicted then it becomes possible to XOR the known clear text against its encrypted form to reproduce the PRGA. Once the PRGA is known any further packets with a colliding IV can be decrypted. Although this doesn’t reveal the pre-shared key the ability to decrypt single packets is still a problem. That’s strike one.

WEP also has zero replay protection. What makes this one so bad is the normal authentication and challenge/response process used by WEP. When an AP sends a challenge to a client it is sent in clear text along with the IV. When received the client uses the provided IV and WEP key to encrypt the challenge and send it back to the AP. If the challenge/response is captured then we have a known packet and its encrypted counterpart. All you need to do is XOR the challenge with the response and you will reproduce the PRGA for packets with the same IV. This is especially bad because you can then  inject traffic into a network that will elicit predictable responses leading to more known IV and PRGA pairs. That’s strike two.

Now to bring it all home, this is the coup da grace on why WEP sucks. Nearly every single packet sent has a standard Ethernet header. The header always starts with 0xAA 0xAA and is at predictable location inside an encrypted packet. Knowing this you can use the encrypted packets and their known IVs to brute force keys that return 0xAA 0xAA at their expected locations. There is also a similar method that focuses on known parts of standard ARP request. When combined the ability to phish for encrypted packets and IVs with replaying and injection it becomes possible to break WEP outright in as little as 1 minute. That’s strike three.

If breaking the encryption wasn’t bad enough we also need to consider the fact that WEP uses a very poor check for data integrity. The integrity algorithm used by WEP is only CRC32; which was never designed for cryptographic security and can easily be spoofed. What’s even worse is WEP and CRC32 don’t roll in any security elements into its calculation so there is nothing to verify the data came from a legitimate source.

TLDR: If you care about security avoid WEP because it sucks and offers no real protection against intelligent and or targeted attacks.

ASA NAT Part 4 - Using Object NAT

In the diagram below we have three servers and a local network with some users that all need to get out to the Internet. The Web server and FTP server have to share the same public IP.

Step1: Make objects for both the outside and inside addresses that will be used.

ASA(config)# network network public-webftp

ASA(config-network-object)#  host 1.1.1.1

ASA(config)# network network public-appserv

ASA(config-network-object)#  host 1.1.1.2

ASA(config)# network network public-hidenat

ASA(config-network-object)#  host 1.1.1.3

ASA(config)# network network InsideLan

ASA(config-network-object)#  subnet 10.10.10.0 255.255.255.0
ASA(config)# network network server-web-http

ASA(config-network-object)#  host 10.10.10.5

ASA(config)# network network server-web-https

ASA(config-network-object)#  host 10.10.10.5

ASA(config)# network network server-ftp

ASA(config-network-object)#  host 10.10.10.6

ASA(config)# network network server-apps

ASA(config-network-object)#  host 10.10.10.7

Step2: Apply NAT to our inside objects.

ASA(config)# network network InsideLan

ASA(config-network-object)# nat (inside,outside) dynamic public-hidenat
ASA(config)# network network server-web-http

ASA(config-network-object)# nat (inside,outside) static public-webftp service tcp 80 80

ASA(config)# network network server-web-https

ASA(config-network-object)# nat (inside,outside) static public-webftp service tcp 443 443

ASA(config)# network network server-ftp

ASA(config-network-object)# nat (inside,outside) static public-webftp 21 21

ASA(config)# network network server-apps

ASA(config-network-object)# nat (inside,outside) static public-appserv

Step3: Make or modify the interface access-list to allow incoming traffic to the servers

ASA(config)# access-list outside-incoming extended permit tcp any object
server-web-http eq 80

ASA(config)# access-list outside-incoming extended permit tcp any object
server-web-https eq 443

ASA(config)# access-list outside-incoming extended permit tcp any object
server-ftp eq 21

ASA(config)# access-list outside-incoming extended permit tcp any object
server-apps eq 1234

ASA(config)# access-group outside-incoming in interface outside

If you prefer to use the ASDM here is a basic run down of how to add an Object NAT.

Step1: You can either add/edit an existing object using the toolbar on the right side or in the NAT configuration window you can add an Object NAT from the drop down Add menu.

Step2: Once the object window is shown click the little drop down arrow to access the NAT configuration section.

Step3. Check the Add Automatic Address Translation rules box.

Step4: Select if you wish to do a static, dynamic, or dynamic PAT and add your translated address or object. Once done filling out the type and translated address click the advanced button.

Step5: In this window you select your source and translated (destination) interfaces. If you want to do a Static 1 to 1 NAT you can leave the service section blank without port numbers. If you want to perform a PAT or port forward fill them out. The last thing on this window is the “Translate DNS replies for rule” option. This function only available if you want to do a Static 1 to 1 NAT (no port numbers filled out).