Trying to apply a crypto map to a tunnel Int. with PT (ver5.3.1.0044)

[Reprovoid]

Hi.I'm trying to configure GRE over IPSEC on Packet tracer but when I try to apply the crypto map to the tunnel Interface I get unrecognised command.

  Is this command not available In the version of packet tracer I'm using ?

[Richard Burts · Accepted solution]

In general the crypto map is configured on the physical interface and not on the tunnel. At least in recent versions of IOS that is the case. There are older versions of IOS where the crypto map is configured on both the tunnel and the physical interface. But I am guessing that the version of IOS you are using is fairly recent and only supports the crypto map on the physical interface and not on the tunnel.

Try configuring the crypto map on the physical interface and let us know what happens.

HTH

Rick

[edit] I phrased my answer in terms of IOS and see that your question is about packet tracer (which is an emulator). But I believe that the essence of my answer is still correct - the map goes on the physical interface and not on the tunnel.

[Reprovoid]

Hi.Thanks.

I can apply the crypto map to the physical Interface.The document I was reading to apply GRE over IPSec was probably quite old.

Can I then Just create the GRE tunnels and the access-list that allows GRE through the VPN and this will encrypt the GRE tunnel.

I already have the vpn working between 3 routers but the access-lists are for the lan side of the routers.If I change the access-list to a host to host that allows GRE protocols will that be enough ?

Thanks

[Richard Burts]

I have configured many site to site VPN tunnels with IPSec with GRE. I put the crypto map on the physical interface and the access list is a simple permit gre source host to destination host. This works quite well.

If you have configured a crypto map for the traditional IPSec tunnel, not with GRE, then the access list permits all the LAN addresses that will go through the tunnel. But the access list for the GRE/IPSec only needs to permt the GRE hosts.

HTH

Rick

[Reprovoid]

If It's not too much trouble can you take a look at the pt file.I've created a GRE tunnel between the limassol , dubai routers but no luck.

[Richard Burts]

I would be willing to look at configuration information. But unfortunately I do not have packet tracer software to read your file.

HTH

Rick

[Reprovoid]

Thank you.I appreciate It.

I've attached the configs for the two routers.

[Richard Burts · Accepted solution]

I have looked at the configs and as far as the crypto parts are concerned they look fine. The crypto maps seem to match as they should, source and destination addresses match as they should, the access list for crypto looks right.

I do not know what is in between these routers. Pretty obviously their serial interfaces do not connect to each other. So as long as there are appropriate networks between them and they have IP connectivity to each other then the GRE IPSec tunnels should work.

I do not see in these configs how they will learn the route to their peer's address. How will 2.0.0.1 learn the route to 4.0.0.5? And how will 4.0.0.5 learn the route to 2.0.0.1? But if they do learn these routes (without the tunnel up) and 2.0.0.1 can ping 4.0.0.5 and 4.0.0.5 can ping 2.0.0.1 then the tunnels and the crypto should work.

HTH

Rick

[Reprovoid]

Thanks for your help.I've basically put a router In the middle of the three vpn routers with static routes to eachother.The vpn was working without GRE but once I changed the access list It stopped.

I'll take a look again.At least It looks right to you so that's a step forward.

Thanks again.

[Richard Burts]

I would suggest that you start testing by trying to ping with source of 2.0.0.1 to destination 4.0.0.5 and by pinging with source 4.0.0.5 to destination 2.0.0.1.

I see that you are running router RIP over the serial interface. Is that how the routers learn the path to their peer address?

And thinking about routing leads me to notice that I do not see anything that will send traffic through your tunnels. That may be the reason why it stopped working when you configured the GRE tunnels. With just IPSec with crypto map on the physical interface and the crypto access list identifying the end stations it would work as the traffic went out the serial interface. But with the tunnels you need some routing mechanism (could be static routes could be some routing protocol) to send traffic through the tunnels.

As a side note - I see that you are doing no service timestamps. I am curious why you are doing this and would observe that log messages with timestamps and debug messages with timestamps can be very helpful when you are trying to troubleshoot issues on the router.

HTH

Rick

[Reprovoid]

I can ping from 2.0.0.1 to 4.0.0.5 and vice versa.Wouldn't RIP allow me to send traffic through the tunnels ?

As for not using service Timestamps that would be due to me being a noob!

Unfortunately packet tracer  has suddenly started crashing after using It for aroud 30 seconds.

  I'll hopefully get It working and see what I'm doing wrong with the routing protocol. Thanks!

[Richard Burts]

If you can ping that is a good start and makes it more likely that the crypto tunnels will work.

It is certainly possible to have RIP send traffic through the tunnels. But the configs that you posted are not doing that. And I will mention that you need to be careful about the routing protocol running over the tunnel. If you run a dynamic routing protocol over the tunnel and that routing protocol also advertises the source and destination addresses of the tunnel then it can produce an error condition of recursive routing. If you just add a network statement for 192.169.16.0 to your router rip then you would encounter this problem.

HTH

Rick

[Reprovoid]

Hi.I was reading this article about solutions to recursive routing http://fengnet.com/book/cisco.ios.cookbook.2nd/I_0596527225_CHP_12_SECT_4.html.  The second solution :

The second method simply excludes the tunnel's IP address range from the routing protocol. You can then run a different routing protocol for the addresses that you want to pass through the tunnel:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Tunnel1
Router1(config-if)#ip address 192.168.35.6 255.255.255.252
Router1(config-if)#tunnel source 172.25.1.5
Router1(config-if)#tunnel destination 172.22.1.2
Router1(config-if)#exit
Router1(config)#router eigrp 55
Router1(config-router)#network 172.22.0.0
Router1(config-router)#network 172.25.0.0
Router1(config-router)#end
Router1(config)#router rip
Router1(config-router)#network 192.168.35.0
Router1(config-router)#exit
Router1(config)#end
Router1#
 
 In this example I don't understand how 
 network 172.22.0.0 can be added to the 
 eigrp configuration If It doesn't belong 
 to any of the router's Interfaces.
 
  

[Richard Burts]

I looked at this link and it does illustrate one of the good ways to avoid the problem with recursive routing, which is to run one routing protocol on the tunnel interface address and to run a different routing protocol on the physical interfaces. Since the tunnel source address is 172.25.1.5 we know that the network statement for 172.25.0.0 will match and put that interface into the routing protocol. It is not clear to me whether the 172.22 network is also on some interface of this router. If it is then it would be valid to have that network statement under router eigrp. And you are right that if that network is not on this router then it would not be effective to have that network statement.

HTH

Rick

[Reprovoid]

Thanks again for all your help!