Ask Your Question

Checksum (ESP ICV) with Extended Sequence Number (ESN)

asked 2024-02-09 14:07:09 +0000

Ivan Rancati gravatar image

updated 2024-02-09 14:08:17 +0000

Dear community,

I have a small problem with displaying checksums for encapsulated packets, when I am capturing data over a IPSec connection that has been negotiated using Extended Sequence Numbers In both scenarios, I use tcpdump on the client to capture packets sent to the VPN Server, and use dig and ping to generate some traffic on the VPN tunnel.

Scenario 1 - no problem here
Connection from Strongswan client to a VPN Server
The ESP proposals do not include “esn” (Extended Sequence Numbers)
The VPN Tunnel works: I can reach services/servers in the VPN
On the client, with “ip xfrm state” I get the SPI, encryption and authentication details and enter them in Preferences/Protocols/ESP
All 4 options are checked, in particular “Attempt to check ESP Authentication”
The ESP Packet are now decrypted, I see a ESP IV (16 bit) and in Encapsulating Security Payload / ESP ICV I see that the value, 16 bit, is marked as correct
[Good: True]
[Bad: False]

Scenario 2 - Wireshark displays the checksum as incorrect
Connection from Strongswan client to a VPN Server
The ESP proposals include “esn” (Extended Sequence Numbers)

esp_proposals = aes256-sha256-modp2048-esn

The VPN Tunnel still works: I can reach services/servers in the VPN
This means that the VPN client and server can check the ICV for each packet, otherwise packets would be discarded due to incorrect checksums
Wireshark can still decrypt the EPS packets, I still see a 16 bit ESP IV and ESP ICV
However, now in Encapsulated Security Payload the ESP ICV is marked as “Incorrect”
[Good: False]
[Bad: True]
This for all packets, whether sent or received

I’ll be happy to provide more details if needed. Or test a beta build of Wireshark.

I am using Wireshark 4.2.2 on Windows 11, the VPN Client is Strongswan 5.9.13 on Ubuntu 23.10, and the VPN Server is a BSD based appliance (
The options in “ESP SAs” are, in both scenarios, and in both directions:
Protocol IPv4
Encryption AES-CBC [RFC3602]
Authentication HMAC-SHA-256-128 [RFC4868]

Thank you and best regards
Ivan Rancati

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2024-02-12 06:43:17 +0000

Jaap gravatar image

Okay, this is called a bug report. This is not the place for these, they go here. Fill out the complete report, and add sample capture files there, so that developers have data to work with.

edit flag offensive delete link more


Thanks for the info. I entered a bug report:

Ivan Rancati gravatar imageIvan Rancati ( 2024-02-16 17:10:28 +0000 )edit

Looks good.

Jaap gravatar imageJaap ( 2024-02-16 19:08:08 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2024-02-09 14:07:09 +0000

Seen: 77 times

Last updated: Feb 16