|
Consider the following setup:
- On the Hub location, a dynamic Dial-up VPN tunnel is configured.
- On Spoke, the static VPN tunnel is configured.
By default, on the VPN phase 1 config, 'set ip-fragmentation post-encapsulation' is configured.
In some cases, traffic may be dropped, and hence, 'set ip-fragmentation pre-encapsulation' needs to be configured on phase 1 with an MTU on the VPN tunnel interface.
For more details regarding pre-encapsulation and post-encapsulation, review the article: Technical Tip: IP Packet fragmentation over IPSec tunnel interface explained.
For a dynamic VPN tunnel, changing this will not take effect immediately.
Current Settings: set ip-fragmentation post-encapsulation + tunnel interface mtu 1300:
Hub # diagnose sniffer packet any 'host 192.168.100.2' 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[host 192.168.100.2]
2025-02-28 14:25:20.257506 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:25:20.257506 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:25:20.257566 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:25:20.257566 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:25:20.257745 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:25:20.257745 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:25:20.257759 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply ---> No fragmentation taking place with default settings on the tunnel
2025-02-28 14:25:20.257759 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply
Changing to pre-encapsulation:
Hub # config vpn ipsec phase1-interface
Hub (phase1-interface) # edit ipsec2
Hub (ipsec2) # set ip-fragmentation pre-encapsulation
Hub (ipsec2) # end
New settings: set ip-fragmentation pre-encapsulation + tunnel interface mtu 1300:
Still no fragmentation taking place:
Hub # diagnose sniffer packet any 'host 192.168.100.2' 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[host 192.168.100.2]
2025-02-28 14:27:14.828822 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:27:14.828822 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:27:14.828886 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:27:14.828886 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:27:14.829093 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:27:14.829093 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:27:14.829124 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply ---> No fragmentation taking with tunnel interface mtu of 1300
2025-02-28 14:27:14.829124 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply
As a workaround, after rebooting the FortiGate, it works.
Hub # diagnose sniffer packet any 'host 192.168.100.2' 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[host 192.168.100.2]
2025-02-28 14:30:38.427976 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:30:38.427976 ipsec2 in 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:30:38.428003 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:30:38.428003 port3 out 10.245.9.11 -> 192.168.100.2: icmp: echo request
2025-02-28 14:30:38.428222 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:30:38.428222 port3 in 192.168.100.2 -> 10.245.9.11: icmp: echo reply
2025-02-28 14:30:38.428243 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply (frag 33513:1280@0+) ---> Starts working after reboot.
2025-02-28 14:30:38.428243 ipsec2 out 192.168.100.2 -> 10.245.9.11: icmp: echo reply (frag 33513:1280@0+)
2025-02-28 14:30:38.428303 ipsec2 out 192.168.100.2 -> 10.245.9.11: ip-proto-1 (frag 33513:128@1280)
2025-02-28 14:30:38.428303 ipsec2 out 192.168.100.2 -> 10.245.9.11: ip-proto-1 (frag 33513:128@1280)
Note: This has been addressed and will be fixed with the FortiOS v7.4.8 release.
|
