Lan2Lan problem

Answered Question
Jul 11th, 2008

Hello everybody!!!

I'm test just now, in a lab enviromment, a simple solution to join 2 networks at diferent location. There are in this lab 2 cisco 1841 with C1841-ADVSECURITYK9-M both. I'm not so good when subject is VPN, I configure the both routers and does not work. Now I don't know how to start a debug to help me.

I did the command "sh crypto session detail" and the session is down.

Someone can help me on this issue.

See the att below.

Thanks.

I have this problem too.
0 votes
Correct Answer by michael.leblanc about 8 years 4 months ago

Didn't recognize any issues with your configuration.

Have you generated any traffic to bring the tunnel up?

Your crypto ACLs:

Router A:

access-list 150 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

Router B:

access-list 150 permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255

... define the traffic that is to be forwarded to the crypto engine.

If you don't generate traffic requiring protection, the two tunnel endpoints won't commence negotiation of an ISAKMP SA (used as a secure channel to negotiate IPSec SAs).

Ping a host on the far side network, and see if tunnel negotiation commences.

Noticed an unimplemented NAT ACL. If you later decide to implement NAT, be sure to exempt the traffic requiring crypto protection, from the NAT process.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
a.alekseev Fri, 07/11/2008 - 12:27

try send traffic from 192.168.0.0/24 to 192.168.1.0/24

sh crypto isakmp sa

sh crypto ipsec sa

Correct Answer
michael.leblanc Fri, 07/11/2008 - 12:35

Didn't recognize any issues with your configuration.

Have you generated any traffic to bring the tunnel up?

Your crypto ACLs:

Router A:

access-list 150 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

Router B:

access-list 150 permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255

... define the traffic that is to be forwarded to the crypto engine.

If you don't generate traffic requiring protection, the two tunnel endpoints won't commence negotiation of an ISAKMP SA (used as a secure channel to negotiate IPSec SAs).

Ping a host on the far side network, and see if tunnel negotiation commences.

Noticed an unimplemented NAT ACL. If you later decide to implement NAT, be sure to exempt the traffic requiring crypto protection, from the NAT process.

tarik.cisco Fri, 07/11/2008 - 12:54

Damm, I'm so stupid, the session doesn't up because there are no host on LAN ports opn both routers, after connect to LAN the VPN works.

Thanks Very Much for all.

Thanks again for the experts always on line

michael.leblanc Fri, 07/11/2008 - 13:27

In future lab scenarios, you could bring up and maintain the tunnel by synchronizing the clock of one router with that of the other using the Network Time Protocol.

i.e.:

- configure a loopback interface as the "NTP source interface" on each device.

- include the traffic between the two loopback interfaces in your crypto acl.

- configure Router-A as the NTP Server with which Router-B is to synchronize its clock.

Actions

This Discussion