Traditionally, an end-entity that participates in IKE receives a single ID certificate from a CA. The same CA or another CA issues an ID certificate to the peer IKE device. As long as a mutual trust exists between the IKE devices and the CAs, a successful IKE authentication occurs.
An end-entity can receive two certificates from a single CA or from two different CAs, and each of these certificates is used for a unique purpose, such as authentication of two different IKE sessions. The current configuration mechanism fails to provide the required outcome.
The chain validation between multiple subordinate CAs in different Virtual Routing and Forwarding (VRF) tables that lead to a single root-CA also contribute to the complication.
For these reasons, behavior changes have been incorporated into the Cisco IOS in order to make the use of multi-tier PKI hierarchy in IKEv1 feasible.
The two new enhancements include:
Could you please provide more details on the type of VPN you're running so I can assist you with the sample configuration.
Please share helpful posts
can we establish gre tunnel or vpn between these two LAN i.e 192.168.1.0 and 192.168.2.0 followed by public ip
if its possible then
1 how we can make connectivity between these LAN because there is isp involved and isp just do static ip
2 please provide me the steps to make reach ability i mean 192.168.1.1 can ping to 192.168.2.1 passing throughout isp.
3 I have already configured NAT,DHCP,Default route and redistribute default route in to eigrp.
4 but these can reach me to 188.8.131.52 network and forward of this cannot succes.
We may need to check hop by hop where exactly are the packets being dropped.
Could you share the output of the traceroute command from the source to the destination?
This seems simply a config issue. We may need to ensure proper destination routing is configured on all the intermediate devices or they must be in a state to forward those packets.
If that does not work try taking packet captures on the devices as well. This would help you to understand if the packets are even hitting the ingress interface of that device.
There are no major changes except the packet is subjected to crypto engine checks.
If the crypto engine is able to encrypt/decrypt the traffic (depending on the rules) it will forward the packet for normal checks (like L4/L3 checks) but first the packet has to be decrypted to find the actual payload/packet.