Re: File Server with OpenBSD?

[lists]

Tue, 7 Mar 2017 16:29:12 + (GMT) Roderick 
> Before I make a decision, I want to ask you for suggestions.

Hi Roderick,

As you probably know well already, read _carefully_ Nick Holland's advice
to this (and previous) threads in the OpenBSD mailing lists.  These will,
most definitely, present you important pointers to evade common pitfalls.

> I want to make a small file server, just to separate important
> files from my working system.

This simplified definition makes your solution quite obvious: a networked
computer exposing your data to the other systems.  This also defines your
all other important aspects towards the sub-defined requirements and also
is the basis for providing the solutions to all of these sub-definitions.  

> Two disks as Raid 1. Files are to
> be read with NFS. Emphasis:

OpenBSD provides these easily, you will have no problem implementing your
solution, just use the minimum required hardware and configuration setup.
 
> (1) Data Integrity (not security :).
> 
> (2) some degree of indepencence from hardware and operating system.
>  Disk are to be readable for many decades. Standard File System
>  readable after moving the Disks to another computer, different
>  hardware, perhaps with different OS.

The pointers in the thread are quite well suited with one minor omission.

The independence of hardware and operating system to ensure your data and
not only disks but the actual stored information is readable for the long
periods you design is given by: the standards, and by the protocols used.

The longest available and stable is, the Ethernet network periphery port.

Just make sure you expose your data over multiple protocols, and not only
the one you use to access it in production, e.g. add file synchronisation
and more than one data carrier protocol for archival and you're all done.

Kind regards,
Anton

> I was thinking on doing it with FreeBSD and ZFS. I find the last
> interesting because: (a) it make checksums and corrections if
> a checksum in a disk is wrong (using the other disk in the array),
> (b) many OS are implementing it. But I find horrible how
> resource hungry it is.
> 
> Do you have an idea?
> 
> I do preffer OpenBSD, but is there an appropriate file system
> for archiving?
> 
> I thank for any suggestion
> Rodrigo.

Re: Unsuccessful build unbound --with-pyunbound --with-pythonmodule to have Python scripting support

[Stuart Henderson]

On 2017-03-10, Denis  wrote:
> Trying to build Unbound-1.5.9 from /usr/src/usr.sbin/unbound with Python
> scripting support on OpenBSD 6.0 amd64

Just use the upstream tarball for this and build it separately, don't
retrofit it into /usr/src.

Re: Bizarre arp entry corruption

[Sebastian Benoit]

Joe Holden(m...@m.jwh.me.uk) on 2017.03.09 13:41:26 +:
> On 09/03/2017 11:51, Martin Pieuchot wrote:
> >On 07/03/17(Tue) 19:38, Joe Holden wrote:
> >>On 12/12/2016 16:55, Joe Holden wrote:
> >>>On 12/12/2016 10:27, Martin Pieuchot wrote:
> On 11/12/16(Sun) 00:50, Joe Holden wrote:
> >On 10/12/2016 08:43, Mihai Popescu wrote:
> seeing some bizarre behaviour on one box, on one specific interface:
> >>
> >>Hello,
> >>
> >>This looks like some stupid TV game, where contesters are given some
> >>clues from time to time and they have to guess what is the real shit.
> >>
> >>Do post your FULL dmesg and configurations for network if you really
> >>want someone to even think at your issue. Isn't that obvious?
> >>
> >>Bye!
> >>
> >
> >Appreciate the useless response (but still better than nothing!), the
> >affected box has since been reverted to older snapshot and thus no more
> >debugging can be done - someone else will have to do it.
> 
> I'd appreciate to see the output of 'netstat -rnf inet' when it is
> relevant.  Without that information it's hard to understand.
> 
> But there's a bug somewhere, it has to be fixed.
> 
> >Not that dmesg is even relevant since it is a userland bug not a kernel
> >problem but anyway:
> 
> It's a kernel problem.
> 
> >>>I'll see if I can recreate it but I'm not holding my breath - it only
> >>>breaks once BGP loaded the table which leads me to thing it is actually
> >>>bgpd that is updating the llinfo with bogus info and even though I have
> >>>a feed in my lab it doesn't do the same thing.
> >>>
> >>Ok so, inadvertantly recreated this (pretty much exactly the same) issue 
> >>on
> >>a lab/test setup:
> >>
> >>For the purposes of debug, ignore the fact that the interfaces are tap
> >>interfaces, they're still emulated ethernet...
> >>
> >>Wall of text incoming, various info...
> >>
> >>box#1:
> >>
> >>tap1: flags=8843 mtu 1500
> >>lladdr fe:e1:ba:d1:be:f3
> >>index 7 priority 0 llprio 3
> >>groups: tap
> >>status: active
> >>inet 172.20.230.72 netmask 0xfffe
> >>
> >>box#2:
> >>
> >>tap1: flags=8843 mtu 1500
> >>lladdr fe:e1:ba:d1:cf:92
> >>index 7 priority 0 llprio 3
> >>groups: tap
> >>status: active
> >>inet 172.20.230.73 netmask 0xfffe
> >>
> >>All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
> >>the following:
> >>
> >>Host Ethernet AddressNetif Expire 
> >>Flags
> >>172.20.230.7200:00:00:00:20:12   ? 12m30s
> >>
> >># route -n get 172.20.230.72
> >>   route to: 172.20.230.72
> >>destination: 172.20.230.72
> >>   mask: 255.255.255.255
> >>  interface: tap1
> >> if address: 172.20.230.73
> >>   priority: 3 ()
> >>  flags: 
> >> use   mtuexpire
> >>  20 0   702
> >>
> >>flags destination  gateway  lpref   med aspath origin
> >>IS*>  172.20.230.72/31 172.20.230.64  200 0 i
> >>
> >>.64 is the loopback on one of its connected boxes that doesn't have broken
> >>entries
> >>
> >>tcpdump looks ok, afterwards:
> >>
> >>19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
> >>19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> >>19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
> >>19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> >>
> >>but the correct entry is never installed, after I delete the broken arp
> >>entry it never readds a new one.
> >>
> >>This only happens with redist connected as far as I can tell, but bgpd
> >>probably shouldn't be able to mangle arp entries and prevent the correct 
> >>one
> >>being added.
> >
> >Here's the fix.
> >
> >Index: net/rtsock.c
> >===
> >RCS file: /cvs/src/sys/net/rtsock.c,v
> >retrieving revision 1.232
> >diff -u -p -r1.232 rtsock.c
> >--- net/rtsock.c 7 Mar 2017 09:23:27 -   1.232
> >+++ net/rtsock.c 8 Mar 2017 16:06:22 -
> >@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
> > }
> > }
> > change:
> >-if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
> >-rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
> >-tableid)))
> >-break;
> >+if (info->rti_info[RTAX_GATEWAY] != NULL) {
> >+/*
> >+ * When updating the gateway, make sure it's
> >+ * valid.
> >+ */
> >+if (!newgate && rt->rt_gateway->sa_family !=
> >+ 

Re: BGPD.conf Question

[Claudio Jeker]

> So not useful in a route server qualifying that an inbound route's next
> hop is the speaker itself. It looks like I can do that with filters, I
> just wanted to make sure I wasn't missing a better way. 
> 

Yes, you need to use a filter like:
deny from all
allow from all nexthop neighbor

nexthop qualify is as Stu already mentioned only for nexthop validation in
the RDE decision process.


> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> 
> - Original Message - 
> 
> From: "Stuart Henderson"  
> To: misc@openbsd.org 
> Sent: Wednesday, March 1, 2017 9:04:06 AM 
> Subject: Re: BGPD.conf Question 
> 
> On 2017-03-01, Mike Hammett  wrote: 
> > nexthop qualify via ( bgp | default ) If set to bgp , bgpd(8) may use 
> > BGP routes to verify nexthops. If set to default , bgpd may use the 
> > default route to verify nexthops. By default bgpd will only use static 
> > routes or routes added by other routing daemons like ospfd(8) . 
> > 
> > What is it that this does? 
> 
> This is for step 2 in the route decision process shown in bgpd(8)'s 
> DESCRIPTION section. The nexthop is normally only considered reachable 
> if it's either on a directly connected interface, or where an OSPF or 
> static route points at the nexthop. Having the nexthop for one BGP 
> route reached by the default route or by another BGP route is legal, 
> but would be an unusual and often unwanted configuration. 
> 

-- 
:wq Claudio

IKEv2 (iked) VPN with Windows 10 clients

[Roberto Katalinic]

I have a few remote workers with Windows 10 and would like to move them to
IKEv2 VPN.

On my gateway (OpenBSD 5.7) the iked.conf file is:
ikev2 "IKEv2 DIAL-IN" passive esp \
from 192.168.10.0/24 to 192.168.40.0/24 \
local 1.2.3.4 peer 0.0.0.0/0 \
srcid 1.2.3.4 \
config access-server 192.168.10.10 \
config name-server 192.168.10.21 \
config address 192.168.40.0/24

My remote client is configured like this:
VPN Type: IKEv2
Data encryption: Optional
Authentication: Use machine Certificates (no EAP)

My PF rules contain the following lines which are definitely not overruled by
any rules further down the line:
set skip on {lo,enc0}
pass in on egress proto udp from any to any port {500,4500}
pass in on egress proto {ah,esp}

When the client attempts connection, the SA is configured and Windows reports
the connection as established. It also acquires an IP address and the DNS
server as specified in the iked.conf file:

PPP adapter EDGE:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : EDGE
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.40.87(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.10.21
   NetBIOS over Tcpip. . . . . . . . : Enabled

My gateway also reports the connection as established and the SA is shown by
ipsecctl -sa:
FLOWS:
flow esp in from 192.168.40.87 to 192.168.10.0/24 peer 5.6.7.8 srcid
IPV4/1.2.3.4 type use
flow esp out from 192.168.10.0/24 to 192.168.40.87 peer 5.6.7.8 srcid
IPV4/1.2.3.4 type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x7a8197f6 auth hmac-sha1 enc aes-256
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x926fb219 auth hmac-sha1 enc aes-256

Output from iked -dvvv:
ikev2_pld_cp: INTERNAL_IP4_SERVER 0x5ba0 length 4
ikev2_pld_cp: INTERNAL_IP4_DNS 0x0003 length 4
ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4
ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length
44
ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4
xforms 3 spi 0xe7ce691f
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE
ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length
24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.40.34 end 192.168.40.34
ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00
length 24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.10.0 end 192.168.10.255
ikev2_msg_send: IKE_AUTH response from 1.2.3.4:4500 to 5.6.7.8:15573 msgid 1,
1452 bytes, NAT-T
pfkey_sa_add: update spi 0xe7ce691f
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xe7ce691f
pfkey_sa_add: add spi 0xabf256a4
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xabf256a4
ikev2_childsa_enable: loaded flow 0x1166a0b99800
ikev2_childsa_enable: loaded flow 0x1166a0b99400
sa_state: VALID -> ESTABLISHED from 5.6.7.8:15573 to 1.2.3.4:4500 policy
'IKEv2 DIAL-IN'


The problem is, from the remote worker, I cannot connect to any resources on
the remote network. Pinging the remote gateway's internal IP address or the
DNS server produces no replies.

Equally, the gateway cannot ping the remote worker's IP address.

tcpdump on the enc0 and pflog0 interfaces produces no results at all when
creating traffic between the two.

What am I missing?



Kind regards,

Roberto Katalinic
07460663373

kliker IT
www.kliker.it
08455442033

Information contained in this e-mail is intended for the use of the addressee
only, and is confidential and may be the subject of Legal Professional
Privilege. Any dissemination, distribution, copying or use of this
communication without prior permission of the addressee is strictly
prohibited. The contents of an attachment to this e-mail may contain software
viruses which could damage your own computer system. While Kliker IT Services
Ltd. has taken every reasonable precaution to minimise this risk, we cannot
accept liability for any damage which you sustain as a result of software
viruses. You should carry out your own virus checks before opening the
attachment. Registered Office: New House, South Grove, Petworth, GU280ED.
Company Number: 8206089.Company Registered in England and Wales.

Re: OpenBSD 6.0 - Silicom PE2G4SFPI35L Intel i340AM4 based

[Uday MOORJANI]

Stuart,

Thank you for your quick response. We are in requirement of a 4-Port
1000Base-LX capable network card, whether it's 10GbE or 1GbE it
doesn't matter. I took a look a the vendor, and I have to say it feels
awesome learn something new every day. I did not know this vendor and
the mere fact that they openly support OpenBSD is reassuring. I'll
have my distributor take a look at it. Thanks a lot.

/Uday

On Fri, Mar 10, 2017 at 1:47 AM, Stuart Henderson  wrote:
> On 2017-03-09, Uday MOORJANI  wrote:
>> Dear Community,
>>
>> Hope all is well. I'm on my last stretch to put in production our
>> OpenBSD/OpenBGPd implementation. I have chosen a SuperMicro box as my
>> platform, some of our transit providers at the data center come in
>> through 1000-Base-LX fiber cross connects hence the search for an SFP
>> and LX capable network card.
>>
>> My question is, does the em driver work with Intel-based network cards
>> of other vendors such as the Silicom PE2G4SFPI35L or the PE2G4SFPI80L,
>> both respectively are based on Intel i340AM4 and 82580EB controllers.
>
> I haven't tried those Silicom cards but I have a couple of 6-port
> HotLava 1000base-T em(4) cards which are working nicely.
>
> I don't see I340AM4 on the list in the em(4) manual. I can't say whether
> this is just an omission from the manual, or whether it's unsupported.
> 82580EB is listed there.
>
>> Or is there another card with 4-Ports 1000-Base-LX capable hardware I
>> missed?
>>
>> Sincerely,
>>
>> Uday MOORJANI
>>
>> PS
>> Loving the OS.
>>
>>
>
> When I had a circuit delivered on single-mode fibre I couldn't find
> a suitable 1Gb SFP card for any sensible money so I used a 10Gb card
> instead (in my case some 82599-based Intel SFP+ which uses the ix(4)
> driver), which also work with 1Gb SFPs.
>
> $ ifconfig ix1 | grep -e ^ix -e media
> ix1: flags=8843 mtu 1500
> media: Ethernet autoselect (1000baseLX full-duplex,rxpause,txpause)
>
> $ dmesg | grep ^ix1 | tail -1
> ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01: msi, address 
> 00:1b:21:c0:25:bd

Re: BGPD.conf Question

[Mike Hammett]

*bump* 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mike Hammett"  
Cc: misc@openbsd.org 
Sent: Wednesday, March 1, 2017 11:09:09 AM 
Subject: Re: BGPD.conf Question 

So not useful in a route server qualifying that an inbound route's next hop is 
the speaker itself. It looks like I can do that with filters, I just wanted to 
make sure I wasn't missing a better way. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


- Original Message - 

From: "Stuart Henderson"  
To: misc@openbsd.org 
Sent: Wednesday, March 1, 2017 9:04:06 AM 
Subject: Re: BGPD.conf Question 

On 2017-03-01, Mike Hammett  wrote: 
> nexthop qualify via ( bgp | default ) If set to bgp , bgpd(8) may use 
> BGP routes to verify nexthops. If set to default , bgpd may use the 
> default route to verify nexthops. By default bgpd will only use static 
> routes or routes added by other routing daemons like ospfd(8) . 
> 
> What is it that this does? 

This is for step 2 in the route decision process shown in bgpd(8)'s 
DESCRIPTION section. The nexthop is normally only considered reachable 
if it's either on a directly connected interface, or where an OSPF or 
static route points at the nexthop. Having the nexthop for one BGP 
route reached by the default route or by another BGP route is legal, 
but would be an unusual and often unwanted configuration. 

Unsuccessful build unbound --with-pyunbound --with-pythonmodule to have Python scripting support

[Denis]

Trying to build Unbound-1.5.9 from /usr/src/usr.sbin/unbound with Python
scripting support on OpenBSD 6.0 amd64

What was done before build:

1. pkg_add swig-2.0.11p2 python-2.7

2. Added into /usr/src/usr.sbin/unbound/Makefile.bsd-wrapper
+LDFLAGS="-L/usr/local/lib"
+--with-pyunbound \
+--with-pythonmodule \
- PATH="/bin:/usr/bin:/sbbin:/usr/sbin" \

3. Copied necessary Python related sources (from official unbound-1.5.9
sources) into /usr/src/usr.sbin/unbound/ dir:
cp -R libunbound/ /usr/src/usr.sbin/unbound/ && cp -R pythonmod/
/usr/src/usr.sbin/unbound/

4. Patched /usr/src.usr.sbin/unbound/libunbound/python/libunbound.i:
-%include "libunbound/unbound.h"
+%include "../unbound.h"

5. While running build from source libtool make an error:
...
/usr/local/bin/swig -python -o libunbound/python/libunbound_wrap.c -I.
-I/usr/local/include/python2.7 -DPY_MAJOR_VERSION=2
/usr/src/usr.sbin/unbound/libunbound/python/libunbound.i
./libtool --tag=CC --mode=compile cc -I.  -I/usr/src/usr.sbin/unbound
-I/usr/local/include/python2.7 -O2 -pipe-o libunbound_wrap.lo -c
libunbound/python/libunbound_wrap.c
libtool: compile:  cc -I. -I/usr/src/usr.sbin/unbound
-I/usr/local/include/python2.7 -O2 -pipe -c
libunbound/python/libunbound_wrap.c -o libunbound_wrap.o
./libtool --tag=CC --mode=link cc  -I.  -I/usr/src/usr.sbin/unbound
-I/usr/local/include/python2.7 -O2 -pipe   -L/usr/local/lib -module
-avoid-version -no-undefined -shared -o _unbound.la libunbound_wrap.lo
-rpath /usr/local/lib/python2.7/site-packages L. -L.libs -lunbound
libtool:   error: cannot build a shared library See the libtool
documentation for more information. Fatal configuration error.
*** Error 1 in obj (Makefile:407 '_unbound.la')
*** Error 1 in /usr/src/usr.sbin/unbound (Makefile.bsd-wrapper:51 'gnu')

6. My partial obj/Makefile  (Which produces Makefile:407 _unbound.la
error)is:
...
SHELL=/bin/sh
VERSION=1.5.9
srcdir=/usr/src/usr.sbin/unbound
prefix=/usr/local
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
sbindir=${exec_prefix}/sbin
mandir=${datarootdir}/man
libdir=${exec_prefix}/lib
# datarootdir is here to please some checkers, use datadir.
datarootdir=${prefix}/share
datadir=${datarootdir}
includedir=${prefix}/include
doxygen=
libtool=./libtool
staticexe=
EXEEXT=
configfile=/var/unbound/etc/unbound.conf
CHECKLOCK_SRC=testcode/checklocks.c
CHECKLOCK_OBJ=
DNSTAP_SRC=
DNSTAP_OBJ=
WITH_PYTHONMODULE=yes
WITH_PYUNBOUND=yes
PY_MAJOR_VERSION=2
PYTHON_SITE_PKG=/usr/local/lib/python2.7/site-packages
PYTHONMOD_INSTALL=pythonmod-install
PYTHONMOD_UNINSTALL=pythonmod-uninstall
PYUNBOUND_INSTALL=pyunbound-install
PYUNBOUND_UNINSTALL=pyunbound-uninstall
UNBOUND_EVENT_INSTALL=
UNBOUND_EVENT_UNINSTALL=
UNBOUND_VERSION_MAJOR=1
UNBOUND_VERSION_MINOR=5
UNBOUND_VERSION_MICRO=9
ALLTARGET=alltargets
INSTALLTARGET=install-all
SSLLIB=-lssl
...
# Pyunbound python unbound wrapper
_unbound.la:libunbound_wrap.lo libunbound.la
$(LIBTOOL) --tag=CC --mode=link $(CC) $(RUNTIME_PATH)
$(CPPFLAGS) $(CFLAGS) $(LDFLAG
S) -module -avoid-version -no-undefined -shared -o $@ libunbound_wrap.lo
-rpath $(PYTHON_SIT
E_PKG) L. -L.libs -lunbound
...
---

If you need mo info I can make any.

Thank you for answer in advance.

Re: File Server with OpenBSD?

[Roderick]

On Thu, 9 Mar 2017, Karel Gardas wrote:


I ask this because I want to know if I will make me dependent of
todays stand of OpenBSD.

Mounting ffs partitions of OpenBSD in FreeBSD and the opposite
is possible without big problems. Will this change with Raid?


Yes, as FreeBSD does not know anything about OpenBSD's software raid.


And even "ccd" seems not to be a solution. We read in the man page
of FreeBSD:




Note that a one-disk ccd is not the same as the original partition. In
particular, this means if you have a file system on a two-disk mirrored
ccd and one of the disks fail, you cannot mount and use the remaining
partition as itself; you have to configure it as a one-disk ccd. 
<<


Perhaps is too naive to think it would be enough to edit the label,
RAID seems to be a complicated issue.

ccd lived long (not anymore in OpenBSD), but I do not know
if the versions in the many BSDs are compatible.

And if ZFS will live longer than the hype is also a big question.

No way to avoid frequent backup, migration and system mutation for the
simplest use.

Rodrigo.

Re: Please: Is there ANY chance that Linux binaries might run again???

[Jiri B]

On Fri, Mar 10, 2017 at 12:23:12AM +0100, Stefan Wollny wrote:
> For the very reason I use OpenBSD: Confidentiality.

Wouldn't running closed source Linux binaries on OpenBSD conflict
with your trust? Those binaries cannot be pledge etc...

IMO it's better if we would have a "VMM bootloader" which would support
running any OS. At least VMM has better security design than compat_linux
had.

j.