https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Ziomalski changed:
What|Removed |Added
Resolution|Not A Bug |FIXED
--- Comment #23 from Ziomalski
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #22 from Michael Muenz ---
(In reply to Eugene Grosbein from comment #21)
Sure, they can. This is only related to *sense, so closing this one here is
just fine.
Thanks for all your efforts.
--
You are receiving this mail beca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |Not A Bug
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #21 from Eugene Grosbein ---
(In reply to Michael Muenz from comment #20)
Route-based and legacy policy-based IPsec tunnels co-exist just find on the
same system.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #20 from Michael Muenz ---
I have not tested too deeply but there *may* be strange side effects when using
filtering and NAT (SPD) when using route-based and legacy policy-based IPsec
tunnels on the same system.
If the *sense i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #19 from Ziomalski ---
(In reply to Andrey V. Elsukov from comment #17)
WOW. Thank you Andrey. I was able to get a connection after adding these
changes. pfSense 2.4.5.
I'm going to be doing more testing and hopefully get it in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #18 from Michael Muenz ---
(In reply to Andrey V. Elsukov from comment #17)
Beautiful Andrey, really nice! That did it for OPNsense (pfSense for sure too).
I'll add a note to the documentation to set a tunable.
--
You are re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #17 from Andrey V. Elsukov ---
Did you tried disable if_enc's pfil handling?
% sysctl net.enc | grep filter
net.enc.out.ipsec_filter_mask: 0
net.enc.in.ipsec_filter_mask: 0
Also you can try enable filtertunnel variable
% sys
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #16 from Eugene Grosbein ---
(In reply to Michael Muenz from comment #14)
Every transit packet coming from LAN to WAN first passes pfil hooks as incoming
packet before routing lookup for destination, then routing lookup is perf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #15 from Eugene Grosbein ---
(In reply to Michael Muenz from comment #14)
The patch could help only if unpached system shows growing counters in the
output of: netstat -sp ipsec|fgrep "inbound packets violated"
If you have pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #14 from Michael Muenz ---
(In reply to Eugene Grosbein from comment #4)
I added the patch and build a new pkg, but it doesn't change anything.
Can see the translated packets but no ESP packets leaving WAN.
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #13 from Eugene Grosbein ---
(In reply to Andrey V. Elsukov from comment #11)
IPSec code adds PACKET_TAG_IPSEC_IN_DONE tag to decrypted mbuf then calls pfil
hooks. Bad things could happen if mbuf looses PACKET_TAG_IPSEC_IN_DONE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #12 from Andrey V. Elsukov ---
(In reply to Andrey V. Elsukov from comment #11)
Probably you need to disable if_enc's pfil handling to avoid some confusions.
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #11 from Andrey V. Elsukov ---
(In reply to Eugene Grosbein from comment #10)
I have very basic knowledge about PF's internals, but I don't think the problem
is with if_ipsec, it does nothing special after decryption, PF will s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #10 from Eugene Grosbein ---
(In reply to Andrey V. Elsukov from comment #9)
Your notes are relevant for problems with outgoing traffic. Are they relevant
for incoming traffic that is decrypted before it hits pfil hooks and the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Andrey V. Elsukov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Michael Muenz changed:
What|Removed |Added
CC||m.mu...@gmail.com
--- Comment #8 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #7 from Andrey V. Elsukov ---
if_ipsec works with ipfw's NAT, we have many of such installations for years.
I think you use PF and it won't work in some configurations, because of its
design and how IPsec handled in FreeBSD.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Eugene Grosbein changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #5 from Eugene Grosbein ---
Also, it would be nice if you use unpatched system that exhibits the problem to
monitor output of:
netstat -sp ipsec|fgrep "inbound packets violated"
Look if the counter grows when you try passing t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #4 from Eugene Grosbein ---
Created attachment 217021
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=217021&action=edit
strongswan work-around patch
Also, it is possible you hit obscure problem in kernel+strongswan c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
--- Comment #3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #2 from Ziomalski ---
(In reply to crest from comment #1)
The reason I posted here was because of the following pfSense Dev response:
https://forum.netgate.com/topic/155803/nat-still-broken-on-ipsec-vti/2
I am currently on pfS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
24 matches
Mail list logo
