Bug 199121 - Packet header is incorrect when following through an IPsec tunnel after upgrade kernel to 4.15
Summary: Packet header is incorrect when following through an IPsec tunnel after upgra...
Status: RESOLVED OBSOLETE
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-15 06:37 UTC by Stanislav Posonsky
Modified: 2018-04-13 02:44 UTC (History)
0 users

See Also:
Kernel Version: 4.15.9
Subsystem:
Regression: No
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Stanislav Posonsky 2018-03-15 06:37:27 UTC 
I have been using IPsec tunnel for a while. StrongSwan is used for management:
```
# swanctl -l
pfsense2: #1, ESTABLISHED, IKEv2, cc04d3c5b34b4bda_i* f150c78e4fc042ef_r
  local  '90.188.239.175' @ 90.188.239.175[500]
  remote '62.152.54.102' @ 62.152.54.102[500]
  3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  established 649s ago, reauth in 2746s
  pfsense2: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 649s ago, rekeying in 286s, expires in 551s
    in  c41e18d6,    588 bytes,     7 packets,   643s ago
    out cfad3c32,    588 bytes,     7 packets,   643s ago
    local  192.168.8.0/24
    remote 10.10.1.0/24
```
And everything worked fine. But after updating to 4.15 traffic stopped passing.

I created [issue](https://wiki.strongswan.org/issues/2571) on wiki.strongswan.org. During the analysis of the situation it was found, when I try to send ICMP request to 10.10.1.248, for example, 
```
$ ping 10.10.1.248
PING 10.10.1.248 (10.10.1.248) 56(84) bytes of data.
^C
--- 10.10.1.248 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3068ms
```
the response is returned as if from 8.0.1.248.
```
# tcpdump -n -vv -i ppp0 icmp
dropped privs to tcpdump
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
01:42:37.767964 IP (tos 0x0, ttl 63, id 42527, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.1.248 > 192.168.8.1: ICMP echo reply, id 12345, seq 1, length 64
01:42:38.767950 IP (tos 0x0, ttl 63, id 42736, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.1.248 > 192.168.8.1: ICMP echo reply, id 12345, seq 2, length 64
01:42:39.771778 IP (tos 0x0, ttl 63, id 42807, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.1.248 > 192.168.8.1: ICMP echo reply, id 12345, seq 3, length 64
01:42:40.768358 IP (tos 0x0, ttl 63, id 42816, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.1.248 > 192.168.8.1: ICMP echo reply, id 12345, seq 4, length 64
```
I have tested on all versions of 4.15 since 4.15.1.
Comment 1 Stanislav Posonsky 2018-04-13 02:44:28 UTC 
The tunnel started to function as needed after upgrading the kernel to version 4.16.

Thank everyone!
Note You need to log in before you can comment on or make changes to this bug.