01-07-2008 08:18 AM - edited 03-03-2019 08:09 PM
Hi,
Scenario - Connecting Cisco 1841 router with WWAN (Sprint) card to existing Corporate WAN using IPSEC VPN.
Problem: Tunnel shows up show crypto commands:
show crypto ipsec sa - what looks ok
show crypto isakmp sa - shows QM_IDLE
PROBLEM:I cannot ping an internal address across the tunnel - 10.40.x.x from the WWAN router
Setups
WWAN Router:
LAN:192.168.0.0/24 on FE0/1
WAN Int: Cellular 0/0/0 68.25.xx.xxx (static from Sprint)
WAN Concentrator
WAN:63.x.x.x (static)
LAN:10.0.0.0/8 and 168.65.0.0/16
WWAN running config (modified some addresses and keys)
terminal length 0
router1841#show run
Building configuration...
Current configuration : 4546 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname router1841
!
boot-start-marker
boot-end-marker
!
no logging buffered
enable secret 5 ------------------secret was here----------------
!
no aaa new-model
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.0.1 192.168.0.3
!
ip dhcp pool pool1
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
dns-server 192.168.0.1
lease 7
!
!
ip domain name ---domain was here------
ip name-server 208.x.x.222
ip name-server 208.x.x.220
!
multilink bundle-name authenticated
chat-script cdma "" "ATDT#777" TIMEOUT 60 "CONNECT"
!
crypto pki trustpoint TP-self-signed---idwashere--
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate---idwashere--
revocation-check none
rsakeypair TP-self-signed---idwashere--
!
!
crypto pki certificate chain TP-self-signed---idwashere--
certificate self-signed 01
--certwashere--
quit
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key --keywashere-- address 63.x.x.x no-xauth
!
!
crypto ipsec transform-set trans esp-3des esp-md5-hmac
!
crypto map SprintTestCardMap 100 ipsec-isakmp
set peer 63.x.x.x
set transform-set trans
match address Dal_ACL
!
!
!
username netadmin privilege 15 password 7 --passwordwashere----
archive
log config
hidekeys
!
!
ip ssh version 2
!
!
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface Cellular0/0/0
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer in-band
dialer idle-timeout 99999
dialer string cdma
dialer-group 1
async mode interactive
ppp chap password 7 --passwordwashere--
crypto map SprintTestCardMap
!
ip route 0.0.0.0 0.0.0.0 Cellular 0/0/0
!
!
ip http server
ip http authentication local
ip http secure-server
ip dns server
ip nat inside source list 101 interface Cellular0/0/0 overload
!
ip access-list extended Dal_ACL
permit ip 192.168.0.0 0.0.0.255 10.0.0.0 0.255.255.255
permit ip 192.168.0.0 0.0.0.255 168.65.0.0 0.0.255.255
ip access-list extended Inbound_Dal_ACL
permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.0.255
permit ip 168.65.0.0 0.0.255.255 192.168.0.0 0.0.0.255
!
access-list 101 deny ip 192.168.0.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 deny ip 192.168.0.0 0.0.0.255 168.65.0.0 0.0.255.255
access-list 101 permit ip 192.168.0.0 0.0.0.255 any
dialer-list 1 protocol ip list 101
!
!
!
!
!
!
control-plane
!
!
!
--removed line details--
!
scheduler allocate 20000 1000
!
webvpn cef
end
router1841#
I have replaced critical info with ---words to describe what was there---
I know when I try to ping an address - the ipsec-isakmp starts building if it has been cleared. So I am pretty sure I am routing over the tunnel. My status show encrypted packets sent but never any decrypted packets. Any suggestions?
01-07-2008 08:28 AM
Hi,
Check the remote router "crypto map" if the ACL in the "match address" is symmetric with your "Dal_ACL". i.e.
Your "Dal_ACL"
ip access-list extended Dal_ACL
permit ip 192.168.0.0 0.0.0.255 10.0.0.0 0.255.255.255
permit ip 192.168.0.0 0.0.0.255 168.65.0.0 0.0.255.255
Remote router "crypto map" ACL
ip access-list extended WHATEVER
permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.0.255
permit ip 168.65.0.0 0.0.255.255 192.168.0.0 0.0.0.255
Regards,
Dandy
01-07-2008 10:13 AM
We have double checked ACLs - but we can triple check. What would be the best way to debug if the tunnel is up and if routing is properly configured to go over the tunnel.
I ahve tried trace from router and also from a client behind the router and I never get any data back after the LAN side - does that seem odd.
trace 10.x.x.x
192.168.0.1 x ms x ms
***
***
01-07-2008 08:06 PM
You need to use route maps instead of source list 101 to exempt the certain networks from the nat process... for the moment, the source list only looks for sources from a simple access list.
Your route map will look like :
route-map nonat permit 10
match ip address 101
You also need to add a deny to the end your Dial_ACL that prevents the other traffic from getting routed through the encryption process.
NS
01-08-2008 12:56 PM
I verified ACLs as requested. VPN Concentrator is a 3030 and administrator confirmed any 192.168.0.0 to either 168.65.0.0 or 10.0.0.0 is permitted thru the tunnel.
I also added a route map with no luck.
What is the best way to verify packets going over the tunnel and how they are configured. I don't know if the packets even leave the router since trace doesn't show anything.
01-10-2008 04:42 PM
I don't believe you need to use a route-map.
There is an instance it solves a problem, but I can'think off hand what it is.
Likewise your DAl_ACL should deny traffic by default (implicit deny at end)
If you perform a "sh cry isa sa" and you seem QM_IDLE then the tunnel is up.
Can you confirm that the other end is routing the required 192.168.0.0 network to the concentrator?
A sh cry ip sa on your router is going to show packets hopefully leaving. The Concentrator administrator should be able to check the session on the 3030 and verify no packets towards you. In which case it's more then likely routing at that end.
HTH
Tim
01-11-2008 04:59 AM
I have put in the route-mpa and it is acting the same. I do show QM_IDLE on the isakmp sa. For ipsec sa - I show enc packets and no decryp packets.
I am sitting with the concentrator admin to review today - so I will show him this thread to see if we can figure it out.
Whatever I find I will post the results for future reference.
01-11-2008 07:45 PM
Hi,
To be safe, the ACL should be symmetric (as I mentioned above).
Also, enable this debug in both router and post the output here (check the clock if correct before turning debug on).
Router# debug crypto isakmp
Router# debug crypto isakmp error
Router# debug crypto ipsec
Router# debug crypto pki
The output log of those debug above always help me to pinpoint and concentrate where the problem are.
Regards,
Dandy
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