Today I was reviewing GRE tunnels and their interaction with IpSEC and I decided to create a very simple and small Lab in GNS3 to have a little bit of practice with it. At the end of the article you will find the Topology file for GNS3 so you can follow the steps showed in this post.
The goal is to have 2 branches exchanging Routing updates (we will use EIGRP) over a simulated WAN Link while all the traffic between the branches networks will be encrypted over the WAN using IpSec features. We will start with the configuration of IpSEC tunnels and we will continue with the configuration of the GRE tunnel. Of course all the interfaces were previously configured with IP addresses.
- IPSEC Configuration
We will start with the configuration of IPSEC on both routers. Let’s jump on the R1 command line and prepare the configuration:
R1#conf t
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 5
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#exit
R1(config)#crypto isakmp key mysharedkey address 192.168.0.2
R1(config)#crypto ipsec transform-set MY_SET esp-3des esp-sha-hmac
R1(cfg-crypto-trans)#exit
R1(config)#crypto map MY_MAP 1 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R1(config-crypto-map)#set transform-set MY_SET
R1(config-crypto-map)#set peer 192.168.0.2
R1(config-crypto-map)#match address 101
R1(config-crypto-map)#exit
R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 172.16.0.0 0.0.0.255
R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 172.17.0.0 0.0.0.255
R1(config)#access-list 101 permit ip 10.10.0.0 0.0.0.255 172.17.0.0 0.0.0.255
R1(config)#access-list 101 permit ip 10.10.0.0 0.0.0.255 172.16.0.0 0.0.0.255
With above commands we prepared a complete IPSEC configurations with both 2 phases and interesting traffic to put into the tunnel (the traffic mentioned in the access-list). If you are not familiar with this configurations it is better to stop here and review some articles abot IpSec.
It is now time to build the configuration for IpSec on router R2 to have it matching what we did on R1:
R2#conf t
R2(config)#crypto isakmp policy 1
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#group 5
R2(config-isakmp)#encryption 3des
R2(config-isakmp)#exit
R2(config)#crypto isakmp key mysharedkey address 192.168.0.1
R2(config)#crypto ipsec transform-set MY_SET esp-3des ah-sha-hmac
R2(cfg-crypto-trans)#exit
R2(config)#crypto map MY_MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R2(config-crypto-map)#set transform-set MY_SET
R2(config-crypto-map)#set peer 192.168.0.1
R2(config-crypto-map)#match address 101
R2(config-crypto-map)#exit
R2(config)#access-list 101 permit ip 172.16.0.0 0.0.0.255 10.0.0.0 0.0.0.255
R2(config)#access-list 101 permit ip 172.16.0.0 0.0.0.255 10.10.0.0 0.0.0.255
R2(config)#access-list 101 permit ip 172.17.0.0 0.0.0.255 10.10.0.0 0.0.0.255
R2(config)#access-list 101 permit ip 172.17.0.0 0.0.0.255 10.0.0.0 0.0.0.255
We are now ready to apply the configuration on the interfaces of the 2 routers that are on the WAN side (so on serials for our topology):
R1(config)#int s0/0
R1(config-if)#crypto map MY_MAP
R2(config)#int s0/0
R2(config-if)#crypto map MY_MAP
At this time we can try to check if the security association and IpSec tunnel will work between the routers. What we should do to achieve this goal? The answer is easy: we should generate some traffic that will match the “interesting traffic” (basically the traffic that will match the access-list 101 we created before). But think about that… will it work?
The answer is: NO! If we try to ping from one router to another using the loopback interfaces (that will match the interesting traffic of access-list) we will not have routes to reach the networks on both sites:
R1#ping 172.16.0.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
…..
Success rate is 0 percent (0/5)
R1#sh ip route 172.16.0.0
% Network not in table
The end result is that also the IpSec tunnel doesn’t come up because no interesting traffic is generated to have it starting:
R1#show crypto isakmp sa
dst src state conn-id slot status
R1#
What we can do now is to add some static routes or a default route on both routers or… we can directly configure the GRE tunnel and then run EIGRP within it to announce the routes between the routers. What will happen configuring the GRE tunnel will be indeed that we can have the routing protocol of our choice (I decided to use EIGRP but you can use whatever you need) running over the simulated WAN. Let’s go for it to check if it will work:
R1(config)#int tunnel 0
R1(config-if)#ip address 192.168.10.1 255.255.255.252
R1(config-if)#tunnel mode gre ip
R1(config-if)#tunnel source 192.168.0.1
R1(config-if)#tunnel destination 192.168.0.2
R2(config)#int tunnel 0
R2(config-if)#ip address 192.168.10.2 255.255.255.252
R2(config-if)#tunnel mode gre ip
R2(config-if)#tunnel source 192.168.0.2
R2(config-if)#tunnel destination 192.168.0.1
We can now check the tunnel interface status and reachability. We will do from router R2:
R2(config-if)#do sh int tu0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.10.2/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.0.2, destination 192.168.0.1
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:11, output 00:00:11, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
5 packets input, 620 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
5 packets output, 620 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
R2(config-if)#do ping 192.168.10.1 source tu0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/20/36 ms
Last step will be to configure EIGRP. We will configure it to have the tunnel interfaces establishing a neighborship and as a consequence we will be able to announce the routes between the 2 sites:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.10.0 0.0.0.3
R1(config-router)#network 10.0.0.0 0.0.0.255
R1(config-router)#network 10.10.0.0 0.0.0.255
R2(config)#router eigrp 1
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.10.0 0.0.0.3
R2(config-router)#network 172.16.0.0 0.0.0.255
R2(config-router)#network 172.17.0.0 0.0.0.255
Of course as soon as you add the network command for the tunnel interfaces you will get the EIGRP Neighborship. Moreover, thanks to the ther network commands you are now announcing the Loopbacks networks that they are now finally visibile in the routers routing tables:
R1#sh ip eigrp nei
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.10.2 Tu0 13 00:04:11 81 5000 0 3
R1#sh ip route
<..>
172.17.0.0/24 is subnetted, 1 subnets
D 172.17.0.0 [90/297372416] via 192.168.10.2, 00:04:13, Tunnel0
172.16.0.0/24 is subnetted, 1 subnets
D 172.16.0.0 [90/297372416] via 192.168.10.2, 00:04:13, Tunnel0
Thanks to this last configuration of EIGRP, we are now, finally, ready to have the traffic between the 2 sites running under IpSEC tunnel. In effect now the networks of each site should be reachable and as they are matching the crypto ACL we created during IpSec configuration, they will push the router to establish an encrypted connection to forward the traffic. To confirm what I am saying, let’s try again to ping from R1 Loopback 0 to R2 Loopback 0 and let’s then see if the IpSec security association will be established:
R1#ping 172.16.0.1 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/29/40 ms
R1#sh crypto isakmp sa
dst src state conn-id slot status
R1#
No Security association! What is wrong!?!? The answer is: the crypto ACL!! To understand why and what to do, we need to think about how and when the traffic will be encrypted. As we are asking to send the traffic via the GRE Tunnel, we will need to tell to IpSec that we want to have all the GRE traffic encrypted!! If we will not do that, the networks will be still pingable because we know the routes thanks to the eigrp updates, but we will not send the traffic encrypted! So, be careful!
Let’s then configure the ACL again on both sides of the tunnel:
R1(config)#no access-list 101
R1(config)#access-list 101 permit gre host 192.168.0.1 host 192.168.0.2
R2(config)#no access-list 101
R2(config)#access-list 101 permit gre host 192.168.0.2 host 192.168.0.1
Now, what will happen is that the securoty association will be immediately established and if we ping between the networks we will see the packet counters of the security session increase:
R1#ping 172.16.0.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
R1#show crypto isakmp sa
dst src state conn-id slot status
192.168.0.2 192.168.0.1 QM_IDLE 5 0 ACTIVE
R1#show crypto session detail
Crypto session current status
Code: C – IKE Configuration mode, D – Dead Peer Detection
K – Keepalives, N – NAT-traversal, X – IKE Extended Authentication
Interface: Serial0/0
Session status: UP-ACTIVE
Peer: 192.168.0.2 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 192.168.0.2
Desc: (none)
IKE SA: local 192.168.0.1/500 remote 192.168.0.2/500 Active
Capabilities:(none) connid:5 lifetime:23:34:44
IPSEC FLOW: permit 47 host 192.168.0.1 host 192.168.0.2
Active SAs: 2, origin: crypto map
Inbound: #pkts dec’ed 1351 drop 0 life (KB/Sec) 4590121/2126
Outbound: #pkts enc’ed 848 drop 36 life (KB/Sec) 4590207/2126
I hope that these notes I made will be useful when I will review this topic. Anyway, if you want to play with this easy topology, just download the GNS3 topology file here.