cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
30315
Views
12
Helpful
18
Replies

Do I need 'crypto ipsec df-bit clear'?

localgareth
Level 1
Level 1

I have a VPN tunnel between an 871 and 877, the tunnel seems to be fine, but checking the tunnel using SDM shows an error.

Checking the tunnel status... Up

Encapsulation :330231

Decapsulation :393226

Send Error :7939

Received Error :0

-----

A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not Fragmet' packets.

1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.

-----

Are the send errors anything to worry about?

Do I need to issue the 'crypto ipsec df-bit clear' on the routers?

Any info would be much appreciated.

Thanks

Gareth

18 Replies 18

attrgautam
Level 5
Level 5

The crypto IPSec-df bit clear will clear the df-bit in the IPSec header being formed during encryption. this may jus help in your case. You can also change the TCP MSS on the egress interface so this will rule out MTU related issues.

Regds

Gareth

In general the issue has to do with what happens to a packet if it has the Do Not Fragment bit set and it gets to a network device and exceeds the maximum frame size. The normal action would be to fragment the packet and send over the segment with a smaller max frame size. But the DF bit prevents fragmentation and so the packet will be dropped.

Issues with max frame size and DF are common when doing IPSec (and when doing GRE, and especially common if doing both IPSec and GRE). This is caused by the extra headers that IPSec and GRE add to the original packet. That is what SDM is reporting, is that the IPSec tunnel can not pass packets that exceed the maximum frame size.

There are several solutions to this problem. One solution is the Path MTU Discovery. This checks over the path to discover what is the largest size packet that will pass without fragmentation. When PMTUD works correctly the end stations negotiate a frame size that will not exceed the capacity of the link in the middle. Unfortunately in many networks (especially ones which cross other public networks) PMTUD does not function correctly (most often because the ICMP error message it depends on may be filtered out). Another of the solutions is the ipsec-df bit clear which will clear the DF bit and allow fragmentation. If you do not have concerns about why the DF bit was set and are comfortable that clearing it will not impact anything (and usually clearing the DF bit has little or no impact) then you can do this. Another solution is to use the ip cp adjust-mss command which will look at TCP connection setup and will force the MSS negotiation to use a smaller MTU and will avoid the fragmentation issue.

I believe that both clear df bit and adjust-mss will work. And it may be that in your network that PMTUD is working. If your users are not experiencing problems I am not sure that I would do anything - even if SDM thinks there is an error.

HTH

Rick

HTH

Rick

Hi Guys

Thanks for responding.

I'm not using GRE, just IPSEC. The user are complaining about the speed of the VPN, but it's very difficult for me to work out whether there is a problem, or if this is just general whinging :-) I decided to do some troubleshooting with SDM, and then found this problem.

I don't mind trying the "ipsec-df bit clear" command, and can also try "ip tcp adjust-mss"... what value should I choose for this, and does these changes need to be applied on both sides of the VPN (ie, the 877 and 871). My VPN tunnel is not a virtual interface, so should I apply this to the vlan or the outside interface?

Thanks again

Gareth

MSS is one time value apply anywhere along the path prefarably outgoing interface and you will set the maximum segment segment. I would recommend some where around 1300 (it works for me ). Suggest giving the same MSS on both routers

Hi Guys

I set MSS to 1300 on the outside interface of both routers, but SDM still reports a problem. I also tried setting 'crypto ipsec df-bit clear' on both routers, again SDM still reports a problem.

I'm very concerned that the Send Errors SDM shows for this tunnel could be causing performance problems.

Gareth

I've just been playing with the config, and removed my ACL from the outside interface. The same SDM test completed without warnings!

Could the "deny icmp any any redirect" in my ACL have caused this problem? How should I remove this without opening up my router to icmp attacks?

ip access-list extended OUTSIDE

remark --- Drop redirects

deny icmp any any redirect

remark --- Drop loopback traffic

deny ip 127.0.0.0 0.255.255.255 any

remark --- Stupid IOS, this is traffic from inside an ipsec tunnel!

permit ip 192.168.x.x 0.0.0.255 192.168.x.x 0.0.0.255

permit ip 10.52.x.x 0.0.0.255 172.17.x.x 0.0.0.15

remark --- Drop RFC1918

deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16.0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

remark --- Drop mcast

deny ip 224.0.0.0 31.255.255.255 any

remark --- Drop MS APIPA

deny ip 169.254.0.0 0.0.255.255 any

remark --- Allow incoming SSH

permit tcp any host 84.x.x.x eq 22

remark --- Allow ESP and ISAKMP

permit esp host 84.x.x.x host 84.x.x.x

permit udp host 84.x.x.x host 84.x.x.x eq isakmp

remark --- Drop everything else

deny ip any any log

Gareth

Gareth

First a comment about an earlier post: when I use the tcp adjust-mss I apply it to the LAN interface where users connect. In my terminology that would be the inside interface. If you used it on the outside interface, I would suggest that you move it to the inside interface and see if it makes any difference.

In the current post, I have a hard time believing that denying icmp any any redirect is causing any problem. And I doubt that removing that line would increase your exposure any significant amount. If you are concerned about icmp attacks then you need to deny a lot more icmp than just redirects.

I am curious about the fact that removing the access list allows the SDM test to complete with no errors. Perhaps you can remove the one line about icmp redirect, apply the rest of the access list, and let us know what happens.

The deny any any at the bottom includes the log parameter. Are there messages in the log about what is being denied. This might provide a clue about what SDM is seeing as a problem.

HTH

Rick

HTH

Rick

Hi Rick

Thanks for the reply.

I correct my mistake, and re adjusted MSS onto my vlan1 interface, where the users connect. This didn't make any difference.

However, I removed the ' deny icmp any any redirect', but left the rest of the ACL in place, and the SDM test failed! I guess this is good news in a way :-)

I found this in my log entry...

018845: Nov 11 08:31:08.956 GMT: %SEC-6-IPACCESSLOGDP: list OUTSIDE denied icmp 84.x.x.x -> 84.y.y.y (0/0), 1 packet

... I guess this is caught by the last entry in my ACL of 'deny ip any any log'.

So, I guess I need to permit some types of icmp traffic, could you give me some pointers?

Many thanks

Gareth

Gareth

Moving the adjust-mss may not have corrected the error reported by SDM but you may want to observe user traffic and see if it helps to improve their response time.

You have made good progress in solving the problem when you found the entry in the log for the denied packet. I believe that you do need to allow some icmp throught your access list. I would start with permit icmp any any. This will allow all icmp. When you do this then check and verify that SDM no longer reports a problem. After you have cleared the error reported by SDM you may want to consider which types of icmp you want to allow and which types you want to deny. Most of the icmp messages are helpful. I find frequently that people are worried about possible negative aspects of icmp and deny all icmp. This frequently is counter productive and you may wind up missing information that could have been helpful. So if you want to get into this I would suggest that you start with a list of the icmp message types (online help in IOS would be one way to get that list: permit icmp any any ?). Then you can go through the icmp message types and identify those specific messages that you do not want to allow. You can create access list entries to deny those specific messages.

HTH

Rick

HTH

Rick

Hi Rick

I've got a list of icmp types from typing 'permit icmp any any ?' in IOS... theres quite a list, 57!!

How should I decide which ones to allow and which ones to block, I don't even know what they mean :-) Do Cisco publish any recommendations?

bim7dsl(config-ext-nacl)#permit icmp any any ?

<0-255> ICMP message type

administratively-prohibited Administratively prohibited

alternate-address Alternate address

conversion-error Datagram conversion

dod-host-prohibited Host prohibited

dod-net-prohibited Net prohibited

echo Echo (ping)

echo-reply Echo reply

fragments Check non-initial fragments

general-parameter-problem Parameter problem

host-isolated Host isolated

host-precedence-unreachable Host unreachable for precedence

host-redirect Host redirect

host-tos-redirect Host redirect for TOS

host-tos-unreachable Host unreachable for TOS

host-unknown Host unknown

host-unreachable Host unreachable

information-reply Information replies

information-request Information requests

log Log matches against this entry

log-input Log matches against this entry, including input

interface

mask-reply Mask replies

mask-request Mask requests

mobile-redirect Mobile host redirect

net-redirect Network redirect

net-tos-redirect Net redirect for TOS

net-tos-unreachable Network unreachable for TOS

net-unreachable Net unreachable

network-unknown Network unknown

no-room-for-option Parameter required but no room

option Match packets with given IP Options value

option-missing Parameter required but not present

packet-too-big Fragmentation needed and DF set

parameter-problem All parameter problems

port-unreachable Port unreachable

precedence Match packets with given precedence value

precedence-unreachable Precedence cutoff

protocol-unreachable Protocol unreachable

reassembly-timeout Reassembly timeout

redirect All redirects

reflect Create reflexive access list entry

router-advertisement Router discovery advertisements

router-solicitation Router discovery solicitations

source-quench Source quenches

source-route-failed Source route failed

time-exceeded All time exceededs

time-range Specify a time-range

timestamp-reply Timestamp replies

timestamp-request Timestamp requests

tos Match packets with given TOS value

traceroute Traceroute

ttl-exceeded TTL exceeded

unreachable All unreachables

Would it be better to permit all icmp where the source is the other end of my VPN, a known fixed IP? And then deny icmp from elsewhere?

Thanks for all your help on this.

Gareth

Gareth

Trying to go through the list and explain each one is beyond the scope of this forum. My recommendation is to go through the list, identify and deny the ones that you worry about, and permit the rest. I know that a lot of people worry about echo Echo (ping). Do you want any one to be able to ping you? Do you want anyone in your network to be able to ping outside of your network?

I believe that there are some very obvious choices. For example if you deny:

packet-too-big Fragmentation needed and DF set

then Path MTU Discovery is broken. PMTUD is especially important when you deal with IPSec tunnels because the IPSec header which is added to the packet is very likely to create the need for fragtmentation.

My perspective is that icmp is an easy target when people worry about security of the network at a high level. But when you look at the details of what is involved there are a lot of messages in icmp that are really helpful. I believe that people usually do not understand what they are giving up when they just deny icmp from remote addresses.

HTH

Rick

HTH

Rick

Rick - thanks for all the help. I've still not solved the problem, but I'm playing around with permit and deny on different icmp traffic.

Many thanks

Gareth

bchostner
Level 5
Level 5

Gareth,

TCP Adjust MSS does not work with UDP and ICMP. I have also been cautioned about performance with remove df-bit enabled, expecially globally and it will also cause issues with TCP. I use the tcp adjust-mss 1310 on my tunnel interfaces and apply a route map to remove df flag from UDP. This should take care of tcp and udp in ipsec tunnels.

interface tunnel1

ip tcp adjust-mss 1360

ip access-list extended udp-df1

permit udp any any

route-map udp-df0 permit 10

match ip address udp-df1

set ip df 0

!

route-map udp-df0 deny 99

interface ingress0

ip policy route-map udp-df0

sh route-map udp-df0

route-map udp-df0, permit, sequence 10

  Match clauses:

    ip address (access-lists): udp-df1

  Set clauses:

    ip df 0

  Policy routing matches: 124071 packets, 35760711 bytes

route-map udp-df0, deny, sequence 99

  Match clauses:

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

That is an interesting solution. Thank you for sharing it with the forum.

HTH

Rick

HTH

Rick
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: