cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3825
Views
0
Helpful
1
Replies

ICMP Type 3 Code 4 blocked at ASA

Spaniard141
Level 1
Level 1

Hello

I am working on an issue related to ICMP Fragmentation needed but DF set.

I have this topology:

Router B----GRE/IPSEC tunnel-----Router A--------Core SW-----------ASA 5510

The problem is that when the GRE tunnel was setup, users coming from router B could not access internet. We increased the MTU size on the tunnel interfaces of routers A and B to 1524 and now internet works but performance is affected due to fragmentation. I have done a lot of research  and everything points me to lowering the MTU instead of increasing it to avoid fragmentation but when doing this internet doesn't work (set as low as 1400 while testing).

I believe that the ICMP type 3 code 4 generated by router A (if I understand correctly) are being blocked by the ASA.

In order to not disrupt production, I have been experimenting with an ASA 5505 and packet tracer to see if a ICMP packet of this nature would be allowed or blocked and it fails every time. I am not sure if this is an accurate test of whether the firewall is allowing that traffic or not but if it is, then it certainly is being blocked.

I've tried multiple things including adding the inspect icmp error to the firewall but without success.

See the test I did:

asa# config t

asa(config)# class-map icmp-class

asa(config-cmap)# match default-inspection-traffic

asa(config-cmap)# exit

asa(config)# policy-map icmp_policy

asa(config-pmap)# class icmp-class

asa(config-pmap-c)# inspect icmp error

asa(config-pmap-c)# exit

asa(config-pmap)# service-policy icmp_policy interface outside

asa(config)# end

asa# packet-tracer input inside icmp 10.16.10.100 3 4 4.2.2.2

and the result was dropped... see test results:

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 outside

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 10.16.10.0 255.255.255.0

match ip inside 10.16.10.0 255.255.255.0 outside any

dynamic translation to pool 1 (192.168.1.72 [Interface PAT])

translate_hits = 309, untranslate_hits = 46

Additional Information:

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (inside) 1 10.16.10.0 255.255.255.0

match ip inside 10.16.10.0 255.255.255.0 outside any

dynamic translation to pool 1 (192.168.1.72 [Interface PAT])

translate_hits = 309, untranslate_hits = 46

Additional Information:

Phase: 7

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Also full config attached.

Am I missing something? Would this be an accurate test of whether the traffic would go through? Any thoughts on a better way of testing this?

Thanks

1 Accepted Solution

Accepted Solutions

did you try adding that inspect in the global policy?

policy-map global_policy

class inspection_default

  inspect icmp error

I think the Cisco recommended MTU is 1400 on the routers GRE tunnel interfaces in order to account for headers...

Also, I think there's a way to clear the DF bit on IPsec tunnels on the routers:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dplane/configuration/15-mt/sec-df-bit-ovride.html

Patrick

View solution in original post

1 Reply 1

did you try adding that inspect in the global policy?

policy-map global_policy

class inspection_default

  inspect icmp error

I think the Cisco recommended MTU is 1400 on the routers GRE tunnel interfaces in order to account for headers...

Also, I think there's a way to clear the DF bit on IPsec tunnels on the routers:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dplane/configuration/15-mt/sec-df-bit-ovride.html

Patrick

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:

Review Cisco Networking products for a $25 gift card