- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-23-2017 04:01 PM
We have recently migrated our site-to-site VPN so it is now running between a PA-3020 > Cisco ASA 5510. After the migration we discovered that one of our cross-site applications broke and the vendor determined it was because their application communicates in 1472 byte packets with the DF bit set. On our old VPN this was not an issue because the devices cleared the DF bit, allowing the packets to be fragmented before crossing the tunnel.
I have found the option on the ASA to clear the DF bit (crypto ipsec df-bit clear-df <interface>), however I can't locate anything similar in the PA documentation.
Can someone please point me in the right direction? Thanks!
03-23-2017 10:26 PM
Hi Winterfrost,
Welcome to the community forums!
As far as I know, there is no option to clear the df bit, on PA. However, you can adjust MSS/MTU under Network->Interfaces.
Regards,
Anurag
03-31-2017 08:43 AM - edited 03-31-2017 08:43 AM
The connection is currently passing 1472-byte ping with the DF-bit set, but I'm not entirely clear how this works.
We have 1500 MTU set on the physical external interface and on the tunnel interface on the PA. At the remote site (Cisco ASA) we have the same MTU settings, but we had to turn on the option to clear the DF bit on the ASA to pass a DF-flagged 1472 byte ping. I assumed we needed to do the same on the PA, but as soon as we enabled it on the Cisco side, the pings started to go through.
So 1472 data + 20 IP header + 8 ICMP header = 1500. But this doesn't include IPSec overhead.
It's my understanding that a VPN device will typically evaluate a packet's size against the MTU, including the size of the IPSec header, and determine if fragmentation is needed. In the case of a packet flagged with the DF-bit, if this total size exceeds the MTU, the packet will be dropped... unless you tell the VPN device to ignore the DF-bit.
On the Cisco side this is what we did, so the packets are fragmented despite the DF-bit and the communication works. Is the PA doing the same thing automatically? Or (much more likely) am I completely misunderstanding something?
01-24-2024 08:41 AM
A) To check DF override status:
> show system state | match ip4-ignore
sw.comm.s1.dp0.flow-data: { 'b_not_use_parent_policy': False, 'cclogmgmt-reject-all': False, 'combine-pkt-msg': True, 'cutthrough': True, 'distributed-sess-mgmt': False, 'dp-avg-load': 2, 'dp-cal-load': True, 'dp-load-level': 102, 'hw-ipv6': False, 'hw-mcast': False, 'hw-remove-req-cnt': 0, 'ip4-ignore-df': False, 'ip6-host-pmtu-exception-check': False, 'ip6-mcast-fwd-check': False, 'ip6-skip-1-routing-hdr-check': False, 'ip6-skip-ucast-mac-check': False, 'ipv6-firewalling': True, 'netflow-refresh-interval': 60, 'no-learning-return-mac': False, 'num-of-free-session': 1246, 'num-of-free-session-this-dp': 1246, 'process-cpu': 0, 'session-timeout-5gcdelete': 15, 'session-timeout-closing': 5, 'session-timeout-cp': 30, 'session-timeout-default': 30, 'session-timeout-discard_default': 60, 'session-timeout-discard_sctp': 30, 'session-timeout-discard_tcp': 90, 'session-timeout-discard_udp': 60, 'session-timeout-forward': 10, 'session-timeout-gtpc_request': 90, 'session-timeout-icmp': 6, 'session-timeout-opening': 5, 'session-timeout-scan': 10, 'session-timeout-sctp': 3600, 'session-timeout-sctpcookie': 60, 'session-timeout-sctpinit': 5, 'session-timeout-sctpshutdown': 60, 'session-timeout-tcp': 3600, 'session-timeout-tcp_unverif_rst': 30, 'session-timeout-tcphalfclosed': 120, 'session-timeout-tcphandshake': 10, 'session-timeout-tcpinit': 5, 'session-timeout-tcptimewait': 15, 'session-timeout-udp': 30, 'tcp-reject-nonsyn': True, }
B) To set DF override status:
> debug dataplane set ip4-ignore-df yes
> show system state | match ip4-ignore
sw.comm.s1.dp0.flow-data: { 'b_not_use_parent_policy': False, 'cclogmgmt-reject-all': False, 'combine-pkt-msg': True, 'cutthrough': True, 'distributed-sess-mgmt': False, 'dp-avg-load': 2, 'dp-cal-load': True, 'dp-load-level': 102, 'hw-ipv6': False, 'hw-mcast': False, 'hw-remove-req-cnt': 0, 'ip4-ignore-df': True, 'ip6-host-pmtu-exception-check': False, 'ip6-mcast-fwd-check': False, 'ip6-skip-1-routing-hdr-check': False, 'ip6-skip-ucast-mac-check': False, 'ipv6-firewalling': True, 'netflow-refresh-interval': 60, 'no-learning-return-mac': False, 'num-of-free-session': 1246, 'num-of-free-session-this-dp': 1246, 'process-cpu': 0, 'session-timeout-5gcdelete': 15, 'session-timeout-closing': 5, 'session-timeout-cp': 30, 'session-timeout-default': 30, 'session-timeout-discard_default': 60, 'session-timeout-discard_sctp': 30, 'session-timeout-discard_tcp': 90, 'session-timeout-discard_udp': 60, 'session-timeout-forward': 10, 'session-timeout-gtpc_request': 90, 'session-timeout-icmp': 6, 'session-timeout-opening': 5, 'session-timeout-scan': 10, 'session-timeout-sctp': 3600, 'session-timeout-sctpcookie': 60, 'session-timeout-sctpinit': 5, 'session-timeout-sctpshutdown': 60, 'session-timeout-tcp': 3600, 'session-timeout-tcp_unverif_rst': 30, 'session-timeout-tcphalfclosed': 120, 'session-timeout-tcphandshake': 10, 'session-timeout-tcpinit': 5, 'session-timeout-tcptimewait': 15, 'session-timeout-udp': 30, 'tcp-reject-nonsyn': True, }
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!