Ccing the reporter of this bug.
On Thu, Mar 15, 2018 at 07:59:51AM -0700, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Thu, 15 Mar 2018 06:37:27 +0000
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 199121] New: Packet header is incorrect when following through
> an IPsec tunnel after upgrade kernel to 4.15
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=199121
>
> Bug ID: 199121
> Summary: Packet header is incorrect when following through an
> IPsec tunnel after upgrade kernel to 4.15
> Product: Networking
> Version: 2.5
> Kernel Version: 4.15.9
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: step...@networkplumber.org
> Reporter: poson...@yandex.ru
> Regression: No
>
> 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.
Can you please try to revert the following patch:
5efec5c655dd ("xfrm: Fix eth_hdr(skb)->h_proto to reflect inner IP version")
In case of IPv4, this writes 0x0800 to the h_proto field
of the ethernet header. The h_proto field has an offset
of 12 bytes in the ethernet header. I bet that the MAC
header is not set in your case and we write this to
the IPv4 header instead. The src address in the IPv4
header has 12 bytes offset too, so I think that's why
the src address is reported with 8.0.1.248.
Please also try thre current 'net' tree, it has a fix
for this issue. It should be fixed with:
87cdf3148b11 ("xfrm: Verify MAC header exists before overwriting
eth_hdr(skb)->h_proto")
