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=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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Pawel Zeddi changed:
What|Removed |Added
CC||p.ze...@gmail.com
--- Comment #30 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #29 from Victor Sudakov ---
(In reply to Julian Elischer from comment #28)
> I used the multiple routing tables to have different MTU
This is one of the workarounds and we have even discussed something similar in
the comments,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Julian Elischer changed:
What|Removed |Added
CC||jul...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #27 from Victor Sudakov ---
(In reply to Bjoern A. Zeeb from comment #26)
Bjoern, can you formulate in a few own words what behavior you deem appropriate
in accordance with the later RFCs?
I can only say that what we have now
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Bjoern A. Zeeb changed:
What|Removed |Added
CC||b...@freebsd.org
--- Comment #26
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #25 from Victor Sudakov ---
The more I think of it, the more I feel that the idea of removing the DF flag
from ESP packets is incorrect. Because in IPv6, there is no flag to remove. If
an IPv6 packet was not fragmented by the or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #24 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #19)
> I still wait for testing results from Victor.
> If we get good results and agreement with other developers, we ought just
> clear DF unconditionally.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #23 from Victor Sudakov ---
Created attachment 210202
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210202&action=edit
ESP from Windows server to FreeBSD
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #22 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #8)
> Can you enable some TCP service at FreeBSD side (f.e. inetd/echo or ftpd)
> and check it out if Windows sets DF=1 for initial encrypted TCP SYN
> when
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #20 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #15)
I've made a quick and dirty script which I run from the remote block.
It seems that this workaround does work.
#!/bin/sh
if echo $REMOTE_ADDR | grep -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #19 from Eugene Grosbein ---
(In reply to dewayne from comment #18)
Yes, the sysctl is somewhat misnamed but it's for testing only, not considered
as permanent solution. I still wait for testing results from Victor. If we get
g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #18 from dewa...@heuristicsystems.com.au ---
(In reply to Eugene Grosbein from comment #16)
I thought that there was a convention regarding sysctl naming format. Should
net.inet.ipsec.trans.cleardf be net.inet.ipsec.trans_clear
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #17 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #16)
Eugene, could you make "no DF bit" the default behavior? Without the DF bit,
transport mode will work "out of the box" in a vanilla configuration.
If so
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #16 from Eugene Grosbein ---
Created attachment 210122
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210122&action=edit
net.inet.ipsec.trans.cleardf
For testing: new sysctl net.inet.ipsec.trans.cleardf is zero by de
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #15 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #14)
Routing lookup can be performed within shell script, too:
gw=$(route -n get "$REMOTE_ADDR" | awk '/gateway: / {print $2}')
As for ipfw. First, ipfw ne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #14 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #11)
> you can use phase1 up-script to create specific routes
A clever idea. A host route to $REMOTE_ADDR via... via what? Maybe sourcing
rc.conf for $defaul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #13 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #5)
> Or I'll try if you provide an example of matching such a packet.
This works for me:
ipfw add tcp-setmss 1418 tcp from any to 'table(1)' tcpflags syn
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #12 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #10)
Windows 7 should be fine. I don't think newer versions of Windows have a
regression dealing with DF bit.
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #11 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #9)
It does scale: with racoon, you can use phase1 up-script to create specific
routes with -mtu 1400 automatically.
--
You are receiving this mail because
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #10 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #8)
> check it out if Windows sets DF=1 for initial encrypted TCP SYN
My FreeBSD - Windows7 IPSec configuration is gone with my Windows7 workstation.
If it h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #9 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #7)
> It's possible to perform routing lookup for any reachable destination IP
> address to discover transmit MTU and deduce right MSS.
Yes, this (or simila
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #8 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #5)
>In a FreeBSD - Windows 7 combination, this kind of transport mode works
> transparently out of the box. I think Windows knows to adjust MSS, or
> somet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #7 from Eugene Grosbein ---
(In reply to Victor Sudakov from comment #5)
> I don't think I can if the packet in question is not received or transmitted
> via any interface (like locally generated ssh-client traffic intercepted
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #6 from Eugene Grosbein ---
OTOH, RFC 2401 Appendix B https://tools.ietf.org/html/rfc2401#page-1-48 states
that packets generated by IPSec transport mode must be allowed to fragment over
the path and this is incompatible with cu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #5 from Victor Sudakov ---
(In reply to Eugene Grosbein from comment #4)
> First, one can use IPSec transport mode combined with gif tunnel and mtu=1500
> for the gif.
The solution with gif or if_ipsec tunnels is not scalabl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
--- Comment #3 from Victor Sudakov ---
(In reply to dewayne from comment #2)
I don't quite understand the second part of your question, the problem is not
within ISAKMP. ISAKMP works fine. The problem with TCP begins later, when all
SA are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
32 matches
Mail list logo
