|
To identify if the ESP packets are sent and received, a sniffer can be used. The commands below will capture the ESP packets:
If NAT traversal is not in use, ESP packets are filtered using protocol 50:
diagnose sniffer packet any "proto 50" 6 0 l
Or:
diagnose sniffer packet any "host x.x.x.x and esp" 6 0 l <----- Where x.x.x.x is the IP address of the remote peer.
If NAT traversal is in use, ESP will be over UDP port 4500:
diagnose sniffer packet any "host x.x.x.x and port 4500" 6 0 l
The Encryption/Decryption can be verified on the tunnel level with the command:
diagnose vpn tunnel list name <phase1-name>
name=Primary Tunnel ver=1 serial=2 10.10.1.1:0->10.10.1.2:0 tun_id=10.10.1.2 dst_mtu=1500 dpd-link=on remote_location=0.0.0.0 weight=1
bound_if=5 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/520 options[0208]=npu frag-rfc run_state=0 accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=4 ilast=0 olast=0 ad=/0
stat: rxp=11746 txp=32 rxb=1939048 txb=9861
dpd: mode=on-demand on=1 idle=10000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=Net-10.1.1.0-24 proto=0 sa=1 ref=2 serial=5
src: 0:192.168.1.0/255.255.255.0:0
dst: 0:10.1.1.0/255.255.255.0:0
SA: ref=4 options=10226 type=00 soft=0 mtu=1438 expire=42832/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=000001db itn=0 qat=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=42933/43200
dec: spi=e6bb098b esp=aes key=16 4c3dd75b85f0be4c2d2b95e5dfe7e99d
ah=sha1 key=20 f9a5dbc83604b58aff64e74fe40137cd89dc98e
enc: spi=533e1c0c esp=aes key=16 4fddb780c9606c5c235737bd7d05c585
ah=sha1 key=20 57c8349171a97eaf230e565bb90853cefaca7ab
dec:pkts/bytes=46/772, enc:pkts/bytes=0 <<<<
If ESP packet loss is identified, the bellow actions can resolve it.
NPU Offload:
In case the drops are caused by the NPU, disable the offloading under phase 1.
config vpn ipsec phase1-interface
edit <phase1-name>
set npu-offload disable
end
If the issue goes away after disabling offloading, esp padding might be the cause. To ensure ESP packets are not dropped due to excessive layer 2 padding, the following change should be performed:
config system npu
set strip-esp-padding enable
set strip-clear-text-padding enable
end
The offloading under phase 1 can be enabled again and the behaviour.
Firewall Policies:
In cases, firewall policies are a requirement, such as when the tunnel is configured on a loopback, and FortiGate is not the initiator.
The firewall policies should be checked to ensure they are not blocking ESP packets. The Debug flow can be used to troubleshoot this case:
diagnose debug enable
diagnose debug flow filter addr x.x.x.x<----- Where x.x.x.x is the IP address of the remote peer.
diagnose debug flow filter proto 50<-----If NAT-T is in use, use port 4500 instead as a filter.
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
ISP Check:
Verify with ISPs that ESP packets are not being blocked on the WAN. NAT transversal can be used to change the port from 500 to 4500 even when NAT is not used. This will help in case packets in port 500 are dropped by the ISP.
config vpn ipsec phase1-interface
edit "tunnel-name"
set nattraversal forced
end
Related documents:
VPN (ESP) traffic dropped due to NP6 PBA leak
Debugging the packet flow
Technical Tip: IPSec VPN NAT-traversal
|
