Bug 282535 - if_ipsec mtu seems to be 1422 for ipv6
Summary: if_ipsec mtu seems to be 1422 for ipv6
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 14.1-RELEASE
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-04 11:43 UTC by bugs.freebsd.org
Modified: 2024-12-02 10:47 UTC (History)
4 users (show)

See Also:

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

Note You need to log in before you can comment on or make changes to this bug.
Description bugs.freebsd.org 2024-11-04 11:43:50 UTC 
I have two FreeBSD connected via the 'if_ipsec' interfaces named 'vpn1' and mtu=1500 on the both sides.


Before update:

ping6 -D -s 1452 ff02::1%vpn1
PING6(1500=40+8+1452 bytes) fe80::9b26:3731:f02d:4768%vpn1 --> ff02::1%vpn1
1460 bytes from fe80::9b26:3731:f02d:4768%vpn1, icmp_seq=0 hlim=64 time=0.178 ms
1460 bytes from fe80::bfc0:65e8:dd5a:8d3c%vpn1, icmp_seq=0 hlim=64 time=4.706 ms(DUP!)
...


After update from 11.2-RELEASE to 14.1-RELEASE:

ping6 -D -s 1374 ff02::1%vpn1
PING(1422=40+8+1374 bytes) fe80::7842:9f3d:a7df:4ae5%vpn1 --> ff02::1%vpn1
1382 bytes from fe80::7842:9f3d:a7df:4ae5%vpn1, icmp_seq=0 hlim=64 time=0.208 ms
1382 bytes from fe80::bfc0:65e8:dd5a:8d3c%vpn1, icmp_seq=0 hlim=64 time=4.854 ms(DUP!)
...

ping6 -D -s 1375 ff02::1%vpn1
PING(1423=40+8+1375 bytes) fe80::7842:9f3d:a7df:4ae5%vpn1 --> ff02::1%vpn1
1383 bytes from fe80::7842:9f3d:a7df:4ae5%vpn1, icmp_seq=0 hlim=64 time=0.147 ms
1383 bytes from fe80::7842:9f3d:a7df:4ae5%vpn1, icmp_seq=1 hlim=64 time=0.080 ms
1383 bytes from fe80::7842:9f3d:a7df:4ae5%vpn1, icmp_seq=2 hlim=64 time=0.095 ms
...
there is no answer or ICMP error message.
This issue affects any protocols and addresses also as link-local.
Comment 1 Lexi Winter freebsd_triage 2024-11-05 13:18:20 UTC 
Alexander: did you mean to cc me on this?  i have never touched this code and know nothing about it.
Comment 2 Alexander Ziaee freebsd_triage 2024-11-05 14:23:25 UTC 
Yes, thought you might find it interesting; sorry for the disruption.
Comment 3 Andrey V. Elsukov freebsd_committer freebsd_triage 2024-11-23 10:29:13 UTC 
I also found this recently and now trying to find what changed.
Comment 4 commit-hook freebsd_committer freebsd_triage 2024-11-25 17:51:39 UTC 
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=c94d6389e428fac55946bfcdbbc3162c06a9278e

commit c94d6389e428fac55946bfcdbbc3162c06a9278e
Author:     Andrey V. Elsukov <ae@FreeBSD.org>
AuthorDate: 2024-11-25 17:42:00 +0000
Commit:     Andrey V. Elsukov <ae@FreeBSD.org>
CommitDate: 2024-11-25 17:42:00 +0000

    ipsec: fix IPv6 over IPv4 tunneling.

    Properly initialize setdf variable in ipsec_encap().
    It is used for AF_INET6 case when IPv6 datagram is going to be
    encapsulated into IPv4 datagram.

    PR:             282535
    Fixes:          4046178557e1
    MFC after:      1 week

 sys/netipsec/ipsec_output.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)
Comment 5 commit-hook freebsd_committer freebsd_triage 2024-12-02 10:25:57 UTC 
A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=628e76a986b9621199e77730eebfdb8e0e43c945

commit 628e76a986b9621199e77730eebfdb8e0e43c945
Author:     Andrey V. Elsukov <ae@FreeBSD.org>
AuthorDate: 2024-11-25 17:42:00 +0000
Commit:     Andrey V. Elsukov <ae@FreeBSD.org>
CommitDate: 2024-12-02 10:24:03 +0000

    ipsec: fix IPv6 over IPv4 tunneling.

    Properly initialize setdf variable in ipsec_encap().
    It is used for AF_INET6 case when IPv6 datagram is going to be
    encapsulated into IPv4 datagram.

    PR:             282535
    Fixes:          4046178557e1

    (cherry picked from commit c94d6389e428fac55946bfcdbbc3162c06a9278e)

 sys/netipsec/ipsec_output.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)