https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
Mark Linimon changed:
What|Removed |Added
Keywords||vendor
--
You are receiving this m
On 19.01.2025 04:46, Timothy Pearson wrote:
Forcibly disabling RSS with the IPSec deferred patch seems to have
fixed the issue. Given the wide ranging deleterious effects with RSS
on vs. a bit of IPsec theoretical maximum bandwidth loss with it off,
we'll take the bandwidth hit at the m
Forcibly disabling RSS with the IPSec deferred patch seems to have fixed the
issue. Given the wide ranging deleterious effects with RSS on vs. a bit of
IPsec theoretical maximum bandwidth loss with it off, we'll take the bandwidth
hit at the moment. ;)
Are there any significant concerns
Quick update --tried the IPSec deferred update patch [1], no change.
A few tunables I forgot to include as well:
net.route.netisr_maxqlen: 256
net.isr.numthreads: 32
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 1
net.isr.maxthreads: 32
Hi all,
I've been pulling my hair out over a rather interesting problem that I've
traced into an interaction between IPSec and the rest of the network stack.
I'm not sure if this is a bug or if there's a tunable I'm missing somewhere, so
here goes...
We have a pf
On 2025-01-16 16:57, Vadim Goncharov wrote:
Could you provide technical overview, both from API and packet format side, at
least briefly?
packet format is just regular ipsec, there are no protocol changes required!
API... we're currently thinking the sockaddr_ipsec struct would take a
On Thu, 16 Jan 2025 10:54:50 -0300
"Soni \"It/Its\" L." wrote:
> we would like to propose an experiment where we treat ipsec as an
> address family, similar to tcp/ip or tcp/ipv6 but with tcp/ipsec instead.
>
> traditionally, ipsec is something the sysadmin con
we would like to propose an experiment where we treat ipsec as an
address family, similar to tcp/ip or tcp/ipv6 but with tcp/ipsec instead.
traditionally, ipsec is something the sysadmin configures between
systems. well, nowadays we use wg because the configuration flow is
basically the same
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216681
Alexander Vereeken changed:
What|Removed |Added
Keywords|patch |
--
You are receiving this m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=103135
Eugene Grosbein changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
NVIDIA networking developed support for inline IPSEC offload on
FreeBSD. It consists of the common infrastructure part, and changes
for mlx5en(4) driver fitting the kernel counterpart.
Inline offload moves (almost) all IPSEC processing of the packet from
CPU and crypto accelerators, to the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
Zhenlei Huang changed:
What|Removed |Added
CC||jhar...@widomaker.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
--- Comment #7 from Andrew Cagney ---
(In reply to Zhenlei Huang from comment #6)
Yes the problem is (was) in fping 5.0 packaged by FreeBSD but that is old. The
issue is confirmed fixed in the latest version 5.1. Can fping please be
updat
Me wrote:
> On 15. Jan 2024, at 16:15, Michael Grimm wrote:
>
> Marek Zarychta wrote:
>> W dniu 15.01.2024 o 15:35, Michael Grimm pisze:
>
>>> route_tunnel0="fd00:a:a:a::/64 fd00:a:a:a::254"
>
>> Please try:
>> route_tunnel0="-6 -net fd00:a:a:a::/64 fd00:a:a:a::254"
>
> Bingo! That did the t
Marek Zarychta wrote:
> W dniu 15.01.2024 o 15:35, Michael Grimm pisze:
>> route_tunnel0="fd00:a:a:a::/64 fd00:a:a:a::254"
> Please try:
> route_tunnel0="-6 -net fd00:a:a:a::/64 fd00:a:a:a::254"
Bingo! That did the trick:
Internet6:
Destination Gateway
W dniu 15.01.2024 o 15:35, Michael Grimm pisze:
route_tunnel0="fd00:a:a:a::/64 fd00:a:a:a::254"
Please try:
route_tunnel0="-6 -net fd00:a:a:a::/64 fd00:a:a:a::254"
--
Marek Zarychta
Andrey V. Elsukov wrote:
> ifconfig_ipsec0_ipv6="inet6 fd00:b:b:b::250 fd00:a:a:a::254 prefixlen 128"
Thanks, now do get the tunnel set (after adding the tunnel to your hint):
ifconfig_ipsec0="inet 10.2.2.250 10.1.1.254 tunnel 1.2.3.4 10.20.30.40"
ifconfig_ipsec0_ipv6="inet6 fd00:b:b:
On 15.01.2024 16:09, Michael Grimm wrote:
Hi,
I do use an ipsec tunnel for routing local IPv4 traffic for years now
(/etc/rc.conf):
cloned_interfaces="ipsec0"
static_routes="tunnel0"
create_args_ipsec0="reqid 104"
ifconfig_ipsec0=&quo
Hi,
I do use an ipsec tunnel for routing local IPv4 traffic for years now
(/etc/rc.conf):
cloned_interfaces="ipsec0"
static_routes="tunnel0"
create_args_ipsec0="reqid 104"
ifconfig_ipsec0="inet 10.2.2.250 10.1.1.254 tunnel 1.2.3.4 10.20.30.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
--- Comment #6 from Zhenlei Huang ---
(In reply to Andrew Cagney from comment #4)
> freebsdw# ping -c 1 192.1.2.23
> PING 192.1.2.23 (192.1.2.23): 56 data bytes
> 64 bytes from 192.1.2.23: icmp_seq=0 ttl=64 time=0.XXX ms
> --- 192.1.2.23 pi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
--- Comment #5 from Andrew Cagney ---
I've also posted this up-up-stream
https://groups.google.com/g/fping-users/c/gLzZP3h1a80
--
You are receiving this mail because:
You are the assignee for the bug.
e numbers available!
(expire_timeout=100, host_nr=0, ping_count=0, seqmap_next_id=0)
freebsdw# sleep 5
freebsdw# fping -c 1 192.1.2.23
+192.1.2.23 : [0], 64 bytes, 0.417 ms (0.417 avg, 0% loss)
+192.1.2.23 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.417/0.417/0.417
freebsdw# ipsec start
Redirect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #3 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
Andrew Cagney changed:
What|Removed |Added
Version|13.2-STABLE |14.0-RELEASE
--- Comment #2 from A
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271394
--- Comment #8 from f.muel...@gmx.de ---
Thank you for clarification
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271394
Michael Tuexen changed:
What|Removed |Added
See Also||https://reviews.freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271394
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #7
from f.muel...@gmx.de ---
It seems like this issue is making no progress. We have a stalemate at this
point. As previously reported, Android only supports UDP encapsulation for
IPV6, but FreeBSD currently does not.
As a result, it is not possible to establish IPsec Roadwarrior connections from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Gleb Smirnoff changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
--- Comment #6 from Franco Fichtner ---
Yes, confirmed fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
, Victor Gamov wrote:
> Hi All
>
> I have FreeBSD 13.2-STABLE stable/13-n255939-b9da47180fd6 GENERIC amd64
> machine with strongswan-5.9.11_2 installed by pkg.
>
> When routed ipsec is up all outgoing packets forwarded into ipsec-tunnel
> so networking is immediately fail
Hi All
I have FreeBSD 13.2-STABLE stable/13-n255939-b9da47180fd6 GENERIC amd64
machine with strongswan-5.9.11_2 installed by pkg.
When routed ipsec is up all outgoing packets forwarded into ipsec-tunnel so
networking is immediately fails.
FreeBSD config:
=
net.fibs=4
net.inet.ip.forwarding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
--- Comment #4 from Shawn Anastasio ---
On further inspection, it appears the failure I observed is caused by an
unrelated bug in the virtio network driver rather than IPSec
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268699
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
--- Comment #3 from Shawn Anastasio ---
I am able to reproduce this on -CURRENT on powerpc64le. With a debug kernel
build, I'm hitting the following assertion when flooding an ipsec link between
two VMs using ipsec3 wit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
Graham Perrin changed:
What|Removed |Added
CC||grahamper...@gmail.com
and the aforementioned Intel X520 card. Each of
the X520 cards in each box are directly connected together, with the IPsec link
running across them, and plain-text packets are being forwarded from the igb
interfaces across the tunnel in both directions.
On the Strongswan / IPSec side, the P2 tunnel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
--- Comment #1 from Zhenlei Huang ---
May you please share your setup briefly?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274007
Mark Linimon changed:
What|Removed |Added
Keywords||regression
Assignee|b...@
On 2023-09-15 4:43 AM, mike tancsa wrote:
On 9/15/2023 1:38 AM, Xin Li wrote:
On 2023-09-14 3:28 AM, Kristof Provost wrote:
On 14 Sep 2023, at 4:54, Xin Li wrote:
Hi!
And as a shoot to the dark, I tried again with IPsec (racoon)
disabled, and the issue is gone. My IPsec configuration is
On 9/15/2023 1:38 AM, Xin Li wrote:
On 2023-09-14 3:28 AM, Kristof Provost wrote:
On 14 Sep 2023, at 4:54, Xin Li wrote:
Hi!
And as a shoot to the dark, I tried again with IPsec (racoon)
disabled, and the issue is gone. My IPsec configuration is fairly
common:
I'm still comparin
e82d7b2952afaf9625a3d7b05d03c43c1d3e7d9c and I
can't think it could caused this).
And as a shoot to the dark, I tried again with IPsec (racoon) disabled,
and the issue is gone. My IPsec configuration is fairly common:
===
flush;
spdflush;
spdadd WAN_IP4 REMOTE_IP4 any -P out ipsec esp/t
On 14 Sep 2023, at 4:54, Xin Li wrote:
> Hi!
>
> I recently upgraded my home router and found that there is some regression
> related to pf or IPv6.
>
> When attempting to connect an IPv6 TCP service, process would enter a
> seemingly unkillable state (the stack varies but always begins with writ
Hi!
I recently upgraded my home router and found that there is some
regression related to pf or IPv6.
When attempting to connect an IPv6 TCP service, process would enter a
seemingly unkillable state (the stack varies but always begins with
write, so it seems that tailscale was trying to send
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
--- Comment #1 from Andrew Cagney ---
More data points:
- it isn't ESN; both FreeBSD->linux (ESN=yes) and FreeBSD->NetBSD (ESN=no) show
this
- it isn't aes_gcm; AES_CBC_128-HMAC_SHA1_96 has same behaviour (aes_gcm was
broken in libreswan 4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273533
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
Eugene Grosbein changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #5 f
Author: Konstantin Belousov
AuthorDate: 2023-07-20 12:08:24 +
Commit: Konstantin Belousov
CommitDate: 2023-07-28 01:14:01 +
ip output: ensure that mbufs are mapped if ipsec is enabled
PR: 272616
(cherry picked from commit bc310a95c58a3c570ed7e5103371453881e36ba1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
Mark Linimon changed:
What|Removed |Added
Keywords||crash
--
You are receiving this ma
: Konstantin Belousov
AuthorDate: 2023-07-20 12:08:24 +
Commit: Konstantin Belousov
CommitDate: 2023-07-21 18:51:13 +
ip output: ensure that mbufs are mapped if ipsec is enabled
Ipsec needs access to packet headers to determine if a policy is
applicable. It seems that
--- Comment #14 from Aleksandr Fedorov ---
The main problem is that we don’t know where the mbuf will fly from with the
M_EXTPG flag. Now it's an IPSEC, tomorrow something else. I think all functions
that work with mbuf's should correctly handle unmapped mbuf's.
But as a temporary patc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #13 from Eugene Grosbein ---
(In reply to Eugene Grosbein from comment #5)
I realized that I recently enabled IPMI watchdog and our watchdogd(8) daemon
but loaded ipmi.ko once manually not enabling its load at reboot, so booted
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #12 from Mark Johnston ---
(In reply to Konstantin Belousov from comment #11)
I just wanted to establish the distinction between, "IPSec fundamentally cannot
work with unmapped mbufs," and "IPSec is not yet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #11 from Konstantin Belousov ---
(In reply to Mark Johnston from comment #10)
Your reply is not much different from my evaluation: IPSEC needs complete
audit to ensure that it works with unmapped pages in mbufs. Until this is
generated
by the kernel will live in mapped mbufs that are separate from unmapped data.
To be safer, we could introduce a mbuf function which guarantees that the first
N bytes of the chain are mapped.
m_makespace() needs a bit of work but fundamentally I don't see any problems
with IPSec+unm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #9 from Konstantin Belousov ---
(In reply to Mark Johnston from comment #8)
Is it guaranteed that all protocol headers are mapped?
Anyway, even quick look over the fundamental m_makespace() needed for
ESP injection shows that i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #8 from Mark Johnston ---
(In reply to Konstantin Belousov from comment #7)
I mean, protocol headers (IP, TCP, etc.) are still mapped. More specifically,
each mbuf in a chain can be mapped or not, and the IP header will general
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #7 from Konstantin Belousov ---
(In reply to Mark Johnston from comment #6)
By payload you mean mbuf data, right?
IPSEC needs to match packet IP header against policy to decide should
it do anything with it at all. Then it
Johnston ---
(In reply to Konstantin Belousov from comment #2)
> Really software IPSEC requires mapped mbufs. Even hw inline accel seems to
> need it, unfortunately.
Why is that? At least for sw it's only the payload that is unmapped, and
crypto providers can handle that.
--
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #5 from Eugene Grosbein ---
I was too quick... Indeed, I cannot reproduce the panic with patched kernel,
but the machine started to experience sudden resets without anything printed to
serial console between "Login: " after boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #4 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #3)
The patch did not apply to stable/13, so I applied it manually, rebuilt and
reinstalled GENERIC and it really helped: no more panics even with defaul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #3 from Konstantin Belousov ---
Created attachment 243503
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=243503&action=edit
ipsec: ensure that mbufs are mapped if ipsec is enabled
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
--- Comment #2 from Konstantin Belousov ---
m_unshare() is not enough. Really software IPSEC requires mapped mbufs.
Even hw inline accel seems to need it, unfortunately.
Try something like the attached patch.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
Eugene Grosbein changed:
What|Removed |Added
CC||j...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
Eugene Grosbein changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Eugene Grosbein changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272616
Bug ID: 272616
Summary: [panic] Reproducible kernel panic related to sendfile
and IPSec
Product: Base System
Version: 13.2-STABLE
Hardware: Any
OS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Graham Perrin changed:
What|Removed |Added
Keywords||crash
Severity|Affects O
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271394
Andrey V. Elsukov changed:
What|Removed |Added
See Also||https://reviews.freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Andrey V. Elsukov changed:
What|Removed |Added
Keywords|crash |
Assignee|n...@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
--- Comment #2 from russell.yo...@gmail.com ---
I am using the GENERIC kernel as updated by freebsd-update.
This bug does not occur with sendfile disabled in apache24.
I am testing this using fetch(1) with a 5,279 byte file on server
betwee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Mark Linimon changed:
What|Removed |Added
Keywords||crash
Assignee|b...@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271394
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
Hi,
I'm using FreeBSD stable/13 and strongSwan 5.9. I have configured my
server as IPsec responder. Variadic number of roadwarriors are
connecting to this IPsec server. So both Phase1 and Phase2 connections
are instantiating. IPsec connections could be established without any
errors.
Hi, i am trying to move my gateway from FreeBSD 11.0 to FreeBSD 14.0 to use
newly added ipfw table lookup for mac addresses
(https://reviews.freebsd.org/D35103)
Also I have too many IPSec connections between fortigate, cisco etc.
And their operators use only 3DES algorithms and they have no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
Author: John Baldwin
AuthorDate: 2022-04-27 19:18:52 +
Commit: John Baldwin
CommitDate: 2022-05-20 00:42:24 +
setkey(8): Clarify language around AEAD ciphers.
AEAD ciphers for IPsec combine both encryption and authentication. As
such, ESP configurations using an AEAD
Author: John Baldwin
AuthorDate: 2022-04-27 19:18:52 +
Commit: John Baldwin
CommitDate: 2022-05-20 00:35:34 +
setkey(8): Clarify language around AEAD ciphers.
AEAD ciphers for IPsec combine both encryption and authentication. As
such, ESP configurations using an AEAD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #15 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=dc72e1b86f8ae396215418cdeda037e37df11e98
commit dc72e1b86f8ae396215418cdeda037e37df11e98
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #14 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9132c793cb014e321c92ed502d20df4426492562
commit 9132c793cb014e321c92ed502d20df4426492562
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #33 from Michael Muenz ---
Sorry Franco for adding you to the loop, maybe you can have a look at the
patch.
May be worth to backport to OPNsense kernel :)
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0aef8628458a7d03e3c7e63ae05e228191167eec
commit 0aef8628458a7d03e3c7e63ae05e228191167eec
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #32 from Pawel Zeddi ---
(In reply to Andrey V. Elsukov from comment #31)
Patch is for FreeBSD 14 which means OPNSense will update to this version in few
years. Very inconvenient (to put it mildly).
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #31 from Andrey V. Elsukov ---
(In reply to Pawel Zeddi from comment #30)
The proposed IPSEC_CTLINPUT() was committed in
https://reviews.freebsd.org/D30992
But I did not track which versions contain this code. Probably, some is
from Pawel Zeddi ---
Any update on the issue?
I have 2 OPNSense (Freebsd) machines connected via IPSec tunnel and packets
above some size are dropped from time to time.
IPSec should work "out of the box".
--
You are receiving this mail because:
You are the assignee for the bug.
: John Baldwin
AuthorDate: 2022-04-27 19:18:52 +
Commit: John Baldwin
CommitDate: 2022-04-27 19:23:18 +
setkey(8): Clarify language around AEAD ciphers.
AEAD ciphers for IPsec combine both encryption and authentication. As
such, ESP configurations using an AEAD cipher
d(name) < 0) {
+warn("%s: module not found", name);
+return 0;
+}
+return 1;
+}
+
int
main(ac, av)
int ac;
@@ -167,6 +180,7 @@ main(ac, av)
}
}
+ modload("ipsec");
so
later I have used setkey config files from
https://github.com/freebsd-net/netperf/tree/master/IPSEC/Configs (specifically
the dut-* and source-* configs with one end using dut- and the other end
using source-). The only one that I have not been able to make work is
*-ipcomp.conf.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #9 from Eugene Grosbein ---
(In reply to John Baldwin from comment #8)
> Static keys are not good for AES-GCM or AES-CTR as the sequence number can
> rollover yes.
Maybe it's worth mentioning in the setkey(8), too.
> stable/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #8 from John Baldwin ---
(In reply to Eugene Grosbein from comment #6)
Static keys are not good for AES-GCM or AES-CTR as the sequence number can
rollover yes. Even for AES-CBC I would be hesitant to rely on static keys
rather
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #7 from Eugene Grosbein ---
(In reply to John Baldwin from comment #5)
> In terms of how to inform other users, we could perhaps add a check to
> stable/12 to warn users about using an explicit -A in combination with
> AES-GC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #6 from Eugene Grosbein ---
(In reply to John Baldwin from comment #3)
I was told that aes-gcm-16 should not be used with static keys for anything
other then debugging, so I'm experimenting with -E aes-cbc ... -A hmac-sha2-512
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #5 from John Baldwin ---
I have a review for the manpage at https://reviews.freebsd.org/D34947 (Eugene,
I couldn't add you on the review via your freebsd.org username for some
reason?)
In terms of how to inform other users, we
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #4 from Eugene Grosbein ---
(In reply to John Baldwin from comment #3)
I personally can deal with the problem in multiple ways but this PR is about
migration ways suitable for most users. Yes, please correct setkey(8) manual
pa
ES-GCM combined with some other MAC in stable/13 and later.
For the purposes of upgrading, you could switch your existing 12.x hosts to use
a supported cipher first prior to upgrading. I would suggest just using -E
aes-gcm-16 and dropping the -A entirely.
Unfortunately, the AES-CTR cipher defined
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
--- Comment #2 from Eugene Grosbein ---
(In reply to John Baldwin from comment #1)
I'm not an IPSec expert in any way. I tend to agree that this setup may be
broken, if you say so.
I'm talking about setkey(8) manual page
anywhere of such a construct for IPsec, and the closest thing I can
find (using a non-AEAD cipher with ESP and a separate MAC with AH) is
deprecated in RFC 8221 (the recommended approach is to use the non-AEAD cipher
and MAC together as a combined ETA cipher with ESP, e.g. AES-CBC+SHA-512-HMAC).
I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379
Bug ID: 263379
Summary: [regression] [ipsec] compatibility broken between
stable/12 and stable/13 opencrypto in AEAD mode
Product: Base System
Version: 13.1-STABLE
Hello,
I'm running FreeBSD stable/12. I'm running kea-dhcp server and strongswan.
DHCP Relay packets are received over IPsec, but kea-dhcp couldn't
receive packets while in "raw" socket mode. When the kea-dhcp is
configured to "udp" sockets, DHCP Relay packets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258849
Mateusz Guzik changed:
What|Removed |Added
Assignee|n...@freebsd.org |m...@freebsd.org
--- Comment #9 f
1 - 100 of 1794 matches
Mail list logo
