VPN Question

[Tony Daniels]

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.

[rvarelac · Accepted solution]

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- 

[Tony Daniels]

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