07-17-2015 08:03 AM
I understand that when creating a vpn tunnel between a static peer and a dynamic peer, the tunnel must be initiated from the remote. The remote is the only side that knows the other peer's IP address. That makes sense.
What I am not sure I understand is, once the tunnel is fully established, shouldn't the static peer be able to initiate traffic to the remote dynamic peer via crypto session's that are currently down?
Cisco ASA (Static IP) <----VPN---> Cisco Router (Dynamic IP)
Example: Remote Cisco router (Dynanic Side)
#show crypto session
Crypto session current status
Interface: FastEthernet0
Session status: DOWN
Peer: 207.201.237.5 port 500
IPSEC FLOW: permit ip 10.63.0.0/255.255.255.0 172.21.0.0/255.255.0.0
Active SAs: 0, origin: crypto map
IPSEC FLOW: permit ip host 10.157.1.1 192.168.1.0/255.255.255.0
Active SAs: 0, origin: crypto map
IPSEC FLOW: permit ip host 10.157.1.1 10.129.0.0/255.255.0.0
Active SAs: 0, origin: crypto map
IPSEC FLOW: permit ip host 10.157.1.1 172.21.0.0/255.255.0.0
Active SAs: 0, origin: crypto map
Interface: FastEthernet0
Session status: UP-ACTIVE
Peer: 207.201.237.5 port 4500
IKE SA: local 10.129.121.180/4500 remote 207.201.237.5/4500 Active
IPSEC FLOW: permit ip 10.63.0.0/255.255.255.0 192.168.1.0/255.255.255.0
Active SAs: 2, origin: crypto map
IPSEC FLOW: permit ip 10.63.0.0/255.255.255.0 10.129.0.0/255.255.0.0
Active SAs: 2, origin: crypto map
Should I not be able to initiate a ping (initiate traffic) from the HQ (Static peer) to the Remote (Dynamic Peer) and the crypto session will come "up"?
Host (10.129.105.100) ping to 10.157.1.1: fails
This is a scenario I am facing at this point.
Once I ping FROM the remote L0 interface (10.157.1.1/32) to 10.129.105.100 and it succeeds, THEN I am able to ping back from Host (10.129.105.100) to 10.157.1.1: SUCCESS
So any traffic ONLY works if it's initiated from the remote (dynamic) peer.
Solved! Go to Solution.
07-17-2015 09:41 AM
Hi Tony ,
You are correct , the traffic can be only initiated from the remote site.
The traffic can be initiated bidirectional , once the SA has been created , you can check this with the command "show crypto ipsec sa peer x.x.x.x"
This will depend as well of your ACL configuration , for example if we have the following ACL for the crypto config.
192.168.10.0/24---remote------ISP----HQ------192.168.20.0/24
access-list vpn permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
If a ping is triggered from the remote site , it will bring up the SA for the whole network , after that any host on the 10.0 will be able to communicate with 20.0 and viceversa.
However if we have the following ACL
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.5
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.10
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.15
Every SA must be triggered by the remote site , meaning the remote site needs to send a ping to 20.5 , 20.10 and 20.15 in order to enable bidirectional communication.
Hope it helps
-randy-
07-17-2015 09:41 AM
Hi Tony ,
You are correct , the traffic can be only initiated from the remote site.
The traffic can be initiated bidirectional , once the SA has been created , you can check this with the command "show crypto ipsec sa peer x.x.x.x"
This will depend as well of your ACL configuration , for example if we have the following ACL for the crypto config.
192.168.10.0/24---remote------ISP----HQ------192.168.20.0/24
access-list vpn permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
If a ping is triggered from the remote site , it will bring up the SA for the whole network , after that any host on the 10.0 will be able to communicate with 20.0 and viceversa.
However if we have the following ACL
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.5
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.10
access-list vpn permit ip 192.168.10.0 255.255.255.0 host 192.168.20.15
Every SA must be triggered by the remote site , meaning the remote site needs to send a ping to 20.5 , 20.10 and 20.15 in order to enable bidirectional communication.
Hope it helps
-randy-
07-17-2015 11:11 AM
Randy,
A quick follow-up question. If I wanted to manage this remote node, what is the best way to do so?
Obviously I would like to Monitor this node via a L0 (Management IP), but this can't happen because nothing would be initiating this traffic from the L0 to my management box first.
I've looked and am not having any luck finding a solution to this situation.
Tony
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide