Re: PC Engines APU platform EOL

[Damian McGuckin]

I will try and summarize the replies succinctly. As Stuart mentioned, by 
wanting fanless AND rackmount, I was certainly limiting my choices.


Thanks - Damian

Re: PC Engines APU platform EOL

[Damian McGuckin]

On Thu, 4 May 2023, Stefan Sperling wrote:


The edgerouter 6p works with OpenBSD/octeon and has a rackmount bracket.


Wow. And it has a serial port. with an RJ45 connector. Hopefully the RS232
pinouts are nicely documented somewhere. Cannot seem to find those details
right now.

I wonder whether the Edgerouter 8 with double the RAM is a wiser choice?

I will go and read the installation instructions for OpenBSD.

I see there was some feedback in 2018 from Bryan. He used an SSD mounted 
over the USB port (and had some issues). Looks like it works at up to 
about 450Mbps. Probably enough. Probably should test it against 7.3 then.


Thanks - Damian

Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: PC Engines APU platform EOL

[Damian McGuckin]

On Thu, 4 May 2023, Maksim Rodin wrote:


Is there any problem with fanless x86_64 mini PCs with several NICs,
sold on aliexpress?


Maybe, or give up on the rackmount and buy the R86S, as in

https://www.aliexpress.com/i/1005004765507664.html

An alternative is to buy 3 APU4s now 3 to cover failures and spares over
the next few years. Hopefully, they still have some left.

Thanks - Damian

Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: PC Engines APU platform EOL

[Damian McGuckin]

Happy apu2 & apu4 user here.


Ditto.


Are there other OpenBSD friendly options?


Same question but qualifying that to add FANLESS and RACKMOUNT.

I am thinking of trying an Intel Ruggest NUC for some scenarios but at 
best, they have dual RJ45 ethernets.


Thanks - Damian

Booting OpenBSD 7.3's i386 bsd.rd

[Damian McGuckin]

What is required please?

I am trying to boot this bsd.rd (which is a file 4Mb big) on an old 
NET5500 which has 512MBytes of RAM.  On a running system,



From the


boot>

prompt, doing

boot> boot bsd.rd

it appears to loads bsd.rd, but then drops straight back into the BIOS
and starts the BIOS boot.

Any suggestions.

Thanks - Damian

Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

PF rules to block out every IP from a given country

[Damian McGuckin]

Has anybody created rules such as this and if so, do you have an example?

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Crashing 64bit (AMD) 6.7 kernel on APU2

[Damian McGuckin]

Hi,

For the first time ever, we have seen a crashing kernel. Having never 
experienced this before on any OpenBSD release for over 20 years, I have 
no debugging experience. We have simply reverted to 32bit to see it that 
is the issue. The system works flawlessly with 6.3 in 32 bit mode but we 
thought we should update.


This is on an APU2 with an AMD64 release.

Has anybody seen the same problem?

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: NPPPD Server behind a firewall

[Damian McGuckin]

On Wed, 16 Oct 2019, Stuart Henderson wrote:

I would srongly recommend switching to IKEv2 if you can, it is far 
easier to come up with a config that still gives decent crypto with 
mixed client platforms. (Internal client on Apple OS and non-ancient 
Windows - strongswan on Android/Linux).


I do not disagree.

I just need to move an existing NPPPD to behind a firewall in the short 
term that serves several iPads and Windows PCs. Once I have the move done, 
I want to move expand to IKEv2. I was also under the impression that IKEv2 
was faster.


The IPsec side should be ok as long as everything supports nat-t (not 
unusual).


I am still stuck and will try some new things on Monday.

Regards - Damian

Re: NPPPD Server behind a firewall

[Damian McGuckin]

On Mon, 14 Oct 2019, Stefan Sperling wrote:


On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:

Because I had a working L2TP server setup on $L2TP, I was not going to
go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MYSECRET"


As an aside, you should avoid use of 3des because it is effecively 
plaintext.


I take your point about 3des but I was starting from a known configuration 
which works (albiet with the external interface hacing a Public IP)



There are ways to make even Windows clients use actual crypto with IPsec if
needed, though last I checked it could not be done from the GUI but required
powershell commands. (I don't have a URL handy, sorry, but this information
wasn't very hard to find when I needed it.)


Thanks. I will investigate. This has to work with iPads as well. Yuk!


You could try to pin-point the problem a bit more, starting with diagnostics
at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.


OK.


I suspect getting IPsec SAs going with both peers behind NAT is tricky.


I agree.

See my subsequent post where I replaced 'egress' above with the external 
IP (of the subsequently NAT'd npppd server). Closer. But not quite there.


Thanks - Damian

Re: NPPPD Server behind a firewall

[Damian McGuckin]

I changed /etc/ipsec.conf to have 'ike' reflect the external IP

ike passive esp transport \
proto udp from $L2TPX to any port 1701 \
main auth "hmac-sha1" enc "aes" group modp2048 \
quick auth "hmac-sha1" enc "aes" group modp2048 \
psk "MYSECRET"

and restarted isakmpd and reloaded ipsec.conf.

On the inside of the NPPPD server, the only errors I get are

isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_384, 
expected MODP_2048
isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_256, 
expected MODP_2048

and I believe it should negotiate the groups. It should also negotiate "3des"
and my earlier "modp1024" but I wanted to minimize lines of errors.

While this is happening

ipsecctl -s flow (shows)

flow esp in proto udp from REMOTE-FW port l2tp to $L2TPI port l2tp peer
REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type use
flow esp out proto udp from $L2TPI port l2tp to REMOTE-FW port l2tp peer
REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type require

Note that there are only 2 lines above. I

Which reflects the network

[laptop-192.168.0.146]<->REMOTE-FW --internet-- FIRE<->SERVER-IP=$L2TPI)

and the firewall FIRE nats $L2TPX->$L2TPI

But, the VPN is never established, eventually

ipsecctl -s flow (shows)



Still at a loss.  Any suggestions?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

NPPPD Server behind a firewall

[Damian McGuckin]

I have a L2TP NPPPD server machine with IP $L2TP sitting behind an OpenBSD 
firewall, say FIRET. 'T' for temporary because it will move. $L2TP is an 
externally routable IP. $Ext, the external interface of FIRET, allows

traffic into $L2TP. A snippet of pf.conf is

begin snippet-0
ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TP port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TP
pass in quick on $Ext inet proto ah from any to $L2TP
end snippet-0

It all went wonderfully. It worked. I have done it before.

Because I had a working L2TP server setup on $L2TP, I was not going to
go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MYSECRET"

Now I want to move the machine to a new site behind a new OpenBSD firewall,
say FIRE. The difference is that now, $L2TP will have an unroutable address,
say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
obviously have an external address, $L2TPX, but that will be exposed through
FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

So on FIRE, where we will call the external interface, $Ext, again. I 
first binat things on FIRE.


match on $Ext from $L2TPI to any binat to $L2TPX

Because BINAT'ing is done before 'pass' rules are processed, the rules must
refer to the external interface.  Just to be sure, I will ensure that I can
SSH to $L2TPI, on FIRE I have a pf.conf with

pass in quick on $Ext inet proto tcp from any to $L2TPI port ssh\
flags S/SA modulate state

Yes, that works. I can SSH to $L2TPX and get all the way through FIRE and
get in through the interface $L2TPI of the NPPPD server.

OK, now I need to let the other protocols through. I think I want all 
traffic, once it gets onto $Ext, to be allowed through to the internal 
network on which $L2TPI sits with its IP 10.200.100.200.


begin snippet-1

ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TPI port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TPI
pass in quick on $Ext inet proto ah from any to $L2TPI

end snippet-1

I can see traffic destined to 10.200.100.200 coming in through the external
interface of FIRE and going out to 10.200.100.200 and then, from within this
machine, i.e. the NPPPD Server, I see traffic coming in, admittedly on port
ipsec-nat-t, i.e. 4500. But it fails.

Any suggestions on what I have done wrong or what I need to do right.

Thanks - Damian

Re: "Re: stub-addr in unbound.conf & unbound man page wording"

[Damian McGuckin]

On Wed, 26 Jul 2017, Damian Haehlen wrote:


do-not-query-localhost: no


Damian - that fixed it.

Not that I have a clue what is going on there. The default interface is 
127.0.0.1 so I am amazed that it gets into a list that you cannot query

by default.

Yet again - I was doing something wrong.

Thanks heaps - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: stub-addr in unbound.conf & unbound man page wording

[Damian McGuckin]

Theo,

On Wed, 26 Jul 2017, Theo de Raadt wrote:


This is due to the socket pledge code, with SOCK_DNS.  This area was
damaged during the transition to pledge, and hasn't been repaired.


I am not convinced it is. But I can always be proven wrong and often am.

I think my problem is purely an issue with unbound or maybe the way I am 
using/configuring it.


On a machine, let's call it Oz, 

NSD is listening on port 8053 on both 127.0.0.1 and 10.10.10.10, Oz's 
internal interface. 'PF' on Oz's external interface (X.Y.Z.T) redirects 
port 53 to port 8053 on lo0 (127.0.0.1) and DNS queries through that 
external interface work. So NSD is working, and on 127.0.0.1, it would 
seem.


Unbound is listening on port 53 on both 127.0.0.1 and 10.10.10.10.

With the following entry in unbound.conf

stub-zone:
name:   "turkeys.com.au."
stub-addr: 10.10.10.10@8053

I can resolve 'roasted.turkeys.com.au' perfectly with dig or nslookup 
which do queries on port 53. So, I know that the host is in the file and 
it would appear that I have not screwed up my unbound configuration too 
badly.


But changing unbound.conf ever so slightly to

stub-zone:
name:   "turkeys.com.au."
stub-addr: 127.0.0.1@8053

and queries on port 53 for 'roasted.turkeys.com.au' fails. And yes, the 
lines for 'access-control' are correct. Unless I need some other special 
command or option for 127.0.0.1 such as 'private-domain' or something? I 
know that a query through the external interface RDR'd to 127.0.0.1@8053

resolves perfectly.

Am I silly? What is difference in the above context between

10.10.10.10 and 127.0.0.1

Doesn't 'pledge' just thinks they are IP addresses?

Host names have been changed to protect the guilty!

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

stub-addr in unbound.conf & unbound man page wording

[Damian McGuckin]

STUB-ADDR (of unbound.conf): 127.0.0.1@PORT (fails)
---

I can run NSD on port 8053 on the interface 127.0.0.1 for a domain say

turkeys.com.au

I can then query hat externally (with 'pf' doing an 'rdr' from some 
external IP 'rdr'd to 'lo0') and it works.


But if I run 'unbound' on port 53 the same machine as that NSD and then 
have a 'stub-zone' in my unbound.conf specified as


stub-addr: 127.0.0.1@8053

then a 'dig' or 'nslookup' fails even though I can get to port 8053 on 
127.0.0.1.


But, if I then run NSD on the IP of a real interface, i.e. not 'lo', and 
then use that IP as the stub-addr, it works.


Why cannot unbound query NSD on 127.0.0,1 when other people (from the 
outside) can get through to it. Basically, why doesn't 127.0.0.1 work as a 
stub-addr?


There is some mention in the Changelogs of 2008 that this is working.

The ideas of digging through the source code (to find out why it now does
not) really does not enthuse me.

Also, where one has a 'forward-zone' of "." on a machine where there is an 
running NSD controlling several zones, say A, B and C, should one have a 
separate forward-zone for those 3 zones which can be satisfied locally 
rather than having them go out to some global 'catch-all' forwarder if a

name is not in the case.

UNBOUND.CONF: Wording of man page
-

I had a look at the English in the unbound man page talking about 
forward-first.


If enabled, a query is attempted without the forward clause if it
fails.

Does this mean that

If enabled, and if a query fails to all the forward-addr hosts,
that same query is re-attempted without the forward clause.

I assume that means that the query is reattempted locally which I guess 
would only mean going to stub-zones.


The second sentence says

The data could not be retrieved and would have caused SERVFAIL
because the servers are unreachable, instead it is tried without
this clause.

Does that mean that

This situation happens when data could not be retrieved because
the servers are unreachable. While normally, this would cause a
SERVFAIL, instead the error is ignored the request is retried
without forwarding active, i.e. it is retried locally.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Libreoffice Calc (sometimes) kills X when attempting to import a CSV file?

[Damian McGuckin]

On Sat, 6 May 2017, Stuart Henderson wrote:


I've seen this once, but wasn't able to trigger it again.


Ditto, but under Gnome on Linux - CentOS 6.6.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Performance Clang

[Damian McGuckin]

On Tue, 25 Apr 2017, Marc Espie wrote:


On Thu, Apr 20, 2017 at 11:14:24PM +0200, Heiko wrote:

Thank you for the info. So you expect a lower time in future.


If we eventually remove gcc 4.2.1, yes, the time will go down from
clang+gcc to clang without gcc :)

Apparently, it seems that lld might be better behaved than binutils ld
in *some* respects like speed and memory consumption in *some* cases...

we'll see.


Doesn't Clang have superior (and integrated) static analysis tools?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: printf(3): extra parameters, %b token, and cpp antics

[Damian McGuckin]

On Sun, 23 Apr 2017, Jonathan Gray wrote:


http://man.openbsd.org/printf.9


Is the use of '%b' an addressing-out-of-bounds bug waiting to happen or is 
there some sort of inbuilt protection that I cannot see?


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

AMD Ryzen

[Damian McGuckin]

Has anybody achieved an installation of OpenBSD on this yet please?

Just curious whether it is worth the effort to try.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

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

[Damian McGuckin]

On Tue, 7 Mar 2017, Stefan Wollny wrote:


Yes - I will (again) contact SoftMaker trying to persuade them to
provide an OpenBSD-version of their office suite. But they seem to have
none with some decent Unix/OpenBSD-knowledge, just Linux. Sigh...


I would buy SoftMaker on OpenBSD.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

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

[Damian McGuckin]

On Tue, 7 Mar 2017, Ingo Schwarze wrote:


Regarding your task at hand:

If you want to run MS Word, your best bet is running MS Windows.
If you want to run binary-only Linux software, your best bet is
running Linux.  Ideally, on dedicated hardware that is not
connected to the Internet.


We use OpenBSD for crucial server infrastructure, Linux for some end-user 
applications, and have a Windows Machine to which anyone can connect with 
an RDP client like 'rdesktop'. We use Windows Terminal Server if lots of 
people need a Windows system.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: serial port expansion card

[Damian McGuckin]

Maybe we need a list of recommended serial port add-on cards although the 
thrust of other's arguments is to simply buy a good USB->serial adapter.


I just bought a little VIA box with serial ports which I hope will act as
a nice way to connect to the consolves my ALIX boxes which will arrive in
the next week or so.

I have not worked on serial port drivers for nearly 20 years and I only 
ever worked on SGI, MIPS, SUN and BSDI kernels. When I worked on really 
good hardware implementations of serial ports, the work was extremely

satisfying. And the reverse was also too true.

And for fear of starting a war, I will say nothing about the 'tty' driver.

So take this with a grain of salt.

On Fri, 3 Mar 2017, Stuart Henderson wrote:


I think I've sometimes seen similar hangs when the card wanted
something from the handshake lines that wasn't being provided.
If it's not plugged in yet (with a null modem adapter if needed,
note not just a gender-changer) then plugging it in might make
it come to life.


If this is required, something is poorly implemented with either the 
hardware or the driver.


Mind you, we are often stuck with hardware so this is often the only
workaround.

What I tend to do for consoles on PCs is use a DE9-RJ45 adapter, and in 
that adapter I loop back DTR-DSR and CTS-RTS (so as soon as the computer 
raises DTR it sees DSR) and just connect GND/RXD/TXD between the 
machines which avoids a few headaches..


Is this still needed. It is probably tolerable in this day and age where 
ports can do over 100kBaud. But still a bit rough.


One would think that by now, serial port technology would be perfect. But 
sadly no, if only because the demand no longer exists to support a vibrant 
mix of products. Some of the older Motorola (and TI, Cosystems, and ...) 
serial port cards were sheer works of art, and especially the ones with 
CPU offload features.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: 6.0/i386 memcpy(3) causes crash if DST < SRC, because of overlap

[Damian McGuckin]

Theo, Stuart, +

On Mon, 20 Feb 2017, Theo de Raadt wrote:


It replaces optimised(?) .S versions of memcpy with the shared C
code that contains the test & syslog_r & abort.

There's got to be a performance cost, not using the .S versions.


What is the average size of the copy please?

Years ago, I did a whole lot of tests with this. I was so disappointed 
with memcpy that I NEVER use memcpy these days, only 'memmove'. I grew

up with 'bcopy' so I tend to think in terms of safe overlapped copies.


Yet here we are about a year later, still finding benieft from this
mechanism which finds an obscure bug at runtime.

Maybe we need to write the crashing code into each of the .S versions.


Unless you are trying to identify/block copying of overlapping data, and 
correct me if I am wrong, but depending on the overlap, cannot you just 
copy forwards or backwards to avoid over-writing data you are trying to 
copy.


Does some of todays hardware have problems with cache optimization if you 
are walking backwards through the cache?


Or is the whole point to avoid overlapping copies in the first place?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Memory alignment

[Damian McGuckin]

On Sat, 28 Jan 2017, Kyoung Jae Seo wrote:


Maybe posix_memalign(3) is API you are looking for.


No. This allocates memory.

I already have the buffer. I am trying to use space within it.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Memory alignment

[Damian McGuckin]

What is the recommended most portable way to force memory alignment for a 
datum of any type, assuming one has a pointer say


char *x

I currently use something like

char *xany = aligntonext(x, sizeof(long))

where I use my own function 'aligntionext' which is defined below and I 
also assume that a 'long' will be the natural word-size of the machine and 
that any datum things just needs to align to this boundary. That said, if 
the second argument is say 4k, the function will align its result to a 4k 
boundary.


I was wondering if there is an optimal, better, more acceptable, or more 
portable, way.


I tried to look in malloc.c and realized that now there are 6 versions in 
/usr/src. After reading them all, my head started spinning.


Is there was an easy answer?

Regards - Damian

Source of aligntonext -->

#include
#include
#include
/*
 *  http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetTable
 */
static unsigned int
numberofsetbits(unsigned int i)
{
 i = i - ((i >> 1) & 0x);
 i = (i & 0x) + ((i >> 2) & 0x);
 return (((i + (i >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24;
}
/*
 * adjust pointer such that is aligned to a given number of bytes
 */
void *
aligntonext(void *x, size_t size)
{
unsigned int bits = numberofsetbits((unsigned int) (size - 1));
unsigned long long p = (unsigned long long) x;

assert(size == (size_t)(1 << bits));

p += (1 << bits) - 1;
p >>= bits;
p <<= bits;

return (void *) p;
}

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

On Mon, 16 Jan 2017, Nick Holland wrote:

So. You can run a recursive resolver, an authoritative server, and a few 
(or a lot) selectively poisoned forwarding resolvers (for DNS 
filtering), each on their own 127/8 address, and use PF or unbound to 
select which one a particular user gets access to.


# ifconfig lo0 alias 127.0.0.2 netmask 255.255.255.255
$ ifconfig lo0
lo0: flags=8049 mtu 32768
   index 3 priority 0 llprio 3
   groups: lo
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
   inet 127.0.0.1 netmask 0xff00
   inet 127.0.0.2 netmask 0x

NSD/UNBOUND require rethinking a lot of wrong-ideas that BIND permitted
and encouraged for years.


Agreed. I think Peter Phillips alluded to much the same.

As I noted previously in my reply to Stuuart Henderson, I listing on 'lo0' 
without the alias, i.e. 127.0.0.1. It works. External DNS queries should 
work because I redirect DNS using 'rdr-to lo0 port NSD-listening=-port'. 
Unfortunately, the ISP is blocking port 53, hence my need to debug the

problem.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

Sorry, lots of good ideas got thrown up while I was asleep.

On Mon, 16 Jan 2017, Stuart Henderson wrote:


In that case, unbound bound to an internal address, and NSD not bound to a
specific address, or bound to external and 127.0.0.1.


I did the last of these. Which still needs 'rdr-to' on the external 
interface.



Which code, the 'dig' side or the daemon sucking on the port? I probably
need to discuss this over a beer because there must e something I am
missing.


The dig side. Pledge restricts what a process is able to do (killing the 
process if something other than this is attempted), so any bugs in dig 
causing it to do something other than the expected would trigger this. 
Since DNS packet parsing is rather complex and is by definition working 
on untrusted network input,


Understood. That still does not negate my need for a utility to suck on 
any port and 'grok' DNS-speak. Whether it is dig or anything else, I do
not care. But a tool which enables you to test/debug a program on a 
non-standard port, whether it be for DNS, or whatever, is a key part of

our toolkit. Mind you, I can speak SMTP so I still use 'telnet' to debug
my mail issues so I do not need it for port 25. But DNS, no way.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

On Mon, 16 Jan 2017, Stuart Henderson wrote:


On 2017/01/16 15:37, Damian McGuckin wrote:

On Mon, 16 Jan 2017, Stuart Henderson wrote:


In normal operations NSD _does_ run on port 53.


Yes. But if you want both NSD and UNBOUND running on the same box, things
need to change.


Not necessarily, because they can run on different addresses. For 
example you could have unbound bound to an internal address and NSD 
listening to an external one.


I am not an NSD/UNBOUND expert, but

If you run NSD on the external link (pppoe0) and that external link does 
not come up, as when the external (ADSL) phone link is down, anything that 
NSD is handling for the internal machines in the network is unavailable.

So it needs to run off an internal interface.


I'm not sure how you're fetching code to see this, but if it's showing you
pledge in 5.1 then something is wrong with it, it's a much newer addition.


Ignore those comments. Looking at the 'diff' back the front. There is no 
pledge in the 5.1 code.



I thought the whole idea of using NSD/UNBOUND is to avoid installing
'isc_bind'.


Well, the tools you're using for this are part of BIND...


Yes, under sufferance. I looked at 'drill' but it looked like too much 
work. Long term, might be a great idea as Craig Skinner suggests ...


Could NLnetLab's libldns & drill totally replace all this?

I still cannot see what risk there is on qujerying a DNS on a 
non-standard port. Enlighten me please?


None, if that's what you are expecting to do.

Plenty, if the code has been subverted to make an unexpected network 
connection.


Which code, the 'dig' side or the daemon sucking on the port? I probably 
need to discuss this over a beer because there must e something I am 
missing.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

On Mon, 16 Jan 2017, Theo de Raadt wrote:


There's a small piece some people have missed.  pledge doesn't
block port 53.  It is blocked unless you use SOCK_DNS.  That was
a step taken seperate "hostname/dns lookup" pieces of code from
"internet speaking" pieces of code.  That step allowed pledge to
do something really cool.


Based on that, my earlier comment about the socket(2) manpage is wrong. 
Apologies. My comment about port 53 being hard-coded into 'asr_run (3)' 
does however still stand.



Yes, we changed unix.


It will be 50 years old soon so that will start to be more common. Mind 
you, some of the networking is only just over 30 years old.



Someone could write a diff, and test it well...


Is it that simple? or should one look at doing a replacement library along 
the lines of 'asr_run(3)' first.


As an aside, the 'host' command, the simple version of dig, does a pledge 
with 'inet' included.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

On Mon, 16 Jan 2017, Sebastien Marie wrote:


On my OpenBSD 5.1 system, '-p' was still allowed, and it had a pledge list
of "stdio dns". When 'rpath' was added to the pledge list, it was at this
time at which '-p' was effectively disabled.


The implementation of "dns" promise has been refined with the time.


Got it. I am enlightened.


In these restrictions, the port number is included: a socket flagged
with SOCK_DNS couldn't use another port than 53.


OK. That explains a lot.


And it is the link with -p flag.


OK. That explains everything.

Note that in socket(2), it says

SOCK_DNS
For domains AF_INET or AF_INET6, only allow connect(2),
sendto(2), or sendmsg(2) to the DNS port (typically 53).

Those words are a lot looser than your words which are

a socket flagged with SOCK_DNS couldn't use another port than 53.

It would appear there is nothing typical about 53. It is either 53 or it 
is nothing. In the light of the your comments, the last few words should 
say something to the effect


to the DNS port (only 53 allowed)

Looking in the code within 'asr_run(3)' shows that 53 is hard-coded.


For looking up DNS records, "dns" is the right promise to use.


Others use dig as a DNS server debugging tool and I think in those cases
the port restriction (and forcing traffic through rebound if it's running)
can get in the way.


I agree with sthen@. For debugging purpose, things are more complex, and
"dns" doesn't fit well.


I am not convinced that the ISC's move to 'dig' from nslookup and the even 
simpler utility 'host' was done as cleanly and securely and as flexibly as

it could have. But I did not contribute so who am I to complain.


sthen@, does a subpackage for tools like dig could be a way ? Eventually
with pledging it with "inet" (instead of "dns") ?


One of the strengths of Unix is that its user tools can act as diagnostic 
tools. Trying to limit that flexibility is counterproductive at times. And 
balancing that with security is a difficult task and I am not sure I have 
the answer. However, having 2 versions of 'dig' is not a solution. And as

I /usr/local/WHATEVER first, the 'pledged' dig would be lost.

All I know is that having a working utility with 'dig -pPORT#' saved me an 
inordinate amount of time in identifing my own particular esoteric problem 
over the last weekend. It has put me in a position where I can complain 
(loudly) to the ISP knowing the problem is theirs!  Now my only issue is 
identifying where in the router chain is there the rule while blocks port 
53 getting through to the OpenBSD box. It seems like the ISP hierarchy 
cannot find the problem. I wonder if there is something like 'traceroute' 
for DNS requests.


Looking at the whole functionality of host/nslookup/dig, along with, or in 
the context of the asr_run(3), might be a useful exercise. But what do I 
know, except maybe a little bit more than I did before I read your reply 
Sebastien!


Many thanks for taking the time to explain the issues. Tout est clair!

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

On Mon, 16 Jan 2017, Stuart Henderson wrote:


In normal operations NSD _does_ run on port 53.


Yes. But if you want both NSD and UNBOUND running on the same box, things
need to change.

Prior to the change to make -p an error, but after the dns pledge was 
added, -p was allowed but ignored with a warning. See the commit adding 
SOCK_DNS.


On my OpenBSD 5.1 system, '-p' was still allowed, and it had a pledge list 
of "stdio dns". When 'rpath' was added to the pledge list, it was at this 
time at which '-p' was effectively disabled.


ADSL ISPs here in Australia have some (cheap) home-user connections with 
ports blocked, while for business-user connections, ports are not blocked.
But they regularly screw up by blocking ports for business users so I need 
a tool to test. So I need an internet testing tool.



Maybe I need more enlightening on my poor understanding of pledge as to
why restricting the port number to only 53 is needed.


Some people just use dig for looking up DNS records and I think for them
the dns pledge restrictions are a useful way to limit bug damage.


Pledge is great. But I cannot see the link between pledge and killing off 
the '-p' option. Maybe I am getting senile, or just too much summer sun on 
my brain.



Others use dig as a DNS server debugging tool and I think in those cases
the port restriction (and forcing traffic through rebound if it's running)
can get in the way.


It did. I thought for a while I was doing something stupid or had really 
screwed up the firewall's 'pf' configuration.


I have NSD listening on 8053.

With 'pass ... port 53 rdr-to (pppoe0) port 8053' in pf.conf, a telnet to 
port 53 failed. But doing 'pass ... port 8080 rdr-to (pppoe0) port 8053' 
in 'pf.conf' and telnet to port 8080, worked. So I was fairly sure my

'pf.conf' was not flawed.

But using 'dig -p8053', or any other ports that I used, was an invaluable 
aid in being able to prove conclusively that the ISP had messed up. Other 
testing was going to be hairy, and probably not conclusive.


Alternatively you could use the version of dig from packages which 
doesn't use pledge:


pkg_add isc-bind
/usr/local/bin/dig -p

However, because this one doesn't use pledge at all, bugs are a bigger risk.


I thought the whole idea of using NSD/UNBOUND is to avoid installing 
'isc_bind'.


I still cannot see what risk there is on qujerying a DNS on a non-standard 
port. Enlighten me please?


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

dig/nslookup limitations - can only do NSLOOKUPs using port 53

[Damian McGuckin]

With the advent of NSD which in normal operations would be configured to 
not even use port 53, and a dilemma (noted below), I had a need to try and 
query NSD directly on a port other than port 53.


I could not do such tests from an OpenBSD machine because in 6.0, the port 
command on 'nslookup' is disabled and the option 'p', -pPORT#, on 'dig' is 
tweaked to not change anything. See further below.


In my case, I was seeking proof that an ISP was blocking port 53 traffic. 
While I could 'rdr-to' any port I wanted in my efforts to help diagnose 
the problem and prove that the issue was the ISP and not my 'nsd' or 'pf' 
configuration, querying with a 6.0 OpenBSD 'dig' was fruitless.  Luckily I 
had a Linux machine which could query any port I wanted and I could then 
let 'pf' on the firewall map from any weird port number, say 12053, 10053, 
or even 8080 to the port on which NSD was listening. Any port except 53 
worked. I then knew that my configuration was not at fault. I had already 
proven that my 'pf' configuration was not blocking port 53 but I am a 
novice using 'nsd' and its idea of listening on a port other than 53 and 
having the local caching nameserver 'unbound' querying it on that port. 
Handling external machines which want to use 53 is easy, 'pf' redirect of 
external DNS traffic to that same NSD port. I eventually found an old 
OpenBSD box which has a version of dig which did allow '-pPORT#'.


It turns out that the ISP was blocking ports 53 (and 139 but nothing else) 
for some weird reason, even though the ISP said they were not blocking any 
ports. The ISP internal systems let the, block a a whole range of ports 
like 25, 53, 80, 8080, for non-business, i.e. 'residential', customers. 
But for a 'business' account, for which they charge a premium, they leave 
all ports open and let the user sort out protection or do whatever they

want. So my problem was solved.

Anyway, my question is, should we limit nslookup or dig to query solely on 
port 53. I notice that the difference between a old version of OpenBSD dig 
which allows the '-pPORT#', and that of '6.0' which does not, is just



#include 

151d151
< " -p port (specify port number)\n"
1194c1194,1197

Re: PC-Engines apu2c4 install reboot loop :(

[Damian McGuckin]

On Tue, 10 Jan 2017, Raf Czlonka wrote:


Anyway, the box is running live now so I cannot reboot for a while to get
the 'dmesg'. Sorry.


Try /var/run/dmesg.boot


You would think so. But:

No such file or directory

I am not getting senile - yet. That's next year's project.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: PC-Engines apu2c4 install reboot loop :(

[Damian McGuckin]

Not that I can help but I can confirm that problem.

On Tue, 10 Jan 2017, Steve Williams wrote:

The BIOS prompts work fine, I get the "boot>" prompt in OpenBSD, but right 
after the "entry point" line prints out, the system reboots.


Yes. I have seen this 3 times on a fit-PC4 Eco which is an AMD A4-1250 
1Ghz. It occurred on a very hot day in a room with no air-conditioning. It 
was OpenBSD 6.0 without patches. And then the problem went away for no 
apparent reason. I had not done any patches. Nor made the room any cooler. 
The A4-1250 has a GPU and in my case, the console was a screen attached to 
the HDMI with a USB keyboard (and no mouse).



It will do this endlessly.


Mine no. Thank goodness.

I would send the 'dmesg' boot messages but 'pf' keeps printing messages 
like


pf: state reuse TCP in wire
or
pf: state reuse TCP out wire

and it has filled up the /var/log/messages* so that dmesg no longer has 
any of the system boot configuration messages. I have to address that 
problem another day.


Anyway, the box is running live now so I cannot reboot for a while to get 
the 'dmesg'. Sorry.


- Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Hardware recommendations for compact 1U firewall

[Damian McGuckin]

To answer some of my own questions, and after wise guidance from the list, 
I have noticed that all our firewall hardware using 'vr' ethernet ports 
hit a wall somewhere between 65Mbps->69Mbps. This is the case with the 
Geodes in a net5501 and various VIA x86 CPUs in VIA embedded systems,


I am thinking of replacing the motherboard in my Net5501 system with one 
of the APU2 systems. If anybody has any experience with these, please feel 
free to share it. That will keep the price down but probably still about 
twice the level that I think Aaron is trying to achieve.


They use an AMD GX-412TC, 1Ghz quad Jaguar core and have 3*1Gbps ethernet 
(Intel i210AT) ports. The GX-412TC nominally is about 5 times faster than 
the Geode LX in the Net5501.


We need something better than the Soekris Net5501/Geode-LX on the end of 
an (Optus) cable internet link which we know runs at 110Mbps (raw) and on 
the end of two symmetric fibre links, both 100Mbps, one Optus and one 
Telstra. For non-Aussies, Optus and Telstra = ISPs. No, not NBN.


Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: isakmpd set up

[Damian McGuckin]

I apologise if it has already been said but we have heaps of clients with 
Office 365 where Microsoft do not control the DNS. The client does but you 
need special TXT records. Then again, none are charities with that special

$1/month/user deal.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Hardware recommendations for compact 1U firewall

[Damian McGuckin]

While everybody is talking about hardware, I noticed that some of you
have flicked your Soekris Net 5501 boards.

We are upgrading from 20Mbps links to 100Mbps links and as a result of 
this discussion, I am wondering whether it would be a wise move on or part 
to consider replacing them. Rock solid little units.


What is the max throughput people have seen on these?

Assuming traffic going between say 'vr0' and 'vr1', will it a Net5501
board sustain 100Mbps?

Thanks - Damian

Re: IPSEC from behind NAT stage 2 failure

[Damian McGuckin]

On Tue, 6 Dec 2016, Robert Szasz wrote:

I'll try it, but that would be a problem if I have to add the local 
address for any machine that wants to connect. I assume there is a way 
to work through NAT because picked up nat-t and works for phase 1. I was 
hoping I had just missed a parameter in the ipsec.conf to get phase 2 
working.


the NPPPD/IPSec combination does not need to know about the IP. Not 
knowing is the only way it can handle road-warrior types. The only issue 
as the far-more-knowledgeable-than-I Stuart Henderson pointed out is that 
you can have only one such Pre-Shared=-Key for all these unknown peers.


Sorry, busy with other things yesterday. I will try and find the time to 
go through your configurations later today.


Did you try to use 3des and modp1024 in your ipsec.conf because that is 
the only config some Windows clients will handle? Did you read this?


https://support.microsoft.com/en-us/kb/325158

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: IPSEC from behind NAT stage 2 failure

[Damian McGuckin]

Robert,

On Mon, 5 Dec 2016, Robert Szasz wrote:


I'm testing with the following setup

Win10 ->obsd5.9(firewall doing nat)->{}->obsd5.9(IPSEC)


Do you mean?

Win10 ->obsd5.9(firewall doing nat)->{INTERNET}->obsd5.9(IPSEC)

The connection process fails at stage 2 with the error message below 
where X is the public IP of the box being connected to, and Y is the ip 
of the firewall the win10 machine is behind 10...58 is the private ip of 
the win10 machine.


I can try to help but as you probably read a week or so ago, am a bit of a 
learner with L2TP myself.



error in the isakmpd log


010420.423317 Default responder_recv_HASH_SA_NONCE: peer proposed invalid 
phase 2 IDs: initiator id 10.1.1.58, responder id x.x.x.x
010420.423325 Default dropped message from y.y.y.y port 58544 due to 
notification type INVALID_ID_INFORMATION


ipsec.conf

ike passive esp transport \
 proto udp from x.x.x.x to any port 1701 \
 main auth hmac-sha1 enc "aes" group modp2048\
 quick auth hmac-sha1 enc "aes" group modp2048\
 psk ""


Why no pre-shared key?

Come versions of Windows 10 L2TP client, i.e. certain the one on my 
Windows 10 HOME box, only use 3DES, i.e. replace "aes" by "3des" above. 
Also, some only use modp1024 or maybe I am getting confused by those 
Apples.


I wouled also need to look at a copy of 'pf.conf' because that can be 
where the problem lies. That was where I made a mistake.


What about 'npppdf.conf'. Make sure that the sandbox network that it uses, 
or what some documentation called the VPN network, is different from the 
IPs of the 2 networks at each end of your link.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: IPSec

[Damian McGuckin]

Hi Stuart,

On Mon, 28 Nov 2016, Stuart Henderson wrote:


For completeness of description, for the latter I use

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MY-PRE-SHARED-SECRET"


"to any" in ipsec.conf creates a configuration for what isakmpd.conf(5)
describes as "the default ISAKMP peer". There can only be one such
section, so if you're using "default" in isakmpd.conf you have such a
conflict.


I figured it was something that.


The simplest fix, but not always possible, is to tie configs down by
IP address of the other side; if you can rely on normal lan-to-lan
tunnels to come only from specific addresses, just list them separately
and leave "default" for roaming clients.


Unfortunately we do not have static IPs in the remote offices. Some of 
these might be able to be converted to static IP but others, especially 
those out in the country, cannot easily be converted. So there is a demand 
for two types of connections to be "to any", the remote offices links 
which are a tunnel between 2 networks, and the road warriors with a Mac or 
Windows PC, or Ipad or the like. All a bit of a nightmare.



By doing things on the isakmpd.conf/policy side you can write an
isakmpd.policy section fairly easily that allows somebody to connect
with either of a choice of PSKs (it's similar to one of the examples in
the manpage). I think it may also be possible (though more complicated)
to write a section that allows the port 1701 UDP tunnel with one psk,
and other tunnels with a different psk.


I think I will just live with a single PSK for the 'roaming' sites/people.


Here's an *untested* rough equivalent to the ipsec.conf entry you
included, with the standard auto-generated suite/transforms rather than
the ones that ipsecctl generates (using 192.0.2.1 as the local address
in this case).


I might see how I using yours as a guide but translating directly the
raw output of 'ipsecctl -nv'.


Also it is important to note that ipsec.conf doesn't handle the
isakmpd.policy side of things.


I need to read up on the isakmpd.policy a bit more it seems.


While I am here, I still see on the passive IPSec Port 500 traffic

got AES_CBC, expected 3DES_CBC

on the IPSec/port500udp


That is "incoming packet was AES, but I expected it to be 3DES". Is this 
tunnel configured in default from the isakmpd.conf setup?


Yes. See below.

If so, it sounds like that section is being overridden by the ipsec.conf 
one.


Do not think so. The same happens even if there is no 'ipsec.conf' or 
'npppd'. I have seen it on older systems for years. Across VPN links

that work quite happily.

You also see this if config is cleared without reloading a new one and 
you get an incoming request for AES request, because the default 
"default peer" setting is for 3DES.


That is not my situation. It happens all the time on a system where nobody 
is touching 'isakmpd'. And the network is running nicely. It appears say 
every 3-4 minutes for 15 minutes, then not again for 2 hours and then for

a bit, and then not again for 30 minutes, and so on.

Looks like I will have to use the '-L' flag to the daemon. Does it need
any other options to get the maximum out of the '-L' dump.

My 'isakmpd.conf' : (slightly sanitized)
===

[General]
Listen-on=  Local-Machine-External-IP-to-the-World
Default-phase-1-lifetime=   86400,3600:86400
Default-phase-2-lifetime=   86400,3600:86400
DPD-check-interval= 10

[Phase 1]
default=ISAKMP-clients

[Phase 2]
Passive-connections=IPSec-clients

[ISAKMP-clients]
Phase=  1
Transport=  udp
Local-address=  Local-Machine-External-IP-to-the-World
Configuration=  Client-main-mode
Authentication= MY-PRE-SHARED-KEY-as-in-isakmpd-policy

[IPSec-clients]
Phase=  2
ISAKMP-peer=ISAKMP-clients
Configuration=  Client-quick-mode
Local-ID=   Net-My-Local-One
Remote-ID=  Net-Any_Remote

# My local network is 10.138.138.0/24 ( or could be and is something else )

[Net-My-Local-One]
ID-type=IPV4_ADDR_SUBNET
Network=			10.138.138.0 
Netmask=			255.255.255.0


[Net-Any_Remote]
ID-type=IPV4_ADDR
Address=0.0.0.0

[Default-main-mode]
DOI=IPSEC
EXCHANGE_TYPE=  ID_PROT
Transforms= AES-SHA-GRP2,3DES-SHA

[Default-quick-mode]
DOI=IPSEC
EXCHANGE_TYPE=  QUICK_MODE
Suites= QM-ESP-AES-SHA-PFS-SUITE

[Client-main-mode]
DOI=IPSEC
EXCHANGE_TYPE= 

Re: IPSec

[Damian McGuckin]

Hi Stuart,

On Mon, 28 Nov 2016, Stuart Henderson wrote:

ipsec.conf isn't required for this (or anything that you can do with 
ipsec.conf; though not all of it is documented in the isakmpd.conf 
manual, i.e. NAT-ID).


With the kind help of 'mxb' with a Swedish email address, I learned that. 
Mind you, it uses features of 'isakmpd.conf' that are well beyond my level 
of knowledge.



I would love to use both concurrently if I can?

Has anybody got any experience with both working well together?


That will be fine.


Yes. I have it working thanks to the list. But not quite as flexibly as I 
would like.


If I use a particular PSK across 'isakmpd.policy' and 'isakmpd.conf', and 
then try to use a different PSK for all inbound L2TP/IPSec connections, it 
fails. If they agree, it works. And I cannot remove the former (.policy) 
which I assume enforces an 'isakmpd'-wide PSK and try and use different 
ones in the different files, iaakmpd.conf and ipsec.conf i.e. what I use 
for IPSec over UDP500 and L2TP/IPSec over 1701 respectively.


For completeness of description, for the latter I use

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MY-PRE-SHARED-SECRET"

The above is what I found works for both Windows 10 (which has '3des' 
hardcoded) and Apple. Why I need the 'group modp1024' for quick-mode I do 
not know. I must figure out how to obtain a more flexible Windows VPN 
client. Microsoft says that only the earlier versions of its L2TP client 
are so inflexible.


https://support.microsoft.com/en-us/kb/325158

But even my laptop's version for an up-to-date Windows 10 Home does not 
give me any choice for encryption from what I can see. Although I am far 
from an expert on Windows 10, in anything and I have used OpenBSD for 20

years.

Though if you have an example ipsec.conf fragment, feed it into 
"ipsecctl -nv" and it shows the isakmpd fifo commands that it would send 
to add the config sections,


I noticed. I learned more about the complexity of ISAKMPD commands in that 
split second of viewing output than I ever really needed to know. Wow. I 
awe of those that create such networking tools.


which you could clean up and add to isakmpd.conf yourself if you wanted 
to keep things in one place.


That sounds frought with risk. Not a big fan of jumping into the unknown.

And the future is 'ipsec.conf' so I probably need to learn that. Mind you, 
one I cannot see is how to nominate a list of CRYPTO TRANSFORMS to the 
'enc' keyword inside 'ipsec'. For example how does one achieve the 
equivalent in 'isakmpd.conf' to the alternatives


Transforms=  AES-SHA-GRP2,3DES-SHA

or even

Suites=  QM-ESP-AES-SHA-PFS-GRP2-SUITE, QM-ESP-3DES-SHA-PFS-SUITE

While I am here, I still see on the passive IPSec Port 500 traffic

got AES_CBC, expected 3DES_CBC

on the IPSec/port500udp even when the originating side (A Billion Router 
running some version of embedded Linux) is configured to talk AES and only 
AES. Very weird. But I notice that in the past, even old versions of 
ISAKMPD (4.6 and 4.7) with both ends the same produced that message it 
seems. I am clueless as to the cause of that.


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

IPSec

[Damian McGuckin]

Can you mix the use of 'isakmpd.conf' and 'ipsec.conf'?

I currently use the former for port 500 stuff. We use both predefined 
network-to-networks IPSec links with PreShared Secrets and also dynamic, 
i.e. negotiated, network-to-network links. The thought of figuring out how 
to do both with IPSec, especially the latter which does not seem to be 
documented with examples, fills me with dread.


I have just figured out to allow L2TP/IPSec connections which demands the 
use of the latter.


I would love to use both concurrently if I can?

Has anybody got any experience with both working well together?

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Sendmail on OpenBSD 6.0

[Damian McGuckin]

Is anybody using this configuration, i.e. not OpenSMTPD?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer