Fw: [Bug 199121] New: Packet header is incorrect when following through an IPsec tunnel after upgrade kernel to 4.15

Fw: [Bug 199121] New: Packet header is incorrect when following through an IPsec tunnel after upgrade kernel to 4.15

[Stephen Hemminger]

Begin forwarded message:

Date: Thu, 15 Mar 2018 06:37:27 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@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: stephen@networkplumber.org
          Reporter: posonsky@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.
```
# 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Fw: [Bug 199121] New: Packet header is incorrect when following through an IPsec tunnel after upgrade kernel to 4.15

[Steffen Klassert]

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-daemon@bugzilla.kernel.org
> To: stephen@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: stephen@networkplumber.org
>           Reporter: posonsky@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")