Prev

FreeBSD Handbook Chapter 14 Security

Next

14.10 VPN over IPsec

Written by Nik Clayton. Creating a VPN between two networks, separated by the Internet, using FreeBSD gateways.

14.10.1 Understanding IPsec

Written by Hiten M. Pandya. This section will guide you through the process of setting up IPsec. In order to set up IPsec, it is necessary that you are familiar with the concepts of building a custom kernel (see Chapter 8). IPsec is a protocol which sits on top of the Internet Protocol (IP) layer. It allows two or more hosts to communicate in a secure manner (hence the name). The FreeBSD IPsec network stack is based on the KAME implementation, which has support for both protocol families, IPv4 and IPv6. IPsec consists of two sub-protocols:

Encapsulated Security Payload (ESP), protects the IP packet data from third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, 3DES). Authentication Header (AH), protects the IP packet header from third party interference and spoofing, by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.

ESP and AH can either be used together or separately, depending on the environment. IPsec can either be used to directly encrypt the traffic between two hosts (known as Transport Mode); or to build virtual tunnels between two subnets, which could be used for secure communication between two corporate networks (known as Tunnel Mode). The latter is more commonly known as a Virtual Private Network (VPN). The ipsec(4) manual page should be consulted for detailed information on the IPsec subsystem in FreeBSD. To add IPsec support to your kernel, add the following options to your kernel configuration file:

options device

IPSEC crypto

#IP security

If IPsec debugging support is desired, the following kernel option should also be added:
options IPSEC_DEBUG #debug for IP security

14.10.2 The Problem

There is no standard for what constitutes a VPN. VPNs can be implemented using a number of different technologies, each of which have their own strengths and weaknesses. This section presents a scenario, and the strategies used for implementing a VPN for this scenario.

14.10.3 The Scenario: Two networks, one home based and one corporate based. Both are connected to the Internet, and expected, via this VPN to behave as one.
The premise is as follows:

You have at least two sites Both sites are using IP internally Both sites are connected to the Internet, through a gateway that is running FreeBSD. The gateway on each network has at least one public IP address. The internal addresses of the two networks can be public or private IP addresses, it does not matter. They just may not collide; e.g.: may not both use 192.168.1.x.

14.10.4 Configuring IPsec on FreeBSD

Written by Tom Rhodes. To begin, the security/ipsec-tools must be installed from the Ports Collection. This third party software package provides a number of applications which will help support the configuration. The next requirement is to create two gif(4) pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly. As root, run the following commands, replacing the internal and external items with the real internal and external gateways:
# ifconfig gif0 create # ifconfig gif0 internal1 internal2

# ifconfig gif0 tunnel external1 external2

For example, the corporate LAN's public IP is 172.16.5.4 having a private IP of 10.246.38.1. The home LAN's public IP is 192.168.1.12 with an internal private IP of 10.0.0.5. This may seem confusing, so review the following example output from the ifconfig(8) command:
Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4

Once complete, both private IPs should be reachable using the ping(8) command like the following output suggests:
priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms

As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses. Next, both gateways must be told how to route packets in order to correctly send traffic from either network. The following command will achieve this goal:

# # # #

corp-net# corp-net# priv-net# priv-net#

route route route route

add add add add

10.0.0.0 10.0.0.5 255.255.255.0 net 10.0.0.0: gateway 10.0.0.5 10.246.38.0 10.246.38.1 255.255.255.0 host 10.246.38.0: gateway 10.246.38.1

At this point, internal machines should be reachable from each gateway as well as from machines behind the gateways. This is easily determined from the following example:
corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms

Setting up the tunnels is the easy part. Configuring a secure link is a much more in depth process. The following configuration uses pre-shared (PSK) RSA keys. Aside from the IP addresses, both /usr/local/etc/racoon/racoon.conf files will be identical and look similar to
path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of preshared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer { # timing options. change as needed counter interval persend natt_keepalive 5; 20 sec; 1; 15 sec;

phase1 phase2 } listen { } remote {

30 sec; 15 sec;

# address [port] that racoon will listening on isakmp isakmp_natt 172.16.5.4 [500]; 172.16.5.4 [4500];

192.168.1.12 [500] exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; nat_traversal off; generate_policy off; proposal { encryption_algorithm hash_algorithm authentication_method lifetime time dh_group } blowfish; md5; pre_shared_key; 30 sec; 1;

} sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; }

Explaining every available option, along with those listed in these examples is beyond the scope of this document. There is plenty of relevant information in the racoon configuration manual page. The SPD policies need to be configured so FreeBSD and racoon is able to encrypt and decrypt network traffic between hosts. This task may be undertaken with a simple shell script similar to the following which is on the corporate gateway. This file will be used during system initialization and should be saved as /usr/local/etc/racoon/setkey.conf.

flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12172.16.5.4/use;

Once in place, racoon may be started on both gateways using the following command:
# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log

The output should be similar to the following:

corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]>172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]>192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]>172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]>192.168.1.12[0] spi=175852902(0xa7b4d66)

To ensure the tunnel is working properly, switch to another console and use tcpdump(1) to view network traffic using the following command. Replace em0 with the network interface card as required.
# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12

Data similar to the following should appear on the console. If not, there is an issue, and debugging the returned data will be required.
01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)

At this point, both networks should be available and seem to be part of the same network. Most likely both networks are protected by a firewall, as they should be. To allow traffic to

flow between them, rules need to be added to pass packets back and forth. For the ipfw(8) firewall, add the following lines to the firewall configuration file:
ipfw ipfw ipfw ipfw add add add add 00201 00202 00203 00204 allow allow allow allow log log log log esp from any to any ah from any to any ipencap from any to any udp from any 500 to any

Note: The rule numbers may need to be altered depending on the current host configuration. For users of pf(4) or ipf(8), the following rules should do the trick:
pass pass pass pass pass pass pass pass pass pass in quick proto esp from any to any in quick proto ah from any to any in quick proto ipencap from any to any in quick proto udp from any port = 500 to any port = 500 in quick on gif0 from any to any out quick proto esp from any to any out quick proto ah from any to any out quick proto ipencap from any to any out quick proto udp from any port = 500 to any port = 500 out quick on gif0 from any to any

Finally, to allow the machine to start support for the VPN during system initialization, add the following lines to /etc/rc.conf:
ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes"

UBUNTU
Style Cleanup Required: This article does not follow the style standards in the Wiki Guide. More info... Matthew Caron This howto is primarily taken from IPSec - Linux Kernel 2.6 using KAME-tools; the native IPSec stack in the 2.6 kernel series. This covers using manually-keyed connections, and is geared toward very small or primarily star toplogy networks (an NIS server and all it's clients, for example). Larger networks (if all the NIS clients want to talk to each other in an encrypted fashion) would benefit from the use of an automated keying agent, such as racoon. Discussion of such agents is outside the scope of this draft of this document (maybe later). 1. Install the tools:
sudo apt-get install ipsec-tools

2. Edit /etc/ipsec-tools.conf file. This file should be of the general form:

# Configuration for 192.168.1.100 # Flush the SAD and SPD flush; spdflush; # Attention: Use this keys only for testing purposes! # Generate your own keys! # AH SAs using 128 bit long keys add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6; add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; # ESP SAs using 192 bit long keys (168 + 24 parity) add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df; # Security policies spdadd 192.168.1.100 192.168.2.100 any -P out ipsec esp/transport//require ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P in ipsec esp/transport//require ah/transport//require;

It is important to understand this, so let me break it down:

# AH SAs using 128 bit long keys add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6; add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

This section lists the 128 bit keys for the 192.168.2.100 and 192.168.1.100 connection. Each IP pair has 2 keys - one for each direction (in and out). Each pair of machines needs to know the this information. So, this means that, for each pair of IP's, you need to generate a new key (hence why this works for small networks, but anything major probably wants a daemon to handle this. Maybe if I feel ambitious, I'll set mine up to use it and update this with that info). Also, note the number right after the 'ah' for each of these keys. This number needs to be unique for each 'add' statement. These keys are generated as follows:
dd if=/dev/random count=16 bs=1| xxd -ps

Don't forget to add the 0x in front of it. Similarly, this section:

# ESP SAs using 192 bit long keys (168 + 24 parity) add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

This works just like the AH keys, except that they are longer. Again, the number after 'esp' must be unique. These keys are generated as follows:
dd if=/dev/random count=24 bs=1| xxd -ps

Again, don't forget to add the 0x in front of it. So, these top two sections should list keys for all the IP addresses that the machine cares about. These sections do not change when moving the file amongst machines on either side of a connection. That brings us to the next section:
# Security policies spdadd 192.168.1.100 192.168.2.100 any -P out ipsec esp/transport//require ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P in ipsec esp/transport//require ah/transport//require;

This sets up the policies for in and out communications. So, the above version will work for 192.168.1.100, because all outgoing communication to 192.168.2.100 and all incoming communication from 192.168.2.100 will be encrypted. To use this on the other machine (192.168.2.100), flip the in and out directives, as follows:
# Security policies spdadd 192.168.1.100 192.168.2.100 any -P in ipsec esp/transport//require ah/transport//require; spdadd 192.168.2.100 192.168.1.100 any -P out ipsec esp/transport//require ah/transport//require;

3. Make the conf file not readable to the world:

sudo chmod 750 ipsec-tools.conf

Okay, do both sides of the connection have an ipsec-tools.conf? Everyone set? Good, now it gets easy. 4. It will be started at boot by default on systems, so you don't have to worry about that. 5. Also, starting it wouldn't hurt either (make sure to do this on both sides of the connection before trying to have them talk to each other; you could also reboot):
sudo /etc/init.d/setkey start

Mikrotik
Mikrotik RouterOS
If you are using ROS v3.x or above, be sure to check the end of this list to see a list of necessary mod. First should configure a Tunnel Interface:
/ interface ipip add name="Tunnel1" mtu=1480 local-address=10.10.1.100 remoteaddress=10.10.1.200 comment="" disabled=no

After that all interfaces are configured, than should asign IP addresses for interfaces:
/ ip address add address=10.10.1.100/24 network=10.10.1.0 broadcast=10.10.1.255 interface=WAN comment="" disabled=no add address=192.168.1.1/24 network=192.168.1.0 broadcast=192.168.1.255 interface=LAN comment="" disabled=no add address=172.16.0.1/30 network=172.16.0.0 broadcast=172.16.0.3 interface=Tunnel1 comment="" disabled=no

Enable Routing in Mikrotik Router, in this case RIP:

/ routing rip set redistribute-static=no redistribute-connected=no redistribute-ospf=no redistribute-bgp=no metric-static=1 \ metric-connected=1 metric-ospf=1 metric-bgp=1 update-timer=30s timeouttimer=3m garbage-timer=2m / routing rip interface add interface=Tunnel1 receive=v2 send=v2 authentication=none authentication-key="" prefix-list-in="" prefix-list-out="" / routing rip neighbor add address=172.16.0.2 / routing rip network add address=192.168.1.0/24 add address=172.16.0.0/30

In v3.x the bolded line will change on:

/ routing rip interface add interface=Tunnel1 receive=v2 send=v2 authentication=none authentication-key="" in-prefix-list="" out-prefix-list=""

IPSec setup, here should be defined the ipsec policy, peer and proposal. Make sure that policy should not have enabled option tunnel, in this case tunel should be set to NO, because it will be used the transport mode of IPSec not the tunnel mode:
/ ip ipsec proposal add name="IPSec" auth-algorithms=md5 enc-algorithms=3des lifetime=30m lifebytes=0 pfs-group=modp1024 disabled=no / ip ipsec peer add address=10.10.1.200 secret="ipsec" generate-policy=no exchangemode=main send-initial-contact=yes \ proposal-check=obey hash-algorithm=md5 enc-algorithm=3des dhgroup=modp1024 lifetime=1d lifebytes=0 disabled=no / ip ipsec policy add src-address=10.10.1.100/32:any dst-address=10.10.1.200/32:any protocol=all action=encrypt level=require \ ipsec-protocols=esp tunnel=no sa-src-address=10.10.1.100 sa-dstaddress=10.10.1.200 \ proposal=IPSec manual-sa=none dont-fragment=clear disabled=no

In v3.x the bolded line will change on:

/ ip ipsec proposal add name="IPSec" auth-algorithms=md5 enc-algorithms=3des lifetime=30m pfsgroup=modp1024 disabled=no / ip ipsec peer add address=10.10.1.200/32:500 secret="ipsec" generate-policy=no exchangemode=main send-initial-contact=yes \ proposal-check=obey hash-algorithm=md5 enc-algorithm=3des dhgroup=modp1024 lifetime=1d lifebytes=0 disabled=no / ip ipsec policy add src-address=10.10.1.100/32:any dst-address=10.10.1.200/32:any protocol=all action=encrypt level=require \ ipsec-protocols=esp tunnel=no sa-src-address=10.10.1.100 sa-dstaddress=10.10.1.200 \ proposal=IPSec manual-sa=none disabled=no

Cisco IOS
Cisco Interfaces and addresses:
FastEthernet 0/0 description *** WAN *** ip address 10.10.1.200 255.255.255.0 crypto map vpn FastEthernet 0/1 description *** LAN *** ip address 192.168.2.1 255.255.255.0

Cisco Tunnel Interface:

interface Tunnel1 description **Cisco Peer** ip address 172.16.0.2 255.255.255.252

no ip redirects no ip unreachables no ip proxy-arp ip mtu 1480 ip rip v2-broadcast ip tcp adjust-mss 1400 load-interval 30 tunnel source 10.10.1.200 tunnel destination 10.10.1.100 tunnel mode ipip hold-queue 1024 in hold-queue 1024 out

Routing in Cisco:
router rip version 2 timers basic 30 60 90 90 redistribute connected metric 1 route-map connected-to-rip redistribute static metric 5 route-map static-to-rip network 172.16.0.2 network 192.168.2.0 distribute-list prefix LAN out no auto-summary

Setup the prefix-list to match the Local subnet:

ip prefix-list LAN seq 10 permit 192.168.2.0/24

Setup route-maps to match interfaces to be advertised by RIP:

route-map connected-to-rip permit 10 match interface FastEthernet0/0 ! route-map static-to-rip permit 10 match ip address prefix-list LAN

IPSec and Crypto setup in Cisco, also here trasnport mode of IPSec should be setup:
! crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key ipsec address 0.0.0.0 0.0.0.0 crypto ipsec security-association idle-time 600 crypto ipsec transform-set vpn esp-3des esp-md5-hmac mode transport ! crypto map vpn 1 ipsec-isakmp

! ! !

description **To Mikrotik Peer** set peer 10.10.1.100 set transform-set vpn set pfs group2 match address mikrotik_peer

Setup access-list to match the IPSec peer:

ip access-list extended mikrotik_peer permit ipinip host 10.10.1.200 host 10.10.1.100

Type this in "enable" mode to view your routing table (after succesfull RIP update):
sh ip route

or
sh ip rip database

This example can be implemented also with another routing protocol like OSPF, and also very simply we can setup here a failover connection. Regarding the failover, the setup is very easy, all that we need is to create another set of tunnels via another ISP or gateway, but again the remote peer is the same router. Instead of the routing protocol for the second set of tunnels, it needs static routes to be configured, only that the static routes should have higher distance than the dynamic protocol. The idea is that, when the primary link will go down (dynamic routing distance=120) than the backup link becomes active (static routes distance=200), as soon as the primary link will come up, it will put the failover link in inactive mode

Cisco IOS VPN Configuration

Scenario 1: Gateway-to-gateway with preshared secrets The following is a typical gateway-to-gateway VPN that uses a preshared secret for authentication. 10.5.6.0/24 172.23.9.0/24 | | --| |-| +-----------+ /-^-^-^-^--\ +-----------+ | |-----| Gateway A |=====| Internet |=====| Gateway B |-----| | AL+-----------+AW \--v-v-v-v-/ BW+-----------+BL | --| 10.5.6.1 14.15.16.17 22.23.24.25 172.23.9.1 |-| | Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface has the address 14.15.16.17. Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN interface address, 172.23.9.1, can be used for testing IPsec but is not needed for configuring Gateway A. The IKE Phase 1 parameters used in Scenario 1 are: * * * * * * Main mode TripleDES SHA-1 MODP group 2 (1024 bits) pre-shared secret of "hr5xb84l6aa9r6" SA lifetime of 28800 seconds (eight hours) with no kbytes rekeying

The IKE Phase 2 parameters used in Scenario 1 are: * * * * * * * TripleDES SHA-1 ESP tunnel mode MODP group 2 (1024 bits) Perfect forward secrecy for rekeying SA lifetime of 3600 seconds (one hour) with no kbytes rekeying Selectors for all IP protocols, all ports, between 10.5.6.0/24 and 172.23.9.0/24, using IPv4 subnets

To set up Gateway A for this scenario, use the following steps: Cisco IOS includes IPSec support, beginning with early versions of IOS Version 12; however the commands have changed during the evolution of IOS Version 12 point releases. The following example uses the current release version, Cisco IOS Version 12.2(8)T4.

This example uses a Cisco 1700 series router, which has one ethernet port and one serial port. The ethernet port, FastEthernet0, will be the outside, or Internet-facing interface. The serial port, Serial0, will be the inside interface. (This is just an example. Your interfaces may be different.) All configuration changes are volatile, and immediate, until the "write" command is executed, when the configuration is saved to flash and will be reloaded after a reboot. At any time, you may examine the running configuration with the command "show running-configuration", or view the saved configuration with the command "show config". Most commands can be abbreviated. Use a ? at the prompt or in a command to see options. Configure IP on the interfaces: Router# config term Enter configuration commands, one per line. End with CNTL/Z. Router(config)# int fa0 Router(config-if)# ip address 14.15.16.17 255.255.255.0 Router(config-if)# speed auto Router(config-if)# ^Z Router# config term Enter configuration commands, one per line. End with CNTL/Z. Router(config)# int ser0 Router(config-if)# ip address 10.5.6.1 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# ^Z Router# Define the default route: Router# config term Router(config)# ip route 0.0.0.0 0.0.0.0 14.15.16.1 Router(config)# exit Cisco supports only one IKE policy per router, so you must design one which is acceptable to all systems you are going to interoperate with. Assign it an ordering number of 5. If you wanted to have more than one proposal in the policy, the proposals would be given in order defined by this policy order number. Configure the IKE Policy: Router# config term Router(config)# crypto Router(config-isakmp)# Router(config-isakmp)# Router(config-isakmp)# Router(config-isakmp)# Router(config-isakmp)# Router(config-isakmp)# isakmp policy 5 encryption 3des group 2 hash sha lifetime 28800 authentication pre-share exit

Since multiple peers will share the same IKE policy, you must match each peer with its pre-shared secret: Router# config term Router(config)# crypto isakmp key hr5xb84l6aa9r6 address 22.23.24.25 Router(config-isakmp)# exit

The IPSEC transform will be combined later with the rest of the IPSEC policy in a crypto map command. In this command, "STRONG" is just a label. Labels are CASE-SENSITIVE. Define the IPSEC transform: Router# config term Router(config)# crypto ipsec transform-set STRONG esp-3des esp-sha-hmac Router(config-isakmp)# exit Cisco IOS uses access lists for SPD entries. Many features of access lists (.e.g. TCP flag checking) don't work in IPSEC. This kind of access list MUST be labelled with a 3-digit number. The netmask in Cisco access lists are inverted. Nobody knows why, they just are. This list says "all traffic from 10.5.6.0/24 to 172.23.9.0/24, all ports, all IP protocols". Create the IPSEC access list: Router# config term Enter configuration commands, one per line. End with CNTL/Z. Router(config)# access-list 101 permit ip 10.5.6.0 0.0.0.255 172.23.9.0 0.0.0.255 Router(config)# ip route 0.0.0.0 0.0.0.0 14.15.16.1 Router(config)# exit Because IOS is a router first and an IPSEC gateway second, we have to tell IOS which interface to send packets on if the default route is not enough. In this scenario we don't need it, but in other situations you might need to define a route for the remote protected network: Router# config term Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip route 172.23.9.0 255.255.255.0 14.15.16.17 Router(config)# exit A crypto map binds all the assorted crypto parameters with a specific remote gateway. Several crypto maps bound to different remote gateways can be grouped together in one crypto map SET which is then bound to an outgoing interface. The number following the crypto map set name is the ordering of the map in the set. Bind the policy together with a crypto map, and give it the label CISCO: Router# config term Router(config)# crypto map CISCO 10 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. Router(config-crypto-map)# set security-association life seconds 3600 Router(config-crypto-map)# set transform-set STRONG Router(config-crypto-map)# set pfs group2 Router(config-crypto-map)# set peer 22.23.24.25 Router(config-crypto-map)# match address 101 Router(config-crypto-map)# exit Because Ciscos could have many interfaces, you have to bind the SPD to the outgoing interface: Router# config term Router(config)# interface fa0 Router(config-if)# crypto map CISCO

Router(config-if)# ^Z If you had multiple tunnels to multiple gateways, you would need to create a different access list for each tunnel, add an isakmp key entry for each gateway, and possibly create a different ipsec transform if your security policy is different. For example, let's say you have another remote peer at 23.23.24.25, for which you have created access-list 102. You could then add a crypto map to the set created above: Router# config term Router(config)# crypto map CISCO 20 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. Router(config-crypto-map)# set security-association life seconds 3600 Router(config-crypto-map)# set transform-set STRONG Router(config-crypto-map)# set pfs group2 Router(config-crypto-map)# set peer 23.23.24.25 Router(config-crypto-map)# match address 102 Router(config-crypto-map)# exit Now the outgoing interface FastEthernet0 has both crypto maps, and it will compare traffic to each map in order to determine if the traffic requires encryption. Save the configuration: Router# write Building configuration... [OK] Here is the completed IPSEC part of the Cisco configuration: Router# show config ! crypto isakmp policy 5 encr 3des authentication pre-share group 2 lifetime 28800 crypto isakmp key hr5xb84l6aa9r6 address 22.23.24.25 ! crypto ipsec transform-set strong esp-3des esp-sha-hmac ! crypto map CISCO 101 ipsec-isakmp set peer 22.23.24.25 set transform-set STRONG set pfs group2 match address 101 ! interface FastEthernet0 ip address 14.15.16.17 255.255.255.0 speed auto crypto map CISCO ! interface Serial0 ip address 10.5.6.1 255.255.255.0 !

access-list 101 permit ip 10.5.6.0 0.0.0.255 172.23.9.0 0.0.0.255 ! Now, bring up a tunnel! The IOS ping command extensions will allow you to select the source interface, and hence IP address, of the ping: Router# ping Protocol [ip]: Target IP address: 172.23.9.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: serial0 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.23.9.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Hmmmm ... what could be wrong? Router# show ip int brief Interface Protocol FastEthernet0 Serial0 down Let's check some basics: OK? Method Status YES manual up YES manual down up

IP-Address 14.15.16.17 10.5.6.1

Ah, the serial interface is down. I have to actually connect it up to something to bring the interface up. Now, the ping works and brings up the SAs. Show the SAs with these commands: Router# show crypto isakmp sa dst src 14.15.16.17 22.23.24.25 Router# show crypto ipsec sa interface: FastEthernet0 Crypto map tag: CISCO, local addr. 14.15.16.17 local ident (addr/mask/prot/port): remote ident (addr/mask/prot/port): current_peer: 22.23.24.25 PERMIT, flags={origin_is_acl,} # pkts encaps: 12, # pkts encrypt: # pkts decaps: 23, # pkts decrypt: (10.5.6.0/255.255.255.0/0/0) (172.23.9.0/255.255.255.0/0/0) 12, # pkts digest 12 23, # pkts verify 23 state QM_IDLE conn-id 1 slot 0

# pkts compressed: 0, # pkts decompressed: 0 # pkts not compressed: 0, # pkts compr. failed: 0, # pkts decompress failed: 0 # send errors 0, # recv errors 0 local crypto endpt.: 14.15.16.17, remote crypto endpt.: 22.23.24.25 path mtu 1500, media mtu 1500 current outbound spi: 3C39A800 inbound esp sas: spi: 0xD7228E4B(3609366091) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: CISCO sa timing: remaining key lifetime (k/sec): (4607999/3574) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x3C39A800(1010411520) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: CISCO sa timing: remaining key lifetime (k/sec): (4607999/3574) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: The easiest way to clear SAs from a Cisco IOS system varies with version, but one of these two will generally work: RouterRouter# clear crypto isakmp RouterRouter# clear crypto sa To enable debugging in IOS, you must turn on the debug as well as turn on the debug monitor, which is normally the terminal you are logged in on: Router# debug crypto verbose Router# debug crypto isakmp Router# term monitor To disable debugging: Router# nodebug all Router# term no monitor