Re: What determines source IP of traffic from OpenBSD box ?

2021-02-28 Thread Rachel Roch




28 Feb 2021, 11:28 by s...@spacehopper.org:

> On 2021/02/28 11:46, Rachel Roch wrote:
>
>> Thank you all for the suggestions, I am currently testing a few of them.
>>
>> Incase it makes any difference, the underlying problem I have is I have two 
>> firewalls with BGP upstreams, one acting as primary, one as standby.  So the 
>> problem I am seeing is the age-old problem of asymmetric traffic to the 
>> secondary firewall meaning pkg_add on the secondary doesn't work.
>>
>
> You can't just get two sessions from your upstreams so they can both be
> active rather than one in standby?
>

Maybe my wording is a little off.

I do have independent sessions from FW1 and FW2 to upstream routers.

The problem, I suspect, is more to do with overlapping of IP ranges being 
advertised to upstreams, and hence traffic never making it back to FW2 because 
FW1 picks it up, hence the desire to have an effective way to tell OpenBSD 
"send all localhost originating traffic from lo2 because the IPs on lo2 are 
exclusive to that host".




Re: What determines source IP of traffic from OpenBSD box ?

2021-02-28 Thread Rachel Roch
Thank you all for the suggestions, I am currently testing a few of them.

Incase it makes any difference, the underlying problem I have is I have two 
firewalls with BGP upstreams, one acting as primary, one as standby.  So the 
problem I am seeing is the age-old problem of asymmetric traffic to the 
secondary firewall meaning pkg_add on the secondary doesn't work.

I guess I could med/localpref tweak the secondary to push traffic via the 
primary.  But then I still have the problem of determining return path for the 
traffic (given inherent overlapping of IP ranges on the boxes).

26 Feb 2021, 15:34 by s...@spacehopper.org:

> On 2021-02-26, Daniel Jakots  wrote:
>
>> On Fri, 26 Feb 2021 11:53:40 +0100 (CET), Rachel Roch
>>
> > wrote:
>
>>> Let's say I'm running "pkg_add -u" on a OpenBSD-based router with
>>> multiple interfaces.
>>>
>>> What determines the source IP ?
>>>
>>
>> On -current there is
>>  route [-T rtable] sourceaddr [-inet|-inet6] [address]
>>  route [-T rtable] sourceaddr [-inet|-inet6] -ifp interface
>>
>
> Use with care though, this can be a footgun (especially if you are
> connecting from there to other local machines with "strict host model").
>
> If you want something more targetted then nat-to is one option.
>



What determines source IP of traffic from OpenBSD box ?

2021-02-26 Thread Rachel Roch
Hi

Let's say I'm running "pkg_add -u" on a OpenBSD-based router with multiple 
interfaces.

What determines the source IP ?

Building on that, there is no "source interface" flag for pkg_add like there is 
for ping and certain others.  Is there a way for me to configure a default 
interface for utilities such as pkg_add to use ?

Thanks !

Rachel



Re: man netstart(8) OpenBSD-6.8

2020-11-03 Thread Rachel Roch



> an updated diff for this just got committed.
> jmc
>

Thank you all.  For myself and on behalf of future devoted man page readers, 
very much appreciated that such a key man page has been brought up to date.

rr



Re: man netstart(8) OpenBSD-6.8

2020-10-26 Thread Rachel Roch
Re: submitting something.  Theo has spoken and given his judgement. Theo 
decreed "no, it should not be there", thus I shall not be wasting my time 
submitting something that won't ever be accepted due to whatever weird reason 
Theo thinks a random half-baked description of what is going on with 
netstart(8) is acceptable.




25 Oct 2020, 13:44 by pi...@protonmail.com:

> Rachel, you could submit something to be helpful if you like, fill the gap 
> that you see.   Only 60 devs and most of the man page content is incredibly 
> up to date and valuable.
> So I for one look forward to you adding your entry into the netstart man page 
> for community review.
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, 25 October 2020 09:42, Rachel Roch  wrote:
>
>> 25 Oct 2020, 01:25 by dera...@openbsd.org:
>>
>> > Rachel Roch rr...@tutanota.de wrote:
>> >
>> > > Is it just me or is the man entry for netstart(8) missing a reference to 
>> > > wg(4) ?
>> >
>> > ... and 300 other network interfaces.
>> > In otherwords, no, it should not be there.
>>
>> OK smart alec, then why bother enumerating any of the non-physical 
>> interfaces on the man page ? 
>>
>> Afterall, the man page does state at the head of the list "During the system 
>> boot, netstart is executed. netstart performs the following operations, in 
>> the sequence given". 
>>
>> There is little point giving a half-assed description.  Either you enumerate 
>> ALL the non-physical interfaces, or otherwise you treat them the same way as 
>> the physical ones ("Configure all the physical interfaces").
>>
>> Otherwise you are failing to explain what happens to any of your "300 other 
>> interfaces".  Enumerate or don't enumerate, I don't care ... but surely it 
>> is sensible to pay some reference to them.
>>
>> Sheesh !
>>



Re: man netstart(8) OpenBSD-6.8

2020-10-25 Thread Rachel Roch


25 Oct 2020, 01:25 by dera...@openbsd.org:

> Rachel Roch  wrote:
>
>> Is it just me or is the man entry for netstart(8) missing a reference to 
>> wg(4) ?
>>
>
> ... and 300 other network interfaces.
>
> In otherwords, no, it should not be there.
>

OK smart alec, then why bother enumerating any of the non-physical interfaces 
on the man page ? 

Afterall, the man page does state at the head of the list "During the system 
boot, netstart is executed. netstart performs the following operations, in the 
sequence given".  

There is little point giving a half-assed description.  Either you enumerate 
ALL the non-physical interfaces, or otherwise you treat them the same way as 
the physical ones ("Configure all the physical interfaces").

Otherwise you are failing to explain what happens to any of your "300 other 
interfaces".  Enumerate or don't enumerate, I don't care ... but surely it is 
sensible to pay some reference to them.

Sheesh !



man netstart(8) OpenBSD-6.8

2020-10-24 Thread Rachel Roch
Hi

Is it just me or is the man entry for netstart(8) missing a reference to wg(4) ?

Rachel



Re: South American mirrors?

2020-10-19 Thread Rachel Roch
One of the CDNs would seem the obvious answer to your problem. Or have you 
already tried them ?

Addresses are :
Fastly (CDN)
https://cdn.openbsd.org/pub/OpenBSD/
Cloudflare (CDN)
https://cloudflare.cdn.openbsd.org/pub/OpenBSD/
Verizon Digital Media Services (CDN)
https://mirror.vdms.com/pub/OpenBSD/


19 Oct 2020, 14:13 by zp6...@gmx.net:

> Hello y'all,
> Thank you for 6.8 and a painless way to upgrade.
> Just out of curiosity and as a sidenote: downloading from Brazil was
> always faster for me than from Canada or Europe.
> Is there any information available about what happened to the South
> American mirrors of Argentina, Brazil and Uruguay? They are still there
> with 6.6 and 6.7 but no 6.8 and accordingly already do not show up in
> the mirror list.
> Do those mirrors not comply anymore with the requirements for mirrors or
> will they come up later with 6.8 or is it due to the situation of the
> pandemic and the closure of the s.am. universities?
> Does anyone know?
> Cheers
> Eike
> --
> Eike Lantzsch ZP6CGE
> 01726 Asuncion / Paraguay
>



rad(8) and carp - anything I ought to know ?

2020-01-17 Thread Rachel Roch
Hi,

I'm sure many here have been down this road before me.  So to save me many 
hours of tears and frustration, I have a simple question.

Say I was hoping to use rad(8) in conjunction with carp, any tales from the 
battlefield (a.k.a. config tips, things to be aware of etc.).

Thanks !

Rachel



Re: sysupgrade to 6.6 failed at comp66.tgz

2019-11-23 Thread Rachel Roch



> This topic has been beat to death. deraadt@ and other have made it clear that 
> if you do not install all the sets, you are running an unsupported 
> configuration. It has been stated that if people keep bitching, they're just 
> going to merge the release sets into one set.
>
> I like the fact that there are separate sets. A number of times I've had to 
> squeeze an install onto a <2GB disk, and it was useful being able to select 
> only the specific sets I wanted/needed, while at the same time acknowledging 
> that it was indeed an unsupported configuration.
>
> If people are going to try and be edgelords by refusing to install all the 
> sets, then it's up to them to maintain and diagnose their unsupported 
> configuration.
>

You can't seriously be calling "-x* -game*" an unsupported configuration ?  
Seems to me like a sensible thing to do on any box that's going to be headless 
for its entire life and only ever accessed via SSH (or text console at a push).



Re: sysupgrade to 6.6 failed at comp66.tgz

2019-11-23 Thread Rachel Roch



>> - maybe sysupgrade needs to be patched to avoid this issue?
>>
>
> Probably not. sysupgrade has assumptions baked in to it which have
> evidently been rendered invalid either by another tool or by the
> person using them. That tool is where the patch most likely ought
> to be directed.
>
>


If I may make a little comment here.

Surely it is a little bit questionable to "bake assumptions" into sysupgrade 
that everybody is going to do a complete install when the OpenBSD installer 
itself gives you the option to select what is going to be installed.

At the very least, may I suggest that even if the developers don't want to 
increase the intelligence of sysupgrade that they at least code in some sanity 
checks (e.g. "pick a file - or two - at random from the core tgz files that you 
would normally expect to be present on the system if a 'full-default' install 
was done.  If file not present, then throw a horrid error message and abort).

It strikes me as a little silly to put a tool out there that you know will 
trash (or at least severely brick) a user's system just because of some 
severely opinionated "baked assumptions" coded into it.



bgpd not exporting default route

2019-11-23 Thread Rachel Roch
Hi,

I'm probably being completely dumb here, but I'm adding an additional perimiter 
router to my network which is running OpenBSD 6.6.

My current perimiter is a 6.4 instance (soon to be upgraded !) which talks BGP 
to internal firewalls.

The config below works perfectly on 6.4, but on 6.6, the default route is never 
exported (the session otehrwise operates fine, comes up and receives routes 
from firewalls).

"bgpctl sho ri nei nei-name out" shows nothing being sent.   

"bgpd -n" reports no problems with the config

AS 64520
router-id 192.0.2.1
rde med compare always
socket "/var/run/bgpd.sock.ro" restricted

group my_firewall_v4 {
    export default-route
    remote-as 64515
    announce IPv6 none
    neighbor 198.51.100.1 {
    local-address 198.51.100.2
    descr "MY-F1-V4"
    }
}

group my_firewall_v6 {
    export default-route
    remote-as 64515
    announce IPv4 none
    neighbor 2001:db8::1 {
    local-address 2001:db8::2
    descr "MY-F1-V6"
    }
}

MY_INT_FIREWALLS="{group my_firewall_v4,group my_firewall_v6}"
prefix-set my-def-routes {0.0.0.0/0,::/0}
prefix-set MY_NETS_FILTER {192.0.2.0/24 or-longer,198.51.100.0/24 
or-longer,2001:db8::/32 or-longer}
deny to any
allow to $MY_INT_FIREWALLS prefix-set my-def-routes
deny from any
deny from any prefix-set my-def-routes
allow from $MY_INT_FIREWALLS prefix-set MY_NETS_FILTER



Re: Sonos and OpenBSD PF - anyone on-list with experience ?

2019-11-23 Thread Rachel Roch


Thanks all for your ideas.  I'll spend a little time on it over the next few 
days and see how far I can get.



22 Nov 2019, 16:34 by s...@spacehopper.org:

> On 2019-11-22, Peter N. M. Hansteen  wrote:
>
>> On Fri, Nov 22, 2019 at 12:56:51PM +0100, Rachel Roch wrote:
>>  
>>
>>> They sent me the following long email, it does mention inbound access but 
>>> seems like a bit of a generic answer if all those ports really need to be 
>>> opened inbound via PAT ?  I've asked Sonos to clarify exactly what is 
>>> required inbound (as opposed to stateful outbound), and am still awaiting a 
>>> reply !
>>>
>>> "If your firewall needs to be manually configured, refer to the port 
>>> numbers below and make sure inbound access is enabled for the Sonos 
>>> application.
>>>
>>
>> I get the feeling that there is some confusion at the support people's
>> end about what needs to be open inbound vs outbound.
>>
>
> Most users will not have a separate firewall device between Sonos and
> anything accessing it, only a host firewall on e.g. Windows machines
> running their software, and I think that is what their advice refers to.
>
> If it is indeed on a different subnet then there are other things
> that might need considering, like whether multicast can make it through.
>
> The other thing to consider if the various devices involved are all
> connected via wifi is whether client isolation is enabled.
>
> We really need a sketch/description of the desired setup to give
> further advice ..
>



Re: Sonos and OpenBSD PF - anyone on-list with experience ?

2019-11-22 Thread Rachel Roch


Hi Tom,

They sent me the following long email, it does mention inbound access but seems 
like a bit of a generic answer if all those ports really need to be opened 
inbound via PAT ?  I've asked Sonos to clarify exactly what is required inbound 
(as opposed to stateful outbound), and am still awaiting a reply !

"If your firewall needs to be manually configured, refer to the port numbers 
below and make sure inbound access is enabled for the Sonos application.
Port (TCP)  Used for
80 and 443  Music services, radio, and Sonos account
445 and 3445Music library
3400, 3401, and 3500Sonos app control
4070Spotify Connect
System updates
Port (UDP)  Used for
136 through 139 Music library
1900 and 1901   Sonos app control
2869, 10243, and 10280 through 10284Windows Media Sharing
5353Spotify Connect
6969Sonos setup"

22 Nov 2019, 11:32 by tom.sm...@wirelessconnect.eu:

> Hi Rachel,
> I  does Sonos Require uPnP support ?
> (does Sonos require a few  ports to be forwarded from your internet
> interface back into the Sonos
> device on the LAN)
> is there a manual port forwarding that you can do to get around the
> uPNP requirement  ?
>
>
>
>
>
>
>
> On Fri, 22 Nov 2019 at 11:26, Rachel Roch  wrote:
>
>>
>> Hi,
>>
>> Refuse to use Sonos myself, but am helping (or trying to) out a friend who 
>> has a Sonos try to get things working wtih OpenBSD PF.
>>
>> I've simplified their PF rulese to a simple swiss cheese (i.e. stateful 
>> NAT'd allow any out to any).
>>
>> Everything else they care to run on their network is running perfectly.  
>> Apart from their darn Sonos box.
>>
>> Sonos support are about as much use as a fart in spacesuit, so I'm hoping 
>> there's somebody on this list who has already fought and won the Sonos 
>> battle ?
>>
>> Thanks !
>>
>> Rachel
>>
>
>
> -- 
> Kindest regards,
> Tom Smyth.
>



Sonos and OpenBSD PF - anyone on-list with experience ?

2019-11-22 Thread Rachel Roch
Hi,

Refuse to use Sonos myself, but am helping (or trying to) out a friend who has 
a Sonos try to get things working wtih OpenBSD PF.

I've simplified their PF rulese to a simple swiss cheese (i.e. stateful NAT'd 
allow any out to any).

Everything else they care to run on their network is running perfectly.  Apart 
from their darn Sonos box.

Sonos support are about as much use as a fart in spacesuit, so I'm hoping 
there's somebody on this list who has already fought and won the Sonos battle ?

Thanks !

Rachel



ifstated.conf advice needed

2019-11-15 Thread Rachel Roch
Hi,

I'm looking for a bit of help on how to write a sensible and safe (i.e. avoid 
race conditions) ifstated.conf.

I have a scenario where I have a LACP trunk and on top of the trunk, I have 
four carp interfaces.
So: trunk1 => carp0–3

Now, obviously I know I can monitor up/down on trunk1.

But what If I wanted to monitor the carp sub-interfaces too ? e.g. if I wanted 
to have the flexibility to demote one (or more) of the carp interfaces for the 
purposes of maintenance or traffic engineering.

Is there a sensible way to get around the problem of having to write ifstated 
rules for every single possible combination/permutation ?

Thanks !

Rachel



Re: pfsync on VLAN - supported ?

2019-11-14 Thread Rachel Roch




14 Nov 2019, 11:21 by liste...@wernig.net:

> On 14.11.2019 11:30, Rachel Roch wrote:
>
>>>> Does this mean Bad Things (TM) will happen if I try to use a dedicated 
>>>> vlan interface for pfsync ?
>>>>
> I have had pfsync running happily over a vlan interface for years, never
> a problem.
>
>> Regarding the extra port, in my case I'm using that for LACP (my switches 
>> support distributed LACP, so i can have two cables going into two switches)
>>
> Having the sync port physically redundant and connected to a switch is a
> very good idea, because a crossover cable will cause a carp demote
> whenever the other firewall goes down or is rebooted, afair.
>
> best /m
>

Regarding your last point, if your recollection is correct, then surely it is 
something the powers that be should consider adding to the FAQ and man pages 
forthwith ? It seems to me like a rather important thing to know.  ;-)

Thanks for your input, much appreciated.



Re: pfsync on VLAN - supported ?

2019-11-14 Thread Rachel Roch




13 Nov 2019, 20:21 by ch...@nmedia.net:

> Rachel Roch [rr...@tutanota.de] wrote:
>
>> Hi,
>>
>> Both the man page and FAQ (https://www.openbsd.org/faq/pf/carp.html) 
>> <https://www.openbsd.org/faq/pf/carp.html> talk about "physical interface" 
>> in relation to the syncdev parameter.
>>
>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan 
>> interface for pfsync ?
>>
>
> It's as secure as your ethernet network is. There is no privacy or
> authentication with pfsync. I don't think that using a vlan is 
> considered a big problem these days. I'm absolutely amazed at the
> volume of data that pfsync generates. Since so many boxes come with extra
> ports, using a vlan may be more complicated than directly connecting
> the boxes together (unless you have more than two machines)
>

Thanks Chris !

Regarding the extra port, in my case I'm using that for LACP (my switches 
support distributed LACP, so i can have two cables going into two switches)



pfsync on VLAN - supported ?

2019-11-13 Thread Rachel Roch
Hi,

Both the man page and FAQ (https://www.openbsd.org/faq/pf/carp.html) 
 talk about "physical interface" in 
relation to the syncdev parameter.

Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan 
interface for pfsync ?

Thanks !

Rachel



bgpctl sho ri nei terse output vs man page discrepancy

2019-09-22 Thread Rachel Roch
Hi,

Hopefully I'm not missing something silly here but I've read the paragraph in 
the man page and it only lists 15 variables:

"The printed numbers are the sent and received open,
sent and received notifications, sent and received
updates, sent and received keepalives, and sent and
received route refresh messages plus the current and
maximum prefix count, the number of sent and received
updates, and withdraws."

But bgpctl sho ri nei outputs 16 numbers, not 15 ?

Any clues ?

Rachel



Re: Prometheus node_exporter on OpenBSD - anyone managed ?

2019-09-20 Thread Rachel Roch
Sep 20, 2019, 15:57 by k...@plek.org:

>> On Sep 20, 2019, at 01:38, Rachel Roch
>>
>> Regarding the other gmake suggestion, that possibility occurred to me after 
>> sending yesterday's email, but I guess I would have to edit various source 
>> files to make sure its calling the right command.  Not rocket science I 
>> guess, but equally could be time consuming to make sure I've caught all the 
>> right spots in the code.
>>
>
> I tested it before sending the suggestion. I just ran gmake and it built fine.
>

I appreciate your beta testing of your suggestion !   ;-)

I shall run off to my nearest OpenBSD console forthwith.

Thank you.



Re: Prometheus node_exporter on OpenBSD - anyone managed ?

2019-09-20 Thread Rachel Roch
Claudio,

pkg_add node_exporter ?

I already had a good look at the package list on the FTP mirror and can't see 
any node_exporter there ?  pkg_add seems to agree with me, it says "can't find 
node_exporter" ?

Certainly pkg_add would be my preferred option, but it seems someone has forgot 
poor old node_exporter for recent releases ?  

Regarding the other gmake suggestion, that possibility occurred to me after 
sending yesterday's email, but I guess I would have to edit various source 
files to make sure its calling the right command.  Not rocket science I guess, 
but equally could be time consuming to make sure I've caught all the right 
spots in the code.


Sep 20, 2019, 05:29 by cje...@diehard.n-r-g.com:

> On Thu, Sep 19, 2019 at 10:13:23PM +, Travis Cole wrote:
>
>>
>> Looks like they are assuming GNU make.
>>
>>
>> Try doing the build with 'gmake'.
>>
>>
>> If you don't already have gmake installed:
>>
>>
>> # pkg_add gmake
>>
>
> Or just do `pkg_add node_exporter`. While prometheus does not provide
> a pre-compiled binary OpenBSD does.
>
>> On Thu, Sep 19, 2019 at 11:49:20PM +0200, Rachel Roch wrote:
>> > Hi,
>> > 
>> > The official Prometheus github repo 
>> > (https://github.com/prometheus/node_exporter) 
>> > <https://github.com/prometheus/node_exporter> appears to suggest in 
>> > multiple places that node_exporter is capable of working on OpenBSD.
>> > 
>> > But although they provide pre-compiled binaries for multiple platforms 
>> > including NetBSD (https://github.com/prometheus/node_exporter/releases) 
>> > <https://github.com/prometheus/node_exporter/releases> they seemingly 
>> > don't provide a binary for OpenBSD.
>> > 
>> > So I tried downloading the source and compiling it, but I get a screenful 
>> > of nasty sounding messages, e.g.:
>> > Bad modifier: , ,$(shell $(GO) env GOPATH)))   
>> >   
>> > Bad modifier: , ,$(shell $(GO) env GOPATH)))   
>> >   
>> > No closing parenthesis in archive specification
>> >   
>> > *** Parse error: Error in archive specification: "(, \.'))" 
>> > (Makefile.common:41)   
>> >   
>> > *** Parse error: Need an operator in 'else' (Makefile.common:51)   
>> >   
>> > *** Parse error: Need an operator in '' (Makefile.common:54)   
>> >   
>> > *** Parse error: Need an operator in '' (Makefile.common:55)   
>> >   
>> > *** Parse error: Need an operator in 'endif' (Makefile.common:61)  
>> >   
>> > Bad modifier: , ,$(shell go env GOPATH)))  
>> >   
>> > Bad modifier: , ,$(shell go env GOPATH))) 
>> > 
>> > 
>> > Given the popularity of Prometheus, I'm sure someone on-list must be 
>> > actively running it ?
>> > 
>> > Thanks !
>> > 
>> > Rachel
>> > 
>>
>
> -- 
> :wq Claudio
>



Prometheus node_exporter on OpenBSD - anyone managed ?

2019-09-19 Thread Rachel Roch
Hi,

The official Prometheus github repo 
(https://github.com/prometheus/node_exporter) 
 appears to suggest in multiple 
places that node_exporter is capable of working on OpenBSD.

But although they provide pre-compiled binaries for multiple platforms 
including NetBSD (https://github.com/prometheus/node_exporter/releases) 
 they seemingly don't 
provide a binary for OpenBSD.

So I tried downloading the source and compiling it, but I get a screenful of 
nasty sounding messages, e.g.:
Bad modifier: , ,$(shell $(GO) env GOPATH)))
 
Bad modifier: , ,$(shell $(GO) env GOPATH)))
 
No closing parenthesis in archive specification 
 
*** Parse error: Error in archive specification: "(, \.'))" 
(Makefile.common:41)
 
*** Parse error: Need an operator in 'else' (Makefile.common:51)
 
*** Parse error: Need an operator in '' (Makefile.common:54)
 
*** Parse error: Need an operator in '' (Makefile.common:55)
 
*** Parse error: Need an operator in 'endif' (Makefile.common:61)   
 
Bad modifier: , ,$(shell go env GOPATH)))   
 
Bad modifier: , ,$(shell go env GOPATH))) 


Given the popularity of Prometheus, I'm sure someone on-list must be actively 
running it ?

Thanks !

Rachel



Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

2019-05-16 Thread Rachel Roch



> RFC3513 says this:
>
>  o An anycast address must not be used as the source address of
>  an IPv6 packet.
>
>  o An anycast address must not be assigned to an IPv6 host, that
>  is, it may be assigned to an IPv6 router only.
>
> And to help ensure this, the kernel denies binding to an address marked
> with the anycast flag (see netinet6/in6_pcb.c).
>
> This was obsoleted by RFC4291, including this change:
>
>  o The restrictions on using IPv6 anycast addresses were removed because
>  there is now sufficient experience with the use of anycast addresses,
>  the issues are not specific to IPv6, and the GROW working group is
>  working in this area.
>
> So I think this restriction can now be removed, at least with this
> change, but more might be needed
>

Certainly in my case the current OpenBSD situation represents a bit too much 
"nanny knows best".

My use-case is anycast DNS with NSD and Unbound.

Both NSD and unbound provide config parameters that allow distinguishing 
between listen address and source address.

But then again, is there any real reason to use the anycast flag ?  To make NSD 
and unbound work I reconfigured to remove the anycast flag from IPv6 addresses 
and nothing seems broken ?



NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

2019-05-11 Thread Rachel Roch
I'm still learning IPv6 intricacies, so forgive me if this is a silly question.

When I have interfaces set in the standard manner, e.g.:

inet6 2001:DB8:beef::1 128
up

NSD and Unbound will bind to that address without problem.

However if I add the anycast flag:
inet6 2001:DB8:beef::1 128 anycast
up

and then destroy and re-create the interfaces and  pkill and relaunch unbound 
and NSD, they both complain bitterly:

[2019-05-11 21:00:51.665] nsd[43360]: notice: nsd starting (NSD 4.1.27)
[2019-05-11 21:00:51.666] nsd[43360]: error: can't bind udp socket: Can't 
assign requested address
[2019-05-11 21:00:51.666] nsd[43360]: error: server initialization failed, nsd 
could not be started
[1557604863] unbound[69433:0] error: can't bind socket: Can't assign requested 
address for 2001:DB8:beef::1 port 53[1557604863] unbound[69433:0] fatal error: 
could not open ports

The interface shows correctly in ifconfig so I don't know what the problem is ?

This is on OpenBSD 6.5 if it makes any difference.



PKCS11 on OpenBSD 6.5 ?

2019-05-11 Thread Rachel Roch
Hi,

To save me hours of Googling followed by hours of console bashing I thought 
perhaps someone here who's "been there, done that, got the T-shirt" can point 
me in the right direction.

So far I've got:
• A USB HSM
• OpenSC installed (from package) and working (i.e. no problems using 
pkcs11-tool / pkcs15-tool)

But now I'm struggling with the main event.  Creating an HSM-backed CA, so 
something along these lines 
:https://framkant.org/2018/04/smartcard-hsm-backed-openssl-ca/ 


>From the man pages it seems the bundled libressl has no PKCS11 support built 
>in.

The OpenSC package seems to deliver "/usr/local/lib/pkcs11/opensc-pkcs11.so" 
(i.e. for openssl MODULE_PATH), but there's no sign of "pkcs11.so" (i.e. for 
openssl SO_PATH) anywhere on the system.

If some kind soul could point me in the right direction as to what parts of the 
puzzle I'm missing, that would be much appreciated.

Thanks !

Rachel



nat-to random : A couple of questions

2019-04-28 Thread Rachel Roch
Hi,

I've read the delightful manual but its a little terse in this area, so I hope 
some knowledgeable soul can enlighten me:

1) Looking at tcpdumps, I've noticed (on 6.5 have no prior experience with 
nat-to random to compare against) that 'random' seems to operate more like 
'round-robin'  (e.g. if I send traffic, pause, send traffic again it just loops 
through the IP pool in order). 

2) I'm unclear when 'sticky-address' should be appended to random ? In my mind 
I'm thinking about, say, "secure websites" which may track your (apparent) 
source-IP during the time you are logged in, and if it changes you could be 
booted out.  Or am I overthinking things and 'sticky-address' is potentially 
less useful than I think it might be ?

Finally, is there any reason why there isn't (yet?) a more intelligent mapping 
? (e.g. similar to the options in LACP ... e.g. source plus destination, not 
just source).

Thanks !

Rachel



Re: Code of Conduct location

2019-04-28 Thread Rachel Roch
Apr 28, 2019, 9:16 AM by cho...@jtan.com :

> Strahil Nikolov writes:
>
>> Hello All,
>>
>> can someone point me to the link of the OpenBSD code of Conduct ?
>>
>
> I believe OpenBSD's code of conduct can be summed up as "if you are the
> type of person who needs a code of conduct to teach to you how to human
> then you are not welcome here".
>
> At least I hope so.
>
> Matthew
>

I always thought it could be summed up as "Don't piss off Theo".  ;-)



Re: Down on em fibre doesn't kill Layer 1 ?

2019-04-19 Thread Rachel Roch


Apr 18, 2019, 10:41 AM by s...@spacehopper.org:

> On 2019-04-16, Rachel Roch <> rr...@tutanota.de <mailto:rr...@tutanota.de>> > 
> wrote:
>
>> Hi,
>>
>> Is it expected behaviour that ifconfig emX down on a fibre interface doesn't 
>> kill the laser on a GBIC ?
>>
>
> Since ifconfig down doesn't kill link on a copper em(4), I would think it
> is expected from a fibre one too.
>


Would it be too much to ask to get this functionality implemented ?

I was dealing with a carrier the other day and we were dealing with bringing up 
two ports on their network.

The question came from the remote end "have you shutdown the port as its still 
showing up on my side", and indeed on the OpenBSD side carrier state was still 
"active".

It seems to be the expected behaviour that when you put a port into 
"administrative down" mode that it kills the carrier too  (indeed, I witnessed 
this for myself, because the carrier downed their side for me instead as I was 
unable to and I saw the carrier drop on OpenBSD).

Thanks !




Down on em fibre doesn't kill Layer 1 ?

2019-04-16 Thread Rachel Roch
Hi,

Is it expected behaviour that ifconfig emX down on a fibre interface doesn't 
kill the laser on a GBIC ?

Rachel



Re: Viewing SFP diagnostic data in OpenBSD ?

2019-04-12 Thread Rachel Roch
Apr 8, 2019, 5:25 AM by da...@gwynne.id.au:

>
>
>> On 6 Apr 2019, at 01:54, Rachel Roch <>> rr...@tutanota.de 
>> <mailto:rr...@tutanota.de>>> > wrote:
>>
>>
>>
>>
>> Apr 2, 2019, 11:19 PM by >> da...@gwynne.id.au <mailto:da...@gwynne.id.au>>> 
>> :
>>
>>>
>>>
>>>> On 3 Apr 2019, at 04:52, Stuart Henderson <>> >>>> s...@spacehopper.org 
>>>> <mailto:s...@spacehopper.org>>>>>  >>> s...@spacehopper.org 
>>>> <mailto:s...@spacehopper.org>>>>> >>> > wrote:
>>>>
>>>> On 2019-04-02, Rachel Roch <>> >>>> rr...@tutanota.de 
>>>> <mailto:rr...@tutanota.de>>>>>  >>> rr...@tutanota.de 
>>>> <mailto:rr...@tutanota.de>>>>> >>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Hopefully I'm just searching the man pages wrong but I can't seem to find 
>>>>> any hints as to how I can view SFP diagnostics in OpenBSD (i.e. light 
>>>>> power etc.)
>>>>>
>>>>> Perhaps someone could kindly point me in the right direction ?
>>>>>
>>>>> Rachel
>>>>>
>>>>
>>>> I don't think that code has been written yet.
>>>>
>>>
>>> You're right, it hasn't.
>>>
>>> Rachel, which nic are you interested in having this on?
>>>
>>> dlg
>>>
>>
>> Just spotted this email.
>>
>> An Intel I350 based NIC made by HotLava  (>> 
>> https://hotlavasystems.com/products_gbe.html 
>> <https://hotlavasystems.com/products_gbe.html>>> ) <>> 
>> https://hotlavasystems.com/products_gbe.html 
>> <https://hotlavasystems.com/products_gbe.html>>> >
>>
>
> OK. I made a start on this. Have a look for "sfp module info and diagnostics" 
> on tech@, or click on > 
> https://marc.info/?l=openbsd-tech=155469738013008=2 
> <https://marc.info/?l=openbsd-tech=155469738013008=2>
>
> We don't have an em(4) here with optics, but a diff doesn't look too bad if 
> you're willing to test it.
>
> dlg
>


Apologies for the delay in reply Work(TM) has been off the charts recently.  
Thanks a million for your hard work so far !

 Unfortunately I don't have any spare optics either (we only had a limited 
number of the HotLava cards and they're now all spoken for in production boxes).

I'll see what I can do, maybe I'll find another way to get hold of something.  
I really want to test it ! ;-)



Re: bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

2019-04-02 Thread Rachel Roch




Mar 30, 2019, 11:10 AM by s...@spacehopper.org:

> On 2019-03-29, Rachel Roch <> rr...@tutanota.de <mailto:rr...@tutanota.de>> > 
> wrote:
>
>> Hi,
>>
>> Has anyone encountered this before ?
>>
>> Neighbor    AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
>> EXT-V6-R2   65515 50 40 0 00:02:55 Active
>> EXT-V4-R2   65515 38 37 0 00:27:42  1
>> After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock solid.
>>
>> The boxes are sitting right next to each other, connected over an OpenBSD 
>> LACP trunk.
>>
>> I have made the pf rules as simple as possible:
>>
>> table  counters {self}
>> table  counters {192.0.2.1,2001:DB8::1}
>> pass in quick proto {tcp,udp,icmp} from  to 
>>  modulate state
>> pass out quick proto {tcp,udp,icmp} from  to 
>>  modulate state
>>
>
> A few tips:
>
> Start with an explicit "block any" rule so you don't have any traffic
> caught by the implicit "pass flags any no state" default. (If you want
> some "stateless" traffic as may often be the case on a BGP router, make
> it explicit in the ruleset). Otherwise you risk state being created 
> on something other than a SYN, so PF doesn't know the TCP window scaling
> value (which is *only* sent on SYN packets), which can result in the
> connection being killed after some traffic passes (state tracking gets
> out of sync).
>
> You don't have a rule for icmp6. IPv6's equivalent to ARP runs over icmp6
> and you do need a rule for that. It will currently be passed by the implicit
> default rule but that will stop when you add "block any"..
>
> "modulate state" really isn't as simple as possible ;)
>

A belated thanks for this !

Re: icmp6:
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv
pass quick inet6 proto ipv6-icmp all icmp6-type echoreq
pass quick inet6 proto ipv6-icmp all icmp6-type echorep

Re: "modulate state" I thought that was meant to be a good option these days 
instead of one of the more traditional state techniques ?



Viewing SFP diagnostic data in OpenBSD ?

2019-04-02 Thread Rachel Roch
Hi,

Hopefully I'm just searching the man pages wrong but I can't seem to find any 
hints as to how I can view SFP diagnostics in OpenBSD (i.e. light power etc.)

Perhaps someone could kindly point me in the right direction ?

Rachel



Re: bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

2019-03-29 Thread Rachel Roch


29 Mar 2019, 18:57 by rr...@tutanota.de:

> Hi,
>
> Has anyone encountered this before ?
>
> Neighbor    AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
> EXT-V6-R2   65515 50 40 0 00:02:55 Active
> EXT-V4-R2   65515 38 37 0 00:27:42  1
> After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock solid.
>
> The boxes are sitting right next to each other, connected over an OpenBSD 
> LACP trunk.
>
> I have made the pf rules as simple as possible:
>
> table  counters {self}
> table  counters {192.0.2.1,2001:DB8::1}
> pass in quick proto {tcp,udp,icmp} from  to 
>  modulate state
> pass out quick proto {tcp,udp,icmp} from  to 
>  modulate state
>
> The bgpd config is also simple:
>
> MY_ROUTER_ID_V4="192.0.2.2"
> MY_ROUTER_ID_V6="2001:DB8::2"
> MY_ASN="64515"
> AS $MY_ASN
> router-id $MY_ROUTER_ID_V4
> rde med compare always
> network inet connected
> network inet6 connected
> group its_internal_v4 {
>     remote-as 65515
>     announce IPv6 none
>     neighbor 192.0.2.1 {
>     local-address 192.0.2.2
>     descr "EXT-V4-R2"
>     }
> }
> group its_internal_v6 {
>     remote-as 65515
>     announce IPv6 none
>     neighbor 2001:DB8::1 {
>     local-address 2001:DB8::2
>     descr "EXT-V6-R2"
>     }
> }
>

Forgive me, I forgot to include what shows in the logs:

sending IPv4 unicast EOR marker
received IPv4 unicast EOR marker
received notification: HoldTimer expired
state change Established -> Idle, reason: NOTIFICATION received
state change Idle -> Connect, reason: Start
state change Connect -> OpenSent, reason: Connection opened
state change OpenSent -> OpenConfirm, reason: OPEN message received
state change OpenConfirm -> Established, reason: KEEPALIVE message received
sending IPv4 unicast EOR marker
received IPv4 unicast EOR marker



bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

2019-03-29 Thread Rachel Roch
Hi,

Has anyone encountered this before ?

Neighbor    AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
EXT-V6-R2   65515 50 40 0 00:02:55 Active
EXT-V4-R2   65515 38 37 0 00:27:42  1
After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock solid.

The boxes are sitting right next to each other, connected over an OpenBSD LACP 
trunk.

I have made the pf rules as simple as possible:

table  counters {self}
table  counters {192.0.2.1,2001:DB8::1}
pass in quick proto {tcp,udp,icmp} from  to  
modulate state
pass out quick proto {tcp,udp,icmp} from  to 
 modulate state

The bgpd config is also simple:

MY_ROUTER_ID_V4="192.0.2.2"
MY_ROUTER_ID_V6="2001:DB8::2"
MY_ASN="64515"
AS $MY_ASN
router-id $MY_ROUTER_ID_V4
rde med compare always
network inet connected
network inet6 connected
group its_internal_v4 {
    remote-as 65515
    announce IPv6 none
    neighbor 192.0.2.1 {
    local-address 192.0.2.2
    descr "EXT-V4-R2"
    }
}
group its_internal_v6 {
    remote-as 65515
    announce IPv6 none
    neighbor 2001:DB8::1 {
    local-address 2001:DB8::2
    descr "EXT-V6-R2"
    }
}




Re: How to overrule bioctl "chunk already in use"

2019-03-29 Thread Rachel Roch




29 Mar 2019, 02:42 by n...@holland-consulting.net:

> On 3/28/19 10:29 AM, Rachel Roch wrote:
>
>> Hi,
>>
>> I've been following the instructions here
>> https://www.openbsd.org/faq/faq14.html 
>> <https://www.openbsd.org/faq/faq14.html>
>> <>> https://www.openbsd.org/faq/faq14.html 
>> <https://www.openbsd.org/faq/faq14.html>>> > to setup softraid.
>>
>> Unfortunately I somehow messed up the original attempt through my own
>> stupidity.
>>
>
> it happens.
> And best that it happen before production than after.
>
>> So I've been trying to go through the steps again.  However nothing
>> I do can elminate the "softraid0 sd0a chunk already in use" message
>> at the "bioctl -c 1 -l sd0a,sd1a softraid0" step.
>>
>> I've tried everything !  Rebooting the server, /dev/zero to the
>> first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and
>> re-writing disk label.
>>
>> I looked at the man page and thought "ah ha !" ... maybe "-C force",
>> but nope !
>>
>
> you were close with the zeroing the head of the components.  In fact,
> I'm not sure what you did wrong, but that's the solution.
>
> I'd suggest starting by zeroing the beginning of each physical disk --
> using the r device and the c partition -- i.e.,
>
>  # dd if=/dev/zero of=/dev/rsd0c
>  # dd if=/dev/zero of=/dev/rsd1c
>
> I've had enough problems, I really suggest this unless you are
> absolutely sure your disk has never even heard of OpenBSD before you
> install it. :)  (I think I had figured out at one point that zeroing the
> RAID partitions was sufficient, but when it comes to zeroing, a little
> more is never too much. :)
>
> Now, if you were going to script this, you would put a block size and a
> count in there...but since you are just typing this at the command line,
> count to three and hit CTRL-C then do the next.  You really only have to
> clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C
> fast enough, I suspect. :)
>
> By using the 'r' device and the 'c' partion, you have wiped the very
> very start of the disk -- sector zero onward.
>
> I'd reboot after that.  I don't think it's needed, but either the
> disklabel or MBR partition can be held in memory and written back out to
> disk under some circumstance, I don't recall exactly what (probably
> having to do with mounted partitions), so a reboot, and then verifying
> that fdisk sd0 shows lots of zeros everywhere including the Signature.
> NOW fdisk, create your OpenBSD partition, then your RAID disklabel
> partitions, and you should be in business.
>
> If that doesn't do it, show us your exact commands and exact output you
> are seeing.
>
> Nick.
>

Thanks Nick !  Your suggestion did the trick.



How to overrule bioctl "chunk already in use"

2019-03-28 Thread Rachel Roch
Hi,

I've been following the instructions here 
https://www.openbsd.org/faq/faq14.html  
to setup softraid.

Unfortunately I somehow messed up the original attempt through my own stupidity.

So I've been trying to go through the steps again.  However nothing I do can 
elminate the "softraid0 sd0a chunk already in use" message at the "bioctl -c 1 
-l sd0a,sd1a softraid0" step.

I've tried everything !  Rebooting the server, /dev/zero to the first 500MB of 
sd0 and sd1, changing uuid in disklabel, erasing and re-writing disk label.

I looked at the man page and thought "ah ha !" ... maybe "-C force", but nope !

Any ideas 

Rachel




Re: Current thinking on OpenBSD "router" "firewall" role separation ?

2019-03-03 Thread Rachel Roch
Mar 3, 2019, 11:34 AM by s...@spacehopper.org:

> On 2019-03-02, Rachel Roch <> rr...@tutanota.de <mailto:rr...@tutanota.de>> > 
> wrote:
>
>> Hi,
>>
>> I would be interested to find out the community's view on whether separating 
>> "router" and "firewall" roles is still a good thing or whether developments 
>> in recent iterations of OpenBSD would permit aggregation whilst maintaining 
>> integrity and security ?
>>
>> If you forgive my attempt at ASCII art (which I hope survives internet 
>> mangling), this would be representative of what I would do for a 
>> "traditional" setup:
>>
>> (BGP)         (BGP)
>>    |                  |
>> ["router"] ["router"]    |  \          /  |
>>     |      \    /    |
>>     |       /   \    |
>>     |   /         \  |
>>   ["firewall"] ["firewall"]
>>
>>
>> • The routers talk full BGP externally and default-route BGP to the 
>> firewalls.
>> • The firewalls talk offer VRRP internally and also BGP default-route 
>> internally to those that can talk BGP
>> • The firewalls also offer other internal services such as NTP etc.• The 
>> firewalls also act as a VPN endpoint externally using a combination of iked, 
>> ifstated and other stuff to make it work
>> • The firewalls are very much perimeter firewalls, they don't do detailed 
>> content handling such as mail etc., that is done elsewhere
>> Various factors have led to a hardware refresh for this kit, and as part of 
>> that I'm curious as to whether I can consolidate without (a) loosing the 
>> benefits of the split model and (b) introducing too much un-necessary 
>> additional complexity.
>>
>> Thanks !
>>
>> Rachel
>>
>
> The biggest problem is that, if you're advertising on both BGP routers,
> traffic coming from the internet can hit either machine. And traffic
> from your internal networks to the internet will be via whichever is
> carp master. So you can end up with the situation where packets
> associated with one connection are going via different machines,
> which can cause problems with stateful firewalling (in particular
> the TCP sequence number checks).
>
> There are several ways to work with this but there are trade-offs
> with all of them, and if none are acceptable then 
>
> - Best option if your peer sessions are run on a subnet large
> enough for carp:
>
> upstream  192.0.2.1
> rtr1+2 carp ip192.0.2.2
> rtr1 real 192.0.2.3
> rtr2 real 192.0.2.4
>
> Run these BGP sessions:
> 192.0.2.3 <> 192.0.2.1
> 192.0.2.4 <> 192.0.2.1
>
> And set nexthop on your announcements to the carp ip (192.0.2.2).
> That way you can keep the bgp sessions up all the time on both machines
> and have the traffic flow towards whichever machine is carp master.
>
> (thanks Tony Sarendal for the clue about this method -
> https://marc.info/?l=openbsd-misc=153684583625250=2 
> <https://marc.info/?l=openbsd-misc=153684583625250=2>> )
>
> - There is a way to handle this with PF by using pfsync(4) with
> the "defer" flag but it's not perfect and it would be better to
> avoid that if possible. You need to wait until the second
> firewall has added the state before passing the traffic (this
> is what "defer" does), and also pfsync needs to send TCP sequence
> number updates all the time during the session so the other
> firewall can keep in sync, 
>
> - Another way to handle it is to hold the BGP sessions down on the
> machine that is carp backup (bgpd.conf "depend on carpX") but that's
> not ideal in a carp switchover situation as you'll have some delay
> while BGP brings up the sessions and pulls routes from the peer.
> Also you're reliant on sessions on the carp master to send you
> traffic, if an important peer on that machine goes down, you
> won't see traffic flow via the backup.
>
> - Or you can have the BGP sessions up all the time but only
> announce your networks from the carp master, you should be able to
> do that with ifstated and "bgpctl network add". As above you're
> still reliant on sessions on the carp master, but at least you
> don't need to pull the routing table after a carp switchover.
>
> If the first method is viable then there's not too much of a
> problem collapsing this onto one pair of machines. The tradeoffs
> for the other methods aren't so nice and in that case I'd usually
> want the extra machines so I could avoid them..
>

Thanks for the considered reply Stuart.  Much to consider there,  however I 
suspect the TL;DR of it will be my current thinking is much the same as you've 
come to in that the tradeoffs are quite likely fairly significant and that 
working around them will likely be more hassle than maintaining the four-box 
status quo.



Current thinking on OpenBSD "router" "firewall" role separation ?

2019-03-02 Thread Rachel Roch
Hi,

I would be interested to find out the community's view on whether separating 
"router" and "firewall" roles is still a good thing or whether developments in 
recent iterations of OpenBSD would permit aggregation whilst maintaining 
integrity and security ?

If you forgive my attempt at ASCII art (which I hope survives internet 
mangling), this would be representative of what I would do for a "traditional" 
setup:

(BGP)         (BGP)
   |                  |
["router"] ["router"]    |  \          /  |
    |      \    /    |
    |       /   \    |
    |   /         \  |
  ["firewall"] ["firewall"]


• The routers talk full BGP externally and default-route BGP to the firewalls.
• The firewalls talk offer VRRP internally and also BGP default-route 
internally to those that can talk BGP
• The firewalls also offer other internal services such as NTP etc.• The 
firewalls also act as a VPN endpoint externally using a combination of iked, 
ifstated and other stuff to make it work
• The firewalls are very much perimeter firewalls, they don't do detailed 
content handling such as mail etc., that is done elsewhere
Various factors have led to a hardware refresh for this kit, and as part of 
that I'm curious as to whether I can consolidate without (a) loosing the 
benefits of the split model and (b) introducing too much un-necessary 
additional complexity.

Thanks !

Rachel



Any experiences with recent single-socket Dell machines (i.e. R230/R330/R340)

2019-02-02 Thread Rachel Roch
Hi,

Subject line says it all really, I'm looking to hear of people's experiences 
with recent models of Dell single-socket machines (i.e. R230/R330/R340 - 
especially the newest R340, obviously!).

I'm looking for a decent machine with enterprisey features (i.e. hotswap PSU + 
drives, high-efficiency power,and high quality ipmi/ilo). I'm not chained to 
Dell if anyone better ideas, but have had good experience with Dell.

I've contemplated Supermicro machines, but quite frankly what I've read online 
about the quality of their iLO leaves a lot to be desired (combined with the 
fact my 'friendly local reseller' tells me their iLO still requires Java).

Thanks !



Experiences with single mode fibre on OpenBSD ?

2019-01-02 Thread Rachel Roch
Hi,

I see the man pages mention the odd SM fibre NIC, which is a good start.

However I could do with some real-world feedback from people in terms of the SM 
NICs they're using and any other experiences with SM on OpenBSD.

Thanks !

Rachel



Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch



> Rachel,
>
> As a first step, try using s_client to connect to a TLS service and see what 
> comes back:
>
> $ openssl s_client -connect : -showcerts
>
> There are more possible options on s_client to debug more deeply but this is 
> a good start.
>
>
> --Paul
>

In answer to the above. Testing against three "random" servers  (see bottom of 
the email for full exchange, top three are through VPN, rest are bypassing VPN):

Through the VPN:
- Server "A" (HTTPS with "real" cert)- Nothing more than "CONNECTED (0005)"
- Server "B" (HTTPS with "self-signed" cert)- Certificates get displayed (this 
correlates with behaviour seen in browser where I get shown the "do you want to 
continue" prompt, I can see details of the certs presented, but when I click 
continue it hangs)
- Server "C" (IMAPS) - Nothing more than "CONNECTED (0005)"

Bypassing the VPN:
- Server A shows certs in openssl(and browser works ok)- Server "C" shows certs 
in openssl (and email client works ok)

foobarOVERVPN $ openssl s_client -connect web1.example.com:443 -showcerts
CONNECTED(0005)
^C
foobarOVERVPN $ openssl s_client -connect web2.example.com:8443 -showcerts
CONNECTED(0005)
depth=0 C = US, ST = CA, L = San Jose, O = example.com, OU = MyCorp, CN = MyCorp
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = San Jose, O = example.com, OU = MyCorp, CN = MyCorp
verify return:1
---
Certificate chain
0 s:/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

   i:/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

-BEGIN CERTIFICATE-

-END CERTIFICATE-
---
Server certificate
subject=/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

issuer=/C=ZZ/ST=AA/L=BB/O=example.com/OU=MyCorp/CN=MyCorp 

---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1316 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 5C0575730056006E28542F880C1AB6541729337C0DDBEC95347E2B5B4669EAD7
    Session-ID-ctx:
    Master-Key: 
66B8EB1A3FB0857509627840D8DDB595659A5794D365D462DED737AAD4532F4AD542663B8BAE27A7665539D15C14ADEA
    Start Time: 1543861619
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---
^C

foobarOVERVPN $ openssl s_client -connect imaps.example.com:993 -showcerts
CONNECTED(0005)
^C
foobarBYPASSVPN $ openssl s_client -connect web1.example.com:443 -showcerts
CONNECTED(0005)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN 
= COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN 
= COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = web1.example.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=web1.example.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
-BEGIN CERTIFICATE-

-END CERTIFICATE-
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Certification Authority
-BEGIN CERTIFICATE-

-END CERTIFICATE-
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-BEGIN CERTIFICATE-

-END CERTIFICATE-
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
-BEGIN CERTIFICATE-

-END CERTIFICATE-
---
Server certificate
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=web1.example.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA 
Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 6299 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 

Re: TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch



>
> Hello, 
> This appears to be the same thing I have been having issues with and 
> mentioned in a post to misc last week ("Untable ssl connections over ikev2 
> VPN") - (yes, typo intact - it should be "unstable").
>
> I have tried adding a "max-mss 1300" directive into pf.conf (i.e.: "match in 
> all scrub (no-df random-id max-mss 1300)").
>
> At first, I _thought_ this made a difference, but I am not sure if that is 
> really true. 
>
> I have also noticed that the TLS failures seem to vary based on OS.  At this 
> point, I was able to get an https connection to work with firefox on MacOS, 
> but the TLS handshake continues to hang (100% of the time) with firefox on a 
> Windows 7 PC.  With an openBSD laptop, it seems like it sometimes works and 
> sometimes doesn't (using "openssl s_client" to test).
>
> I also made no changes in pf.conf or iked.conf from the working to 
> non-working period. 
>
> I have no idea what to do; I am just posting my observations if that helps. 
> Thanks
>

Hi,

Glad its just not me !!! Even if you don't know the fix, at least I now know I 
haven't gone completely crazy !

For me it more consistent, on OSX its 100% hang, on Windows 10 its 100% hang.  
Haven't tried OpenBSD client yet, I've been too busy putting emergency 
workarounds in place to bypass the site-to-site stuff. Will try OpenBSD client 
though when I get a chance.

Appreciate you taking the time to email ... keep in touch !





TLS suddenly not working over IKED site-to-site

2018-12-03 Thread Rachel Roch
I hope someone here can shed light on an infuriating problem I’ve spent a week 
trying to resolve without luck.

The problem concerns an IKED site-to-site VPN on OpenBSD 6.3 (both endpoints 
fully syspatched).

The VPN worked absolutely perfectly until it suddenly started behaving 
strangely.  Seriously, I’m talking about “pass any traffic you can think of”, 
then I go on holiday for a week (nobody else has physical or remote access to 
the machines, and I did not connect on holiday), then this behaviour starts.

Basically the behaviour I am seeing is that anything that uses TLS is no longer 
able to connect (or at least gets no further than trying to do a TLS handshake, 
e.g. Firefox hangs showing "performing TLS handshake..." at the bottom of the 
screen), so that means:

- HTTPS websites
- VoIP
- IMAP over TLS
- RDP over TLS

Are all broken on the VPN, but all TLS-based services continue to work 
perfectly off-site (or when the site-to-site VPN is bypassed with a third-party 
VPN).  This impacts multiple servers and multiple clients, so its not just one 
server or one desktop PC, its anything that tries to talk TLS over that VPN !


However:
- Ping (including large packet size, e.g. “-s 1600”)
- SSH
- DNS
- Anything else you care to name that doesn’t use TLS

All continue to work perfectly over the VPN.

My PF rules (which cannot possibly be the problem, because they have not 
changed a single bit between “working” and “not working) don’t even 
differentiate between traffic types, so it can’t be some sudden PF oddity :

pass in on enc from  to  keep state (if-bound) 
$midPriority
pass out on enc from  to  keep state (if-bound) 
$midPriority

Similarly, my IKED config is also completely unchanged between "working" and 
"not working", and ipsecctl -sa continues to show everything correctly 
established

ikev2 "to remote" active esp from $a_net to $b_net\
    local $local_ext peer $remote_ext \
    ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 
\
    childsa enc chacha20-poly1305 group curve25519 \
    srcid $local_ext dstid $remote_ext \
    ikelifetime 4h lifetime 3h bytes 512M \
    ecdsa384


This whole thing is just driving me crazy !