* Fw: [Bug 216557] New: tcp connection not working over ip_vti interface
@ 2022-10-07 21:17 Stephen Hemminger
2022-10-11 9:03 ` Fw: [Bug 216557] New: tcp connection not working over ip_vti interface #forregzbot Thorsten Leemhuis
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2022-10-07 21:17 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 07 Oct 2022 20:51:12 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
Subject: [Bug 216557] New: tcp connection not working over ip_vti interface
https://bugzilla.kernel.org/show_bug.cgi?id=216557
Bug ID: 216557
Summary: tcp connection not working over ip_vti interface
Product: Networking
Version: 2.5
Kernel Version: 5.15.53
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: monil191989@gmail.com
Regression: No
TCP protocol is not working, when ipsec tunnel has been setup and ip_vti tunnel
is used for route based ipsec.
After the below changes merged with latest kernel. xfrm4_policy_check in
tcp_v4_rcv drops all packets except first syn packet under XfrmInTmplMismatch
when local destined packets are received over ip_vti tunnel.
author Eyal Birger <eyal.birger@gmail.com> 2022-05-13 23:34:02 +0300
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-05-25
09:57:30 +0200
commit 952c2464963895271c31698970e7ec1ad6f0fe45 (patch)
tree 9e8300c45a0eb5a9555eae017f8ae561f3e8bc51 /include/net/xfrm.h
parent 36d8cca5b46fe41b59f8011553495ede3b693703 (diff)
download linux-952c2464963895271c31698970e7ec1ad6f0fe45.tar.gz
xfrm: fix "disable_policy" flag use when arriving from different devices
setup:
1) create road warrior ipsec tunnel with local ip x.x.x.x remote ip y.y.y.y.
2) create vti interface using ip tunnel add vti_test local x.x.x.x remote
y.y.y.y mode vti
3) echo 1 > /proc/sys/net/ipv4/conf/vti_test/disable_policy
4) Add default route over vti_test.
5) ping remote ip, ping works.
6) ssh remote ip, ssh dont work. check tcp connection not working.
Root cause:
-> with above mentioned commit, now xfrm4_policy_check depends on skb's
IPSKB_NOPOLICY flag which need to be set per skb and it only gets set in
ip_route_input_noref .
-> before above change, xfrm4_policy_check was using DST_NOPOLICY which was
checked against dst set in skb.
-> ip_rcv_finish_core calls ip_route_input_noref only if dst is not valid in
skb.
-> By default in kernel sysctl_ip_early_demux = 1, which means when skb with
syn is received, tcp stack will set DST from skb to sk and in subsequent
packets it will copy dst from sk to skb and skip calling ip_route_input_nore
inside ip_rcv_finish_core.
-> so for all the subsequent received packets, IPSKB_NOPOLICY will not get set
and they will get drop.
workaround:
only work-aroud is to disable early tcp demux.
echo 0 > /proc/sys/net/ipv4/ip_early_demux
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fw: [Bug 216557] New: tcp connection not working over ip_vti interface #forregzbot
2022-10-07 21:17 Fw: [Bug 216557] New: tcp connection not working over ip_vti interface Stephen Hemminger
@ 2022-10-11 9:03 ` Thorsten Leemhuis
2022-11-15 9:58 ` Thorsten Leemhuis
0 siblings, 1 reply; 3+ messages in thread
From: Thorsten Leemhuis @ 2022-10-11 9:03 UTC (permalink / raw)
To: netdev, regressions@lists.linux.dev
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]
[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 07.10.22 23:17, Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Fri, 07 Oct 2022 20:51:12 +0000
> From: bugzilla-daemon@kernel.org
> To: stephen@networkplumber.org
> Subject: [Bug 216557] New: tcp connection not working over ip_vti interface
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=216557
>
> Bug ID: 216557
> Summary: tcp connection not working over ip_vti interface
> Product: Networking
> Version: 2.5
> Kernel Version: 5.15.53
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> Assignee: stephen@networkplumber.org
> Reporter: monil191989@gmail.com
> Regression: No
>
> TCP protocol is not working, when ipsec tunnel has been setup and ip_vti tunnel
> is used for route based ipsec.
>
> After the below changes merged with latest kernel. xfrm4_policy_check in
> tcp_v4_rcv drops all packets except first syn packet under XfrmInTmplMismatch
> when local destined packets are received over ip_vti tunnel.
>
> author Eyal Birger <eyal.birger@gmail.com> 2022-05-13 23:34:02 +0300
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-05-25
> 09:57:30 +0200
> commit 952c2464963895271c31698970e7ec1ad6f0fe45 (patch)
> tree 9e8300c45a0eb5a9555eae017f8ae561f3e8bc51 /include/net/xfrm.h
> parent 36d8cca5b46fe41b59f8011553495ede3b693703 (diff)
> download linux-952c2464963895271c31698970e7ec1ad6f0fe45.tar.gz
> xfrm: fix "disable_policy" flag use when arriving from different devices
>
>
> setup:
> 1) create road warrior ipsec tunnel with local ip x.x.x.x remote ip y.y.y.y.
> 2) create vti interface using ip tunnel add vti_test local x.x.x.x remote
> y.y.y.y mode vti
> 3) echo 1 > /proc/sys/net/ipv4/conf/vti_test/disable_policy
> 4) Add default route over vti_test.
> 5) ping remote ip, ping works.
> 6) ssh remote ip, ssh dont work. check tcp connection not working.
>
> Root cause:
> -> with above mentioned commit, now xfrm4_policy_check depends on skb's
> IPSKB_NOPOLICY flag which need to be set per skb and it only gets set in
> ip_route_input_noref .
>
> -> before above change, xfrm4_policy_check was using DST_NOPOLICY which was
> checked against dst set in skb.
>
> -> ip_rcv_finish_core calls ip_route_input_noref only if dst is not valid in
> skb.
>
> -> By default in kernel sysctl_ip_early_demux = 1, which means when skb with
> syn is received, tcp stack will set DST from skb to sk and in subsequent
> packets it will copy dst from sk to skb and skip calling ip_route_input_nore
> inside ip_rcv_finish_core.
>
> -> so for all the subsequent received packets, IPSKB_NOPOLICY will not get set
> and they will get drop.
>
> workaround:
> only work-aroud is to disable early tcp demux.
> echo 0 > /proc/sys/net/ipv4/ip_early_demux
Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:
#regzbot introduced e6175a2ed1f1 ^
https://bugzilla.kernel.org/show_bug.cgi?id=216557
#regzbot title [Bug 216557] New: tcp connection not working over ip_vti
interface
#regzbot monitor:
https://lore.kernel.org/all/20221009191643.297623-1-eyal.birger@gmail.com/
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fw: [Bug 216557] New: tcp connection not working over ip_vti interface #forregzbot
2022-10-11 9:03 ` Fw: [Bug 216557] New: tcp connection not working over ip_vti interface #forregzbot Thorsten Leemhuis
@ 2022-11-15 9:58 ` Thorsten Leemhuis
0 siblings, 0 replies; 3+ messages in thread
From: Thorsten Leemhuis @ 2022-11-15 9:58 UTC (permalink / raw)
To: netdev, regressions@lists.linux.dev
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]
On 11.10.22 11:03, Thorsten Leemhuis wrote:
> On 07.10.22 23:17, Stephen Hemminger wrote:
>
>> Begin forwarded message:
>>
>> Date: Fri, 07 Oct 2022 20:51:12 +0000
>> From: bugzilla-daemon@kernel.org
>> To: stephen@networkplumber.org
>> Subject: [Bug 216557] New: tcp connection not working over ip_vti interface
>>
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=216557
#regzbot fixed-by: 3a5913183aa1
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-11-15 9:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-07 21:17 Fw: [Bug 216557] New: tcp connection not working over ip_vti interface Stephen Hemminger
2022-10-11 9:03 ` Fw: [Bug 216557] New: tcp connection not working over ip_vti interface #forregzbot Thorsten Leemhuis
2022-11-15 9:58 ` Thorsten Leemhuis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox