IPSEC encrypting traffic under DENY statements.

[aalex1055]

Hello,

I have a site to site IPSEC tunnel over a providers network. 

The crypto map is defined and applied on the WAN interface (interface facing the ISP).

The crypto map calls an extended ACL to specify what traffic should be encrypted.

Tunnel is UP and traffic specified by PERMIT statements on the ACL is being encrypted.

My problem is that that same ACL has a few DENY statements at the begining for specific network-to-host traffic that I would like to traverse the provider's network unencypted. Those deny statements don't seem to be working as the traffic defined in them is also being encrypted and tunneled end to end.

My traceroutes using endpoint sources and destinations which match the deny statements show a single hop between IPSEC peers.

I've tried clearing ipsec sessions on both endpoints of the tunnel and, as soon as the tunnel comes up, traffic matching DENY statements starts to be encrypted.

¿Can anyone tell me why DENY statements on top of the Crypto ACL are being ignored? Its not just one, there are quite a few DENYs at the top of the ACL and none of them are working.

I thank any help in advance,

Alex.

[Richard Burts]

Alex

The obvious first guess is that there is some logic or syntax issue that causes the deny statements to not match. Would you post some information about the topology and the details of how the access list is configured?

HTH

Rick

[aalex1055]

Hello, 

The configuration is actually preety simple. The endpoint from which the tests are being made applies a Crypto map that calls on an ACL that looks like this:

ip access-list extended MYACL
deny ip any host x.x.x.x
deny ip any host 15.121.65.16
deny ip any host x.x.x.x
deny ip any host x.x.x.x
[...]
 permit ip 15.0.0.0 0.255.255.255 15.121.64.0 0.0.3.255
[...]

Traffic not matching any PERMIT statements is not being encrypted, but DENY statements on top of the ACL don't seem to be working for hosts on subnets which have a PERMIT afterwards.

By the way, this is Cisco 7200. I should have mentioned that before, sorry.

Thanks for your help,

Álex.

[Richard Burts]

Alex Would you post the output of show crypto IPsec sa

HTH

Rick

[aalex1055]

Hello,

The output of that command is huge since the ACL y quite large. I think it only shows ACTIVE SAs for traffic under permit statements. Traffic affecting this particular path would correspond to this section:

protected vrf: (none)
local ident (addr/mask/prot/port): (15.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (15.121.64.0/255.255.252.0/0/0)
current_peer 10.95.0.4 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 31994136, #pkts encrypt: 31994136, #pkts digest: 31994136
#pkts decaps: 19069093, #pkts decrypt: 19069093, #pkts verify: 19069093
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 10, #recv errors 0

local crypto endpt.: 10.95.0.1, remote crypto endpt.: 10.95.0.4
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1.91
current outbound spi: xxxxxxx

inbound esp sas:
spi: xxxxxxx
transform: xxxxxxx xxxxxxx,
in use settings ={Tunnel, }
conn id: xxxxxxx  , flow_id: VSA :xxxxxxx , crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (xxxxxxx)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: xxxxxxx
transform: XXXXXX XXXXXX ,
in use settings ={Tunnel, }
conn id: xxxxxxx, flow_id: VSA: xxxxxxx, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (xxxxxxx)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

No SAs with DENYs:

ROUTER#sh crypto ipsec sa peer 10.95.0.4 | i DENY
ROUTER#

Thanks again,

Álex.

[Richard Burts]

Alex

I can appreciate that the output might be quite large and that does make it difficult to find what we are looking for. So let me try again in a slightly different way and perhaps we can make some progress. I am looking for an example of traffic for a host that has deny statements in the crypto ACL but is getting encrypted and transmitted, and would like to see the SA for that traffic. Perhaps this is more feasible?

HTH

Rick

[aalex1055]

Hello Richard,

Thank you for your patience.

Tests are being run using traceroute from 15.17.161.168 to 15.121.65.16

Traffic matching the deny statement:

router#sh ip access-lists MYACL
Extended IP access list MYACL
15 deny ip any host 15.121.65.16
[...]

370 permit ip 15.0.0.0 0.255.255.255 15.121.64.0 0.0.3.255

[...]

The only part of the output of "show crypto ipsec sa" that matches that source and destination is the one matching the PERMIT statement:

protected vrf: (none)
local ident (addr/mask/prot/port): (15.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (15.121.64.0/255.255.252.0/0/0)
current_peer 10.95.0.4 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 34910039, #pkts encrypt: 34910039, #pkts digest: 34910039
#pkts decaps: 20841758, #pkts decrypt: 20841758, #pkts verify: 20841758
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 10, #recv errors 0

local crypto endpt.: 10.95.0.1, remote crypto endpt.: 10.95.0.4
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1.91
current outbound spi: xxxxxxx(xxxxxxx)

inbound esp sas:
spi: xxxxxxx(xxxxxxx)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: xxxxxxx, flow_id: VSA:xxxxxxx, crypto map: xxxxxxx
sa timing: remaining key lifetime (k/sec): (xxxxxxx/xxxxxxx)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE
spi: xxxxxxx(xxxxxxx)
transform: xxxxxxx,
in use settings ={Tunnel, }
conn id: 11967, flow_id: VSA:xxxxxxx, crypto map: xxxxxxx
sa timing: remaining key lifetime (k/sec): (xxxxxxx/xxxxxxx)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: xxxxxxx(xxxxxxx)
transform: xxxxxxx,
in use settings ={Tunnel, }
conn id: 11870, flow_id: VSA:xxxxxxx, crypto map: xxxxxxx
sa timing: remaining key lifetime (k/sec): xxxxxxx
IV size: 8 bytes
replay detection support: N
Status: ACTIVE
spi: xxxxxxx
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: xxxxxxx, flow_id: VSA:xxxxxxx, crypto map: xxxxxxx
sa timing: remaining key lifetime (k/sec): xxxxxxx
IV size: 8 bytes
replay detection support: N
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

The output of "show crypto sess detail" shows 0 SA for that DENY statement:

IPSEC FLOW: deny ip 0.0.0.0/0.0.0.0 host 15.121.65.16
Active SAs: 0, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

I'm not sure why, but it seems that there is no SA for the traffic matching the DENY.

Thanks again for your help and your patience,

Álex.

[Richard Burts]

Alex It is expected behavior that there is no SA for traffic matching the DENY. The SA is negotiated for traffic that will be sent encrypted. There is no point in negotiating a SA if that traffic will not be sent encrypted. I am still puzzled about why the traffic that should match the deny statement would be processed by a permit that comes later in the access list. As a test would it be possible to remove this permit and see if the behavior of the host to host traffic changes?

HTH

Rick

[aalex1055]

Hello Richard,

The test you recommend was already suggested but, because this is in production, it has been delayed.

I have it scheduled for the first few days of next month. 

I believe this is a weird behavior and I am quite curious as to why de denys are being ignored. If I manage to perform this test during the first week of December, I'll post the results here.

Thank you a lot for all your time and effort helping me out.

Kind regards,

Álex.

[Richard Burts]

Alex

Thanks for the update. It is certainly understandable that in production tests must be scheduled. Please do let us know the results of the test when it has been conducted.

HTH

Rick

[aalex1055]

Hello Richard, 

We finally tested this Sunday. No luck.

We managed to confirm that traffic being encrypted was indeed matching the permit statement below in the same ACL by removing it.

We then went on to remove the whole Crypto config and introduce it back again.

We rebooted the router just in case.

We even tried to set up statements that didn't use the keyword "any".

None of this seems to have any effect. Traffic that should be matching deny statements is still being encrypted and we have no idea why.

We will try to upgrade the router and we will open a case with Cisco but I find this very strange behavior. If you can come up whith something, as allways, I thank you for your help in advance,

Álex.

[Richard Burts]

Alex

Thanks for the update. I am disappointed that it was not more successful in identifying the issue. I do hope that you will open a case with Cisco TAC and they are more successful in identifying the issue.

I will continue to think about the issue but hope that Cisco TAC will be more successful in identifying the cause.

HTYH

Rick

[Shakti Kumar]

hi ,

if you are planning  to deny traffic or services over s2s vpn i would rather suggest to use vpn-filter

http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/99103-pix-asa-vpn-filter.html

please rate if helpful

thanks

shakti