cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1233
Views
0
Helpful
4
Replies

Crypto ACL not matching client's traffic..from router it works

apt_portfolio
Level 1
Level 1

We have a IPSec peer. Everything works great..IPSec established, from the router I can ping/connect to the remote hosts, but the clients are not able to connect. There is no NAT involved. When pinging any remote IP from the router using the source IP of LAN interface on which the clients are connected, it works well, but the same thing doesn't work when pinging from client. I even tried assigning different subnet and configured NAT on it to no avail. From the router everything works perfectly, but a directly connected host is not able to connect to anything. Tried different clients as well but it didn't work either. Below is some show commands the I think will be useful for anyone to understand:

B3-MD#show crypto ip sa peer REMOTEPEER

interface: GigabitEthernet0/0
Crypto map tag: b3vpn, local addr LOCALADDRESS

protected vrf: (none)
local ident (addr/mask/prot/port): (LOCALSUBNET/255.255.255.224/0/0)
remote ident (addr/mask/prot/port): (REMOTESUBNET/255.255.255.0/0/0)
current_peer REMOTEPEER port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 39, #pkts encrypt: 39, #pkts digest: 39
#pkts decaps: 39, #pkts decrypt: 39, #pkts verify: 39
#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.: LOCALADDRESS, remote crypto endpt.: REMOTEPEER
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x900765E(151025246)
PFS (Y/N): Y, DH group: group14

inbound esp sas:
spi: 0xB036DAEE(2956385006)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3195, flow_id: Onboard VPN:1195, sibling_flags 80000040, crypto map: b3vpn
sa timing: remaining key lifetime (k/sec): (4287563/3325)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x900765E(151025246)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3196, flow_id: Onboard VPN:1196, sibling_flags 80000040, crypto map: b3vpn
sa timing: remaining key lifetime (k/sec): (4287563/3325)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:
B3-MD#show ip access-lists 149
Extended IP access list 149
10 permit ip LOCALSUBNET 0.0.0.31 REMOTESUBNET 0.0.0.255 (68 matches)
Crypto Map: crypto map b3vpn 20 ipsec-isakmp
set peer REMOTEPEER
set transform-set B3VPN
set pfs group14
match address 149
crypto map b3vpn

B3-MD#show run int gi0/0
Building configuration...

Current configuration : 122 bytes
!
interface GigabitEthernet0/0
ip address LOCALADDRESS 255.255.255.248
duplex auto
speed auto
crypto map b3vpn
end

B3-MD#show run int gi0/1
Building configuration...

Current configuration : 137 bytes
!
interface GigabitEthernet0/1
ip address (LANINTERFACE <LOCALSUBNET>) 255.255.255.224
ip pim sparse-mode
duplex auto
speed auto
no cdp enable
end

 

 

 

P.S It's a CISCO1921/K9 Device

1 Accepted Solution

Accepted Solutions

apt_portfolio
Level 1
Level 1

So the problem was not in the crypto maps or the ACL, but CEF was enabled and it was causing this issue. As soon as we did a 'no ip cef', it started to work from all the clients.

View solution in original post

4 Replies 4

Hi,
Well the IPSec tunnel is up and I able to determine that traffic appears to be sent and received (encaps|decaps counters increasing). What type of host are you testing with? Do they have a local firewall configured that would stop the pings from responding?

HTH

Yes both phase 1 and 2 are up and the router is also able to ping the remote hosts. We tried with different hosts but it doesn't work from the clients.

Dennis Mink
VIP Alumni
VIP Alumni

if your phase one is up and your are able to at least send some traffic acorss the tunnel, then you should focus on IPSEC SAs, enmcryption domains/interestingb traffic and thirdly access list. this needs to be check on both ends.

 

9 out of times these sorts of issues are caused by config mismatches at either end.

 

is the other end a cisco device as well?

Please remember to rate useful posts, by clicking on the stars below.

apt_portfolio
Level 1
Level 1

So the problem was not in the crypto maps or the ACL, but CEF was enabled and it was causing this issue. As soon as we did a 'no ip cef', it started to work from all the clients.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: