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 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 (https://www.genua.eu/it-security-solutions/firewall-vpn-appliance-genuscreen)
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