Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Archive] [SRX] Behavior of the 'df-bit' flag when IPSec is encapsulated

0

1

Article ID: KB25625 KB Last Updated: 29 Mar 2019Version: 4.0
Summary:

Note: This article applies to Junos OS 11.4R3, so it has been archived.

This article describes the behavior of the df-bit flag, when the incoming clear text packet is received by the SRX device and is encapsulated for the IPSec packet.

Symptoms:
SRX does not return type=3 code=4 ICMP to the sender, when the packet size exceeds the MTU of tunnel interface, after packet encryption.
Cause:
The default behavior of DF-bit, when the traffic goes to the IPSec tunnel, is to not change the DF-bit of the inner IP header and clear the DF-bit flag on the outer IP header.
<Command Line>
set security ipsec vpn <VPN Name> df-bit clear

<DF Bit Clear>
root> show security ipsec security-associations index 131073
ID: 131073 Virtual-system: root, VPN Name: vpn-001
Local Gateway: 120.1.1.1, Remote Gateway: 120.1.1.254
Local Identity: ipv4_subnet(any:0,[0..7]=150.1.1.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=100.1.1.0/24)
Version: IKEv1
DF-bit: clear <=========
Bind-interface: st0.0
When a large packet is DF-bit flagged, which does not exceed the ingress interface MTU, but exceeds the egress tunnel interface MTU, is received by SRX, the IP payloads will be encrypted first. Then, if the encrypted packet exceeds the tunnel interface MTU, the packet will be fragmented before ESP encapsulation and these encrypted and fragmented IP packets (one with ESP header and the other without ESP header) will be transmitted; without DF-bit being flagged.

For this scenario, SRX will not return type=3 code=4 ICMP to the sender and transmit fragmented packets to the IPSec peer; without DF-bit being flagged.
Solution:
If the configuration is changed to set security ipsec vpn <VPN-Name> df-bit copy, it will copy the DF-bit of the inner IP header to the outer IP header. This will return type=3 code=4 ICMP to the sender, when it exceeds the tunnel interface MTU and encrypted and fragmented IP packets will not be transmitted.
<Command Line>
set security ipsec vpn <VPN Name> df-bit copy

<DF Bit Clear>
root> show security ipsec security-associations index 131073
ID: 131073 Virtual-system: root, VPN Name: vpn-001
Local Gateway: 120.1.1.1, Remote Gateway: 120.1.1.254
Local Identity: ipv4_subnet(any:0,[0..7]=150.1.1.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=100.1.1.0/24)
Version: IKEv1
DF-bit: copy <=========
Bind-interface: st0.0
Modification History:
2019-03-29: Moved article to 'archive' state, as it applies to Junos OS 11.4R3.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search