https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
Andrey V. Elsukov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In Pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=628e76a986b9621199e77730eebfdb8e0e43c945
commit 628e76a986b9621199e77730eebfdb8e0e43c945
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274469
Eugene Grosbein changed:
What|Removed |Added
Component|kern|Individual Port(s)
Pr
#2 from Eugene Grosbein ---
Created attachment 255476
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255476&action=edit
working example creating per-connection if_ipsec interfaces
Read stock strongswan docs carefully, use reqid=0 and this example script for
updown parameter
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
Alexander Ziaee changed:
What|Removed |Added
Status|New |In Progress
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=c94d6389e428fac55946bfcdbbc3162c06a9278e
commit c94d6389e428fac55946bfcdbbc3162c06a9278e
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
--- Comment #2 from Alexander Ziaee ---
Yes, thought you might find it interesting; sorry for the disruption.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
--- Comment #1 from Lexi Winter ---
Alexander: did you mean to cc me on this? i have never touched this code and
know nothing about it.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282535
Alexander Ziaee changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are rec
faces in general
(if_id) vs changes to if_ipsec).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274469
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
x
net.inet6.ipsec6.filtertunnel = 0x
net.enc.out.ipsec_bpf_mask= 0x0001
net.enc.out.ipsec_filter_mask = 0x0001
net.enc.in.ipsec_bpf_mask = 0x0002
net.enc.in.ipsec_filter_mask = 0x0002
For if_ipsec filtering:
net.inet.ipsec.filtertunnel = 0x0001
net.inet6.ipsec6.filtertunnel = 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #38 from Kevin Ong ---
See Jim's reply on my thread here:
https://forum.netgate.com/topic/159252/ipsec-outbound-nat-to-interface-address-reply-traffic-destination-ip-not-being-translated-back-to-original-source-ip/21?_=1614663
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #37 from jeremy.mordk...@riftio.com ---
(In reply to jeremy.mordkoff from comment #36)
To prove this to myself, I rebooted the "CORE" router. This caused the sysctl
settings to be lost.
The old LAN-LAN tunnel started working a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #36 from jeremy.mordk...@riftio.com ---
(In reply to jeremy.mordkoff from comment #35)
I should have mentioned PF Sense 2.4.5-RELEASE-p1
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
jeremy.mordk...@riftio.com changed:
What|Removed |Added
CC||jeremy.mordk...@riftio.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #31 from Eugene Grosbein ---
(In reply to jimp from comment #30)
With ipfw you don't even need to filter on enc pseudo-interface.
--
You are receiving this mail because:
You are the assignee for the bug.
_
in pf
(and presumably others) which attempt to filter directly on if_ipsec interfaces
while filtering is also active on the enc interface.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #29 from Michael Muenz ---
(In reply to Eugene Grosbein from comment #27)
Indeed, the problem description should be adjusted that "only" NAT via pf is
affected.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #28 from Eugene Grosbein ---
(In reply to Eugene Grosbein from comment #27)
Forgot to note, I use FreeBSD 11.4.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
--- Comment #27 from Eugene Grosbein ---
(In reply to Ziomalski from comment #26)
This is not true: "It is currently not possible to simultanously have Routed
IPsec with NAT and Policy IPsec". I have both ipsec-tools/racoon running as
IKEv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
Ziomalski changed:
What|Removed |Added
Status|Closed |Open
Severity|Affects Only M
#25 from j...@netgate.com ---
The suggested corrections in this issue only solve the problem for a small
number of cases. Sacrificing filtering on enc in favor of if_ipsec isn't viable
if someone needs both policy-based and route-based IPsec tunnels to different
peers at the same time. The numb
Summary|NAT broken on IPsec/VTI |if_ipsec: NAT broken on
|[if_ipsec] |IPsec/VTI
Resolution|FIXED |Not A Bug
--- Comment #24 from Kubilay Kocak ---
^Triage: Correct resolution, FIXED is for resolution by way of a change
(usually a
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 decryptio
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
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
On 28.04.2019 14:50, driesm.michi...@gmail.com wrote:
> Was wondering if it's possible to set-up a route based IPSec VPN with
> Strongswan with if_ipsec in FreeBSD?
We use if_ipsec(4) with Strongswan between offices. But our
configuration is specific. All if_ipsec(4) interfaces are pr
Hi net mailing list,
Was wondering if it's possible to set-up a route based IPSec VPN with
Strongswan with if_ipsec in FreeBSD?
The caveat that I have are dynamic IP addresses (server (I have DDNS) +
clients (roadwarriors; mobile, tablet, etc)).
How should one configure the if_
Mike Tancsa wrote this message on Fri, Aug 10, 2018 at 16:44 -0400:
> On 8/9/2018 4:11 PM, David P. Discher wrote:
> > [ pts/0 sjc2 util201:~ ]
> > [ dpd ] > sudo setkey -D
> > Password:
> > 10.245.0.201 10.245.0.202
> > esp mode=tunnel spi=60080461(0x0394c14d) reqid=12(0x000c)
> > E: r
David P. Discher wrote this message on Thu, Aug 09, 2018 at 13:11 -0700:
> The documentation for using IPSec (especially if_ipsec) is really thin for
> freebsd, so I pieced some of this together from various posts and mailing
> lists threads.
>
> Is there no need for racoon
On 8/9/2018 4:11 PM, David P. Discher wrote:
> [ pts/0 sjc2 util201:~ ]
> [ dpd ] > sudo setkey -D
> Password:
> 10.245.0.201 10.245.0.202
> esp mode=tunnel spi=60080461(0x0394c14d) reqid=12(0x000c)
> E: rijndael-cbc 79e053a5 221c6d48 31e4c98a 3ae8c8ed
pair of C3558s, using
just AES-GCM w/AES-NI. This is with 'pf' on, and KPI mitigations running,
btw.
If anything, i'd expect routed ipsec to be a bit faster.
Jim
On Thu, Aug 9, 2018 at 3:55 PM, Andrey V. Elsukov wrote:
> On 09.08.2018 23:11, David P. Discher wrote:
> >
On 09.08.2018 23:11, David P. Discher wrote:
> The documentation for using IPSec (especially if_ipsec) is really thin
> for freebsd, so I pieced some of this together from various posts and
> mailing lists threads.
>
> Is there no need for racoon ? How in this example is the IKE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #14 from Andrey V. Elsukov ---
(In reply to dpd from comment #13)
> I showed over here :
> https://lists.freebsd.org/pipermail/freebsd-net/2018-August/051301.html
>
> That it seems to work with this line removed.
>
> Attached
The documentation for using IPSec (especially if_ipsec) is really thin for
freebsd, so I pieced some of this together from various posts and mailing lists
threads.
Is there no need for racoon ? How in this example is the IKE/ISAKMP setup
done ? Is setkey doing this ?
> On Aug 9, 2018,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #13 from d...@dpdtech.com ---
I showed over here :
https://lists.freebsd.org/pipermail/freebsd-net/2018-August/051301.html
That it seems to work with this line removed.
Attached is the shell transcript of my current observation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #12 from d...@dpdtech.com ---
Created attachment 196035
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196035&action=edit
Shell Transcript of Issue.
--
You are receiving this mail because:
You are on the CC list for
David P. Discher wrote this message on Thu, Aug 09, 2018 at 00:00 -0700:
>
> > On Aug 8, 2018, at 10:37 PM, Andrey V. Elsukov wrote:
> >
> > On 09.08.2018 06:57, David P. Discher wrote:
> >> I???m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel.
> >> Is this correct ?
> >
>
On 09.08.2018 10:00, David P. Discher wrote:
> [ pts/0 sjc2 util201:~ ]
> [ dpd ] > iperf3 -c 10.245.0.202 -i 8 -t 16
> Connecting to host 10.245.0.202, port 5201
> [ 5] local 10.245.0.201 port 55165 connected to 10.245.0.202 port 5201
> [ ID] Interval Trans
> On Aug 8, 2018, at 10:37 PM, Andrey V. Elsukov wrote:
>
> On 09.08.2018 06:57, David P. Discher wrote:
>> I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is
>> this correct ?
>
> IPsec uses crypto(9) framework that works by default without any
> acceleration. You need
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #11 from d...@dpdtech.com ---
(In reply to Andrey V. Elsukov from comment #10)
Yes. Ironically ... I just reproduced this with bare metal just a few hours
ago - but only between FreeBSD machines. Now that I have it "working" ..
On 09.08.2018 06:57, David P. Discher wrote:
> I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is
> this correct ?
IPsec uses crypto(9) framework that works by default without any
acceleration. You need to load aesni(4) kernel module to enable
acceleration. Also, you need
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #10 from Andrey V. Elsukov ---
(In reply to dpd from comment #9)
> This change breaks ICMP ECHO (pings) to the receiving end of peer to peer
> /30 of the IPsec tunnel between FreeBSD and Juniper JunOS on their SRX
> products.
>
09.08.2018 10:57, David P. Discher wrote:
> I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is
> this correct ?
>
> A small system, with an Atom C2758 and AESNI can hit 940-950 Mbps on a 1g
> copper link SCPing a file with Chiper=aes256-gcm. SSH/OpenSSL automatically
I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is this
correct ?
A small system, with an Atom C2758 and AESNI can hit 940-950 Mbps on a 1g
copper link SCPing a file with Chiper=aes256-gcm. SSH/OpenSSL automatically
uses AESNI if available. (Side Note, loading cryptod
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
d...@dpdtech.com changed:
What|Removed |Added
CC||d...@dpdtech.com
--- Comment #9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Andrey V. Elsukov changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Rodney W. Grimes changed:
What|Removed |Added
CC||n...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Kubilay Kocak changed:
What|Removed |Added
Assignee|n...@freebsd.org |a...@freebsd.org
Stat
change from r272770 to if_ipsec(4) interface.
It is guaranteed that if_ipsec(4) interface is used only for tunnel
mode IPsec, i.e. decrypted and decapsulated packet has its own IP header.
Thus we can consider it as new packet and clear the protocols flags.
This allows ICMP/ICMPv6
it comes down to the SPD entries. That
is also the main reason I am writing this, maybe it will help someone at
some point.
When if_ipsec is used, automatic entries in the SPD are made (for 0.0.0.0/0
<-> 0.0.0.0/0 via ipsecX). That works, because everything that ends up on
ipsecX sho
ly revers IPsec transform to the packet. Then the kernel
checks, that there is some security policy for that packet.
Now how if_ipsec(4) works. Security policies associated with interface
have configured requirements for tunnel mode with configured addresses.
Interfaces are designed for route base
Hi,
I have mixed types of configurations. I’ll give it a run next week.
So far I have tried a tunnel with if_ipsec and strongswan at one end and gif
and racoon at the other end. I have tried if_ipsec with strongswan on both ends.
I’ll start with recompiling racoon today and using it to see if
On 08.05.2018 16:51, Andrey V. Elsukov wrote:
> I think for proper support of several if_ipsec interfaces racoon needs
> some patches. But I have not spare time to do this job.
> I recommend to use strongswan, it has active developers that are
> responsive and may give some help a
On 13.05.2018 02:37, Andreas Scherrer wrote:
> My interpretation of [2]'s statement:
>
> "If no security association is found, the packet is put on hold and the
> IKE daemon is asked to negotiate an appropriate one."
>
> is that it should somehow be automagic. But in my current configuration,
> t
Hi
I am trying to configure a site to site VPN using the (new?) if_ipsec
interfaces [1]. One endpoint is FreeBSD 11.1-RELEASE whereas the other
will be a RPi (Raspbian 9.4 stretch running libreswan).
The public IPs involved are all IPv6 and the goal is to tunnel IPv4 traffic.
Currently I am
if_ipsec(4) interface.
It is guaranteed that if_ipsec(4) interface is used only for tunnel
mode IPsec, i.e. decrypted and decapsultaed packet has its own IP header.
Thus we can consider it as new packet and clear the protocols flags.
This allows ICMP/ICMPv6 properly handle errors that may
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #4 from bugs.freebsd@mx.zzux.com ---
Thank you! I was applied this patch and it seems to be ok.
icmpv6&v4 errors via if_ipsec:
1240 bytes from 2a02:::::451a:5763: Packet too big mtu = 1480
36 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #3 from Andrey V. Elsukov ---
Created attachment 193277
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193277&action=edit
Proposed patch
Can you try this patch? You need to rebuild the kernel.
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Andrey V. Elsukov changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
time=0.410 ms
Is gif over if_ipsec the only reliable way to create encrypted ipv6 tunnel
without need of install extra software?
Pure ipv6 over if_ipsec is limited in use because of dropping 'packet_too_big'
messages.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
ode. A packet has embedded SPI, it is used for
>> security association lookup. If corresponding SA is found, the IPsec
>> code will apply revers IPsec transform to the packet. Then the kernel
>> checks, that there is some security policy for that packet.
>>
>> Now how if
be
handled by IPsec code. A packet has embedded SPI, it is used for
security association lookup. If corresponding SA is found, the IPsec
code will apply revers IPsec transform to the packet. Then the kernel
checks, that there is some security policy for that packet.
Now how if_ipsec(4) works
be
handled by IPsec code. A packet has embedded SPI, it is used for
security association lookup. If corresponding SA is found, the IPsec
code will apply revers IPsec transform to the packet. Then the kernel
checks, that there is some security policy for that packet.
Now how if_ipsec(4) works. Securi
g old SAs.
>> I think your configuration will work, if you first will done if_ipsec(4)
>> configuration, then start racoon and it will generate SAs.
>> To clear all old/stale configured SAs you can first stop racoon, then
>> run `setkey -DF` and `setkey -DPF`.
>
> Hi Andrey
>
On 23/04/2018 15:43, Andrey V. Elsukov wrote:
Your security associations doesn't match your security policies.
Probably you did interfaces reconfiguration without clearing old SAs.
I think your configuration will work, if you first will done if_ipsec(4)
configuration, then start racoon a
ffc
> nd6 options=29
> reqid: 26
> groups: ipsec
Your security associations doesn't match your security policies.
Probably you did interfaces reconfiguration without clearing old SAs.
I think your configuration will work, if you first will done if_ipsec(4)
configuration, t
On 23/04/2018 14:13, Andrey V. Elsukov wrote:
On 21.04.2018 19:16, Victor Gamov wrote:
When I change ipsec-interfaces creation order then only last created
interface worked fine again and previously configured interfaces does
not work.
And very interesting fact: when I ping from remote 10.10.9
On 21.04.2018 19:16, Victor Gamov wrote:
> When I change ipsec-interfaces creation order then only last created
> interface worked fine again and previously configured interfaces does
> not work.
>
>
> And very interesting fact: when I ping from remote 10.10.98.5 for
> example to FreeBSD 10.10.98
On 20/04/2018 19:42, Andrey V. Elsukov wrote:
On 20.04.2018 18:48, Victor Gamov wrote:
More correct problem is: last configured ipsec interface tx/rx traffic
only. For my example:
- ping from 10.10.98.1 to 10.10.98.2 via ipsec30 is OK
- ping from 10.10.98.2 to 10.10.98.1 via ipsec30 is OK
-
On 20.04.2018 18:48, Victor Gamov wrote:
> More correct problem is: last configured ipsec interface tx/rx traffic
> only. For my example:
>
> - ping from 10.10.98.1 to 10.10.98.2 via ipsec30 is OK
>
> - ping from 10.10.98.2 to 10.10.98.1 via ipsec30 is OK
>
> - ping from 10.10.98.5 (Cisco) to
On 20/04/2018 13:04, Andrey V. Elsukov wrote:
On 20.04.2018 11:17, Victor Gamov wrote:
All local SA configured and established and remote side (Cisco routers)
report SA established too.
But traffic goes via only one ipsec-interface.
If you have all SAs established, you probably need to check
On 20.04.2018 11:17, Victor Gamov wrote:
> All local SA configured and established and remote side (Cisco routers)
> report SA established too.
>
> But traffic goes via only one ipsec-interface.
If you have all SAs established, you probably need to check your routing
configuration. Or at least te
Hi All
I have FreeBSD box (11.1-STABLE FreeBSD 11.1-STABLE #0 r327786) and
simple configuration with two if_ipsec configured like
=
ipsec25: flags=8051 metric 0 mtu 1400
description: -so: Sofy
tunnel inet IP-FreeBSD --> IP-Cisco-RTR-1
inet 10.10.98.6 --> 10.1
Hi list,
I'm trying to get some docs and examples about the new if_ipsec code.
For what I read now, it seems to be a bit tricky* running legacy policy
based IPSEC in combination with on route based IPSEC with Strongswan. Is
it possible to mix them for bigger sites running e.g. one Azur
1 - 100 of 115 matches
Mail list logo
