This topic poped up in my mind when I was writing the article ‘A Good Document Helps You Build Site2Site VPN’. Looking back in my personal VPN toubleshooting history, the case I am going to talk is listed on top of the reasons that cause site to site VPN not to work.
The most common senario is that the phase 1 (IKE) negotiatation succeeds, but somehow the phase 2 (IPSec) just refuses to work despite you 100% ensure you use the right encryption method, Hash algorithm.
If that is the case, you should confirm that whether you 100% matched the Internal IP address in your settings. OK, let me take the followin as a example:
Company A and B are going to build up a site to site VPN, which allows the following subnets to access to each other.
A side internal IP address: 192.168.1.0/24
B side internal IP address: 172.29.1.0/28
Here is a piece of configurations the network admin did on each side.
The VPN interesting traffic ACL settings On A firewall:
access-list A2B extended permit ip 192.168.1.0 255.255.255.0 172.29.1.0 255.255.255.0
The VPN interesting traffic ACL settings On B firewall:
access-list B2A extended permit ip 172.29.1.0 255.255.255.240 192.168.1.0 255.255.255.0
Did you find any problems above?
The problem is that the A company’s network admin configured ‘access-list A2B extended permit ip 192.168.1.0 255.255.255.0 172.29.1.0 255.255.255.0’ . He used the whole class C subnet. Even you may say that 172.29.1.0/24 covers 172.29.1.0/28, but this should not be allowed. I have seen many many times that it blocks the phase 2 to be built up.
Jackie Chen's IT Workshop 