pppoe connection between two sites but no tunnel establish.

[jomo frank]

Hello Expert,

I have a hub router an three spoke connct together using ppoe connections.

I am  to [ping all the wan interfaces of my remote (spokes) from the hub , but i am unable to establlish a tunnel between

the hub and repte site.

I went thru the configuration of both hub and spoke compraing key and access list etc.

I include the hub and spoke for your guidance.

Regards

---

[Georg Pauwen]

Hello,

I recreated your setup in GNS3, tunnel comes up. Try and use a diffferent crypto map for each tunnel instead of the same one:

Spoke

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp key 67B3CE5B40CB409D34230D32B561B37604B01C685B01B054 address 101.149.149.128
crypto isakmp keepalive 60 periodic
!
crypto ipsec transform-set manbosvpn esp-3des esp-sha-hmac comp-lzs
mode tunnel
!
crypto map SDM_CMAP_13 1 ipsec-isakmp
description Tunnel to101.149.149.128
set peer 101.149.149.128
set transform-set manbosvpn
match address 103
!
interface Tunnel2
ip address 192.168.19.12 255.255.255.0
ip mtu 1372
tunnel source Dialer0
tunnel destination 101.149.149.128
tunnel path-mtu-discovery
crypto map SDM_CMAP_13

------------

Hub

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp key 67B3CE5B40CB409D34230D32B561B37604B01C685B01B054 address 101.149.149.55
!
crypto ipsec transform-set manbosvpn esp-3des esp-sha-hmac comp-lzs
mode tunnel
!
crypto map SDM_CMAP_13 1 ipsec-isakmp
description Tunnel to101.149.149.55
set peer 101.149.149.55
set transform-set manbosvpn
match address 102
!
interface Tunnel2
description Tunnel to Amazonia_Mall
ip address 192.168.19.10 255.255.255.0
ip mtu 1372
tunnel source Dialer0
tunnel destination 101.149.149.55
tunnel path-mtu-discovery
crypto map SDM_CMAP_13
!

[jomo frank]

Hello Georg,

Thanks for the response I will use a different crypto map for each tunnel and retry
A quick question will the same crypto map on each tunnel be responsible for the tunnels failing to establish between the hub and spoke.

Regards

[Georg Pauwen]

I don't know if the shared crypto map causes the tunnel to fail. I used a separate crypto map for each tunnel and it worked. Give it a try...

[jomo frank]

Hello Georg,

I will try and provide a feedback upon completion .

Regards

[jomo frank]

Hello Georg,

I tried using different crypto map but the vpn tunnel between the two site still not establishing.
Do we have to do any natting on the dialer interface ?
Regards

[a.alekseev]

what is not working. could you be more specific?

[jomo frank]

Hello alekseev,
IF i do show ip route eigrp there is routing relating to 192.168.19.0 network, hence I conclude the tunnel is not establish and pass traffic.

Regards

[Georg Pauwen]

Hello,

is this a lab setup or a real, live network ?

[Richard Burts]

A separate crypto map for each tunnel is an interesting suggestion. But since all tunnels use the same single dialer interface and the crypto map is specified on the dialer interface I do not see how separate crypto maps could work.

Since the crypto map is specified on the dialer interface I wonder why the crypto map is also specified on the tunnel interfaces. When I began using site to site vpn tunnels (a long time ago) we needed to specify the crypto map on both the physical and the tunnel interfaces. But IOS changed and then needed the crypto map only on the physical interface. Is there something about this router code that needs the crypto map in both places? I suggest removing the crypto map from the tunnel interfaces and see if it makes any difference.

It is not clear to me whether the issue is with the crypto or whether the issue might be with the pppoe. Could you remove the crypto map and see if the tunnels come up then?

HTH

Rick

[jomo frank]

Hello Richard,

I will try removing the crypto map on the tunnel and retry.

Regards

[Richard Burts]

Please do let us know what you find.

If you are basing your status that the tunnels are not working based on what you see in the routing table then I have a suggestion: use the commands show crypto isakmp sa and show crypto ipsec sa and post the output. These are much more accurate in determining the status of the tunnels.

HTH

Rick

[jomo frank]

Hello Rick,
Will execute the two commands and post results .
A quick question do I need to use ip nat outside ip virtual-reassebly on the dilaer interface?
Regards

[jomo frank]

Hello Rick,
Please find below results of the two command you requested to run.
User Access Verification


Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.149.149.55 10.149.149.128 MM_NO_STATE 2620 ACTIVE (deleted)
10.149.149.128 10.149.149.55 QM_IDLE 2621 ACTIVE

IPv6 Crypto ISAKMP SA

Router#show crypto ipsec sa

interface: Tunnel0
Crypto map tag: SDM_CMAP_1, local addr 192.168.19.10

protected vrf: (none)
local ident (addr/mask/prot/port): (10.149.149.128/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.149.149.55/255.255.255.255/47/0)
current_peer 10.149.149.55 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 192.168.19.10, remote crypto endpt.: 10.149.149.55
plaintext mtu 1372, path mtu 1372, ip mtu 1372, ip mtu idb Tunnel0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

interface: Dialer0
Crypto map tag: SDM_CMAP_1, local addr 10.149.149.128

protected vrf: (none)
local ident (addr/mask/prot/port): (10.149.149.128/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.149.149.55/255.255.255.255/47/0)
current_peer 10.149.149.55 port 500
PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 3, #recv errors 0

local crypto endpt.: 10.149.149.128, remote crypto endpt.: 10.149.149.55
plaintext mtu 1452, path mtu 1452, ip mtu 1452, ip mtu idb Dialer0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:
Router#

[Richard Burts]

The title of this discussion indicates that a vpn tunnel is not established. But the output that you post shows that in fact the tunnel is established.

interface: Tunnel0
Crypto map tag: SDM_CMAP_1, local addr 192.168.19.10

protected vrf: (none)
local ident (addr/mask/prot/port): (10.149.149.128/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.149.149.55/255.255.255.255/47/0)

The output also shows that there are no packets encapsulated and no packets dencapsulated. So there is no traffic going through the tunnel. So the problem really is not about establishing the tunnel and is about why traffic is not going through the tunnel. You are running EIGRP over the tunnels. So are you learning any routes over the tunnels? Would you post the output of show ip route and we can see if there are EIGRP learned routes. It might also be helpful to show the EIGRP interfaces and EIGRP neighbors.

You ask if you need ip nat outside on the dialer interface. That is an interesting question and the answer depends on whether you intend to do address translation. The configs that you posted show no configuration for address translation. So I would say that at present there is no need for ip nat outside. If you do intend to come back and implement address translation then you would need the command on the dialer.

HTH

Rick