Re: OpenBSD IPSec setup

[Jasper Siepkes]

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.


-Jasper

> Op 29 juni 2017 om 12:59 schreef Marko Cupać :
> 
> On Thu, 29 Jun 2017 12:32:01 +0200
> Luescher Claude  wrote:
> 
> > Why are you using ipsec in the 21th century:
> 
> Because it is in OpenBSD base. Because, at least on OpenBSD, it
> integrates great with the rest of networking ecosystem (carp, sasync,
> ospf, pf etc.) Because it pays my bills for more than a decade
> now. Because my users are satisfied. Because my employers are
> satisfied. Because I haven't encountered anything better for
> site-to-site VPNs so far (I also use both OpenVPN and npppd for my road
> warriors' needs).
> 
> I could go on.
> -- 
> Before enlightenment - chop wood, draw water.
> After enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/

>

Stack clash and OpenBSD

[Jasper Siepkes]

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 note; Does anyone know where can I order my Stack Clash t-shirts
and mugs? I'm also really disappointed there is no clever flashy logo :-(.

Kind regards,

Jasper

Re: Isakmpd vs iked

[Jasper Siepkes]

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 to 
our 6.0 source tree which improved things but in the end after what seemed 
like about a month without trouble OpenIKED suddenly started to run in to
trouble with rekeying so I finally called it quits and deployed isakmpd.

For example we bumped in to an issue described on the mailinglist[1] with
rekeying. This is one of the patches we applied which improved things for
us but as far as I can tell this hasn't ended up in the main source tree.

Also there are some pitfalls of things that work with isakmpd but not with
iked. For example sasyncd has some shortcomings with iked [2].

We bumped into like 5 other things like this before throwing in the
towel. So my advice is: Ask yourself if you really need IKEv2 with iked 
because it won't be as smooth sailing as with isakmpd.

[1] https://marc.info/?l=openbsd-tech=147869752432059=2
[2] https://marc.info/?l=openbsd-misc=147574084806723=2

Kind regards,

Jasper

> Op 7 februari 2017 om 18:43 schreef Christopher Sean Hilton
> :
> 
> 
> How hard is it to transition from an isakmpd managed IPsec VPN to iked
> managment? I have a certificate based isakmpd solution that works. It
> is mainly just a matter of rsyncing the directories and using a little
> editor magic on the ipsec.conf file to create iked.conf?
> 
> Thanks in advance,
> 
> -- Chris

Re: Routes to downed interfaces

[Jasper Siepkes]

> Something similar was discussed in this thread:
> http://marc.info/?t=14599935538r=1w=2

Ah nice, interesting read! I googled quite a lot but that thread didn't 
came up. Guess I need to work on my Google-foo. As discussed in that
thread there is no one size fits all. Maybe a sysctl variable which
determines how OpenBSD deals with routing to dead interfaces would be
an option?

> Maybe a setup without carp on the interfaces towards your upstream would
> work better? But I can not tell based on the information you provide.

I've fixed the problem by merging 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 <remi.loche...@relo.ch>:
> 
> On Sun, Oct 30, 2016 at 12:36:12PM +0100, Jasper Siepkes wrote:
> > 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 wheter the device is up or down.
> > 
> > In Linux (and I have no idea wheter this is a good idea or not) the 
> > route of the downed interface is removed.
> 
> Something similar was discussed in this thread:
> http://marc.info/?t=14599935538r=1w=2
> 
> OpenBSD behaves different to what I know from routers I work with. There
> a route disapears when I shut an interface.
> 
> > Is the above behavior normal? WHat should I do if I don't want to
> > route traffic to downed interfaces (like backup CARP interfaces).
> > 
> > The reason why I'm asking is because I want to route traffic somewhere
> > else with ifstated when a device goes in CARP backup mode (upstream
> > uses ECMP routing). But because the device route of the downed
> > interface (the interface being a CARP interface in backup mode in this
> > scenario) stays in the routing table with priority 1 I can't 
> > override it.
> 
> Maybe a setup without carp on the interfaces towards your upstream would
> work better? But I can not tell based on the information you provide.
> 
> Remi

Routes to downed interfaces

[Jasper Siepkes]

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 wheter the device is up or down.

In Linux (and I have no idea wheter this is a good idea or not) the 
route of the downed interface is removed.

Is the above behavior normal? WHat should I do if I don't want to
route traffic to downed interfaces (like backup CARP interfaces).

The reason why I'm asking is because I want to route traffic somewhere
else with ifstated when a device goes in CARP backup mode (upstream
uses ECMP routing). But because the device route of the downed
interface (the interface being a CARP interface in backup mode in this
scenario) stays in the routing table with priority 1 I can't 
override it.

Kind regards,

Jasper

Re: PF suddenly thinks traffic is not part of an established connection anymore?

[Jasper Siepkes]

Should have mentioned it but the situation described below was 
with the 'defer' option of pfsync enabled.

I think you are right about the problems being with TCP sequence number 
checks. I tried the PF rule with 'keep state (sloppy)' and that "fixes" 
the problem (or I guess it would be better to say: "Makes the symptoms 
disappear"). It seems like a highly discouraged option and I don't 
fully understand the security implications. Would appreciate any 
insights anyone could offer on that.

Could it be that since my upstream has a strong preference
for FW1 everything goes fine for a while (like about 30 secs in mosts
tests) and then upstream sends a couple (maybe even a single one) 
packets directly to FW2 which botches the sequence number check on FW1?
Even with this theory I still don't understand why PF has no problem
accepting traffic on the outside interface (vlan1604) and only starts 
to have a problem when trying to send it out on the inside interface 
(vlan1003).

The cable is actually just a normal cable; Old habbits I guess... ;-)

> Op 20 oktober 2016 om 20:21 schreef Stuart Henderson <s...@spacehopper.org>:
> 
> For this config where you can't predict which firewall receives the
> packet from upstream, and especially if you end up with packets from
> your "inside" machine going through a different firewall as the one
> receiving external packets, you can run into problems with the TCP
> sequence number checking that PF (and some other stateful firewalls)
> does on TCP packets.
> 
> Try "ifconfig pfsync0 defer" first - from pfsync(4):
> 
>  Where more than one firewall might actively handle packets, e.g. with
>  certain ospfd(8), bgpd(8) or carp(4) configurations, 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 defer parameter to ifconfig(8).
> 
> On 2016-10-20, Jasper Siepkes <siep...@serviceplanet.nl> wrote:
> > 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
> 
> Incidentally, there's no need for crossover cables with gigabit nics.
> 
> > over wich pfsync is configured. On the inside the firewalls are each
> > connected with 2 cables (with LACP) to 2 different switches which 
> > are in an MLAG configuration (so these 2 switches function as 1 switch).
> > The OpenBSD firewalls are running OpenBSD 6.0 with all patches applied.
> >
> > It looks like this (public IP's changed):
> >
> > OUTSIDE / UPSTREAM 
> >
> > GW: 192.168.116.21 GW: 192.168.216.21
> > + ^
> > | |
> > vlan1604 | | vlan2604
> > 192.168.116.22 | | 192.168.216.22
> > | |
> > +---v---+ ++--+
> > | FW 1 +--+ FW 2 |
> > +---+---+ ++--+
> > vlan1003 | ^ vlan1003
> > 17.214.19.49 | | 17.214.19.50
> > +---+
> >
> > INSIDE
> >
> > Now on both firewalls I have this really simple ruleset:
> >
> > -
> > # cat /etc/pf.conf
> > 
> > set skip on lo0
> > # Interface connected with crossover cable to other firewall for
> > # pfsync.
> > set skip on em1
> >
> > block log
> >
> > pass log quick proto tcp to port 22
> > -
> >
> > Which results in the following PF rules:
> > -
> > # pfctl -sr
> > 
> > block drop log all
> > pass log quick proto tcp from any to any port = 22 flags S/SA
> > -
> >
> > Now when I SSH from the outside world to 17.214.19.50 the traffic flows
> > as indicated in the diagram (altough its ECMP upstream seems to prefer
> > FW 1 so traffic always ends up there): 
> >
> > [Internet] Me (62.187.45.178)
> > |
> > V
> > [FW1]vlan1604 
> > |
> > V
> > [FW1]vlan1003
> > |
> > V
> > [FW2]vlan1003 
> > |
> > V
> > [FW2]vlan2604 
> > |
> > V
> > [Internet] Me 
> >
> > And this works. However after about 30 seconds I lose connection to the
> > 17.214.19.50 host because PF can't match the traffic on FW1 vlan1003 
> > to the established state. I'm typing random stuff in to the SSH session
> > to keep it active and then it just hangs. This look

PF suddenly thinks traffic is not part of an established connection anymore?

[Jasper Siepkes]

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 pfsync is configured. On the inside the firewalls are each
connected with 2 cables (with LACP) to 2 different switches which 
are in an MLAG configuration (so these 2 switches function as 1 switch).
The OpenBSD firewalls are running OpenBSD 6.0 with all patches applied.

It looks like this (public IP's changed):

 OUTSIDE / UPSTREAM

  GW: 192.168.116.21  GW: 192.168.216.21
   +   ^
   |   |
  vlan1604 |   | vlan2604
192.168.116.22 |   | 192.168.216.22
   |   |
   +---v---+  ++--+
   | FW 1  +--+ FW 2  |
   +---+---+  ++--+
 vlan1003  |   ^   vlan1003
 17.214.19.49  |   |   17.214.19.50
   +---+

INSIDE

Now on both firewalls I have this really simple ruleset:

-
# cat /etc/pf.conf

 
set skip on lo0
# Interface connected with crossover cable to other firewall for
# pfsync.
set skip on em1

block log

pass log quick proto tcp to port 22
-

Which results in the following PF rules:
-
# pfctl -sr


block drop log all
pass log quick proto tcp from any to any port = 22 flags S/SA
-

Now when I SSH from the outside world to 17.214.19.50 the traffic flows
as indicated in the diagram (altough its ECMP upstream seems to prefer
FW 1 so traffic always ends up there): 

[Internet] Me (62.187.45.178)
 |
 V
[FW1]vlan1604 
 |
 V
[FW1]vlan1003
 |
 V
[FW2]vlan1003 
 |
 V
[FW2]vlan2604 
 |
 V
[Internet] Me 

And this works. However after about 30 seconds I lose connection to the
17.214.19.50 host because PF can't match the traffic on FW1 vlan1003 
to the established state. I'm typing random stuff in to the SSH session
to keep it active and then it just hangs. This looks like this 
(public IP's changed):

-
# tcpdump -nettti pflog0 port 22 and host 17.214.19.50 
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Oct 20 10:30:11.27 rule 1/(match) pass in on vlan1604: 62.187.45.178.64072 >
17.214.19.50.22: S 4112726507:4112726507(0) win 29200  (DF)
Oct 20 10:30:11.300026 rule 1/(match) pass out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: S 4112726507:4112726507(0) win 29200  (DF)



Oct 20 10:30:44.330002 rule 0/(match) block out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: P 4112740387:4112740427(40) ack 2507834833 win 594
 (DF) [tos 0x10]
Oct 20 10:30:44.425886 rule 0/(match) block out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: P 40:80(40) ack 1 win 594  (DF) [tos 0x10]
Oct 20 10:30:44.436021 rule 0/(match) block out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: P 40:80(40) ack 1 win 594  (DF) [tos 0x10]
Oct 20 10:30:44.514107 rule 0/(match) block out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: P 80:120(40) ack 1 win 594  (DF) [tos 0x10]
Oct 20 10:30:44.618079 rule 0/(match) block out on vlan1003: 62.187.45.178.64072
> 17.214.19.50.22: P 120:160(40) ack 1 win 594  (DF) [tos 0x10]
-

It seems that PF all of a sudden doesn't see the SSH traffic as part
of the established connection anymore. The state table of PF show that 
the state was correctly added to the state table and synced between 
the firewalls and it also still there:

---
# pfctl -ss


all carp 17.214.19.49 -> 17.214.19.50   SINGLE:NO_TRAFFIC
all carp 10.100.0.2 -> 10.100.0.3   SINGLE:NO_TRAFFIC
all carp 10.100.2.2 -> 10.100.2.3   SINGLE:NO_TRAFFIC
all tcp 17.214.19.49:22 <- 62.187.45.178:65149  ESTABLISHED:CLOSING
all tcp 17.214.19.49:22 <- 62.187.45.178:58883  ESTABLISHED:CLOSING
all tcp 17.214.19.49:22 <- 62.187.45.178:59505  ESTABLISHED:ESTABLISHED
all tcp 17.214.19.49:22 <- 62.187.45.178:63889  ESTABLISHED:FIN_WAIT_2
all tcp 17.214.19.49:22 <- 62.187.45.178:63963  ESTABLISHED:ESTABLISHED
all tcp 17.214.19.49:22 <- 62.187.45.178:63235  

Re: CARP host with lower advskew not becoming master

[Jasper Siepkes]

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 Jasper Siepkes <siep...@serviceplanet.nl>:
> 
> 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 would expect. However once host A comes backup again
> he doesn't become master, he stays backup even though he has a 
> lower advertise skew. 
> 
> Peeking with tcpdump tells me host A just goes to backup and doesn't
> advertise at all so host B never knows a host with lower advskew 
> came up.
> 
> That's not what I expected. Is that normal? From all the examples I 
> can find on the net I would expect host A to become master again. For
> example a lot of 'ifstated' examples use the advskew to promote or
> demote a host as master but since a host with lower advskew doesn't 
> seem to 'claim' the master position those examples don't work.
> 
> The setup is a cleanly installed OpenBSD 6.0 with the only 
> modifications the configs below. I've tested this in a VM and on 
> baremetal.
> 
> Host A
> 
> hostname.em1:
> 
> inet 10.253.255.2 255.255.254.0 NONE
> 
> 
> hostname.carp1000:
> 
> 
> carpdev em1 advbase 1 advskew 0 pass foo vhid 20
> inet 10.253.255.1 255.255.254.0 NONE
> carppeer 10.253.255.3
> 
> 
> Host B
> 
> hostname.em1:
> 
> inet 10.253.255.3 255.255.254.0 NONE
> 
> 
> hostname.carp1000:
> 
> carpdev em1 advbase 1 advskew 100 pass foo vhid 20
> inet 10.253.255.1 255.255.254.0 NONE
> carppeer 10.253.255.2
> 
> 
> Kind regards,
> 
> Jasper

CARP host with lower advskew not becoming master

[Jasper Siepkes]

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 would expect. However once host A comes backup again
he doesn't become master, he stays backup even though he has a 
lower advertise skew. 

Peeking with tcpdump tells me host A just goes to backup and doesn't
advertise at all so host B never knows a host with lower advskew 
came up.

That's not what I expected. Is that normal? From all the examples I 
can find on the net I would expect host A to become master again. For
example a lot of 'ifstated' examples use the advskew to promote or
demote a host as master but since a host with lower advskew doesn't 
seem to 'claim' the master position those examples don't work.

The setup is a cleanly installed OpenBSD 6.0 with the only 
modifications the configs below. I've tested this in a VM and on 
baremetal.

Host A

hostname.em1:

inet 10.253.255.2 255.255.254.0 NONE


hostname.carp1000:



carpdev em1 advbase 1 advskew 0 pass foo vhid 20
inet 10.253.255.1 255.255.254.0 NONE
carppeer 10.253.255.3


Host B

hostname.em1:

inet 10.253.255.3 255.255.254.0 NONE


hostname.carp1000:

carpdev em1 advbase 1 advskew 100 pass foo vhid 20
inet 10.253.255.1 255.255.254.0 NONE
carppeer 10.253.255.2


Kind regards,

Jasper

State of IPsec, iked (OpenIKED) and redundancy (CARP)

[Jasper Siepkes]

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 sasyncd(8) and carp(4) to provide redundancy.".

However after some digging I'm leaning towards it was something that 
used to work but doesn't work anymore (at least not in 6.0).

The issue I bumped into; I'm using OpenBSD 6.0 (fully patched) and CARP 
and iked by themselves work fine. The problems start when trying to 
have iked use the CARP IP address instead of the IP of the host it 
self. iked says in it's logs that it uses the CARP IP as source IP in 
the messages it sends but in reality (checked with tcpdump) it doesn't. 
It uses the IP of the interface with the default route. After some 
digging I found someone on the list who encountered the same 
problem: "IKED/carp/sasyncd: Wrong source ip address/No IKEv2 response" 
[1]. The response is: "iked generates some packets before binding, 
so they have whatever source address is on the interface that holds the 
outgoing route to the destination.". 

I also found a post in the list called "iked+CARP/ active,
passive"[2] which implies that iked + CARP actually does work. But 
since that post is from 2011 I'm guessing it broke somewhere between 
2011 and 2016.

If the current state is indeed that using CARP with iked is not an 
working option perhaps we should modify the iked.conf (5) man page to 
clearly state that?

On a related note; I got bitten by the bug fixed in the patch: 
"Fix an infinite loop in iked"[3]. I manually patched my build with it
but perhaps it's a good candidate for inclusion in the 6.0 patch 
branch?

Regards,

Jasper

[1] https://marc.info/?l=openbsd-misc=145924380931352=2
[2] https://marc.info/?l=openbsd-misc=131850193524708=2
[3] https://marc.info/?l=openbsd-tech=147348976311128=2