I know I'm venturing of topic but I can't resist.
I'll go for OpenBSD with IPSec any day. Only last week OpenVPN had a security
fallout:
https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243
One of these exploits even has a high probability of being remotely exploitable.
Hi all,
I'm trying to determine which action I should take in response to the Stack
Clash thing https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt . I
suspect that "008: SECURITY FIX: May 19, 2017"
(https://www.openbsd.org/errata61.html) is the mitigation for OpenBSD 6.1?
On a related
Disclaimer: I don't want to sound too negative, I really appreciate all the
hard work that went in to OpenIKED but I've just made the reverse trip;
OpenIKED (IKEv2) to isakmpd (IKEv1). We just couldn't get our connections
stable with OpenIKED. We backported multiple patches from the master in t
ging the traffic with the help of 2
layer 2.5 switches in an MLAG in front of the OpenBSD gateways.
Kind regards,
Jasper
> Op 31 oktober 2016 om 22:02 schreef Remi Locherer :
>
> On Sun, Oct 30, 2016 at 12:36:12PM +0100, Jasper Siepkes wrote:
> > Hi all,
> >
> > I&
Hi all,
I've got a question about how OpenBSD deals with routes and interfaces
that are considerd 'down'. I've noticed that when an interface in
OpenBSD is down the route to that interface will remain in the routing
table and is also not flagged with R(eject). The route stays exactly
the same whe
tions, it is beneficial to
> defer transmission of the initial packet of a connection. The pfsync state
> insert message is sent immediately; the packet is queued until either this
> message is acknowledged by another system, or a timeout has expired. This
> behaviour is enabled with the
Hi list!
I've ran into a situation with PF which I don't quite understand.
The situation is as follows; I have 2 OpenBSD firewalls connected to an
upstream provider which forwards traffic to us via equal cost multi
path routing (ECMP). The firewalls are connected via a crossover cable
over wich
Silly me... I forgot the 'net.inet.carp.preempt' sysctl variable.
I thought it was only for forcing demotion of other CARP interfaces if a
single one failed. But it's also for "claiming" the master spot.
Sorry for the noise :-(
> Op 4 oktober 2016 om 9:27 schreef J
Hi list!
I'm experimenting with CARP and I'm a bit puzzled by the following
behavior; I have 2 hosts setup in an active/passive way with CARP.
Host A has an advskew of 0 and becomes master, Host B has an
advskew of 100 and becomes backup. Now when host A fails host B becomes
master just like i wo
Hi everyone @ misc!
I'm trying to determine what the state is of using iked (OpenIKED) with
redundancy (with CARP). Should such a setup work in OpenBSD 6.0?
The iked.conf (5) man page implies that using CARP for
redundancy is a supported configuration: "This option is used for
setups using sasy
10 matches
Mail list logo