A bit of a break from programming because i have oodles of work.
One of the main tasks where I work is creating and changing VPN tunnels with other companies so I normally feel pretty confident that I can set up a tunnel in a few minutes. However, recently I came across an interesting case where ikev1 and ikev2 behaved differently (presenting different show outputs) if the same error was present in the vpn config. Unfortunately, i started with ikev2 which showed a bizarre output so I wrongly assumed a bug and spent hours and hours trying to find the problem.
Let’s say we have multiple crypto map tunnels from the hub R1 to R2,R3, R4 with the crypto map entries in the following order:
crypto map MYMAP 12 ipsec isakmp
crypto acl R1>R2
permit ip 192.168.0.0 0.0.0.255 10.0.0.0 0.0.255.255
ip route 10.0.1.0 255.255.255.0 <R2 peer IP>
crypto map MYMAP 13 ipsec isakmp
crypto acl R1>R3
permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255
crypto map MYMAP 14 ipsec isakmp
crypto acl R1>R4
permit ip 192.168.0.0 0.0.0.255 10.0.100.0 0.0.0.255
permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
ip route 10.0.100.0 255.255.255.0 <R4 peer IP>
If you have a lot of experience with vpn’s, you might have already spotted the problem. R4’s subnet is a subset of R2’s subnet so there will be a problem and it’s easy to see if you have 4 tunnels, but a bit more difficult if you have hundreds of tunnels.
Now a series of interesting things will happen: R1>R2 will be fine, same as R1>R3. In case of R1>R4, let’s additionally assume that in case of the first SA, the application on the side of R4 will try initiate a connection to the side of R1, but in case of the second SA, the application on R1 side will initiate a connection to R4. What will happen now?
In case of ikev1: second SA will form just fine, but the first SA will fail with error ‚Peer not found’ on R1, and Phase 2 mismatch on R4 because R4 will receive 10.0.0.0 proxy from R1 instead of 10.0.100.0. This is despite the fact that routing in both cases is fine (only routes to /24 networks are present through peers). This is because routing is secondary to ISAKMP and IPSEC negotiations.
In case of ikev2: both SAs will form (!) and you will see (crypto session remote <ip of r4> details) that packets from 10.0.100.0 are decrypted, but then these packets will disappear in the bitbucket.
I can’t tell you how much time I spent looking up the significance of error ”peer not found”. What it means basically is that when a peer router sends us phase 2 policies (proxies), the match is found for a different peer (higher in crypto map hierarchy).
I will try to lab this up this week.