Re: adding ipv6 and pppoe to my firewall

2019-07-19 Thread shadrock uhuru
Hi Stuart
thanks for the reply

On 7/12/19 1:20 PM, owner-m...@openbsd.org wrote:
>> hypothetical ipv4 Address and ipv6 prefix from zen:
>> ND Prefix: :::::/64
>> PD Prefix: ::::/48
>> IPv4 Address:     12.34.56.78 (Subnet mask 255.255.255.255)
---
>>     fw1 em0: 192.168.2.2 (lan)
>>     fw1 em1: 12.34.56.78 (wan)
i have taken carp out of the configuration which leaves me with:

/etc/hostname.em0
mtu 1508
inet 192.168.2.2 255.255.255.0 NONE

/etc/hostname.em1
mtu 1508
inet 12.34.56.78 255.255.255.255 NONE
inet6 autoconf -autoconfprivacy -soii

/etc/hostname.pppoe
mtu 1500
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap
authname "XXX@isp" authkey "XXX" up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 -priority 8

/etc/rad.conf
interface em0

dhcpcd to be added

> If you need DHCPv6-PD then don't hardcode the addresses on the
> inside interfaces, just let PD fetch them.(For the UK ISPs I'm most familiar 
> with, zen seems to need PD otherwise
> they don't route the block to me, at least in the config they've got
> on my user account
by inside interfaces do you mean the lan facing nic on the firewall and
any tun interfaces ?
i am on zen also and will have a look at dhcpcd
> question 5
>>> do i need to put -autoconfprivacy -soii  in the nics or should i remove it.
> Don't use autoconf on interfaces where you run rad(8), that is like
> running dhclient and dhcpd on the same interface.
>
so remove autoconf from em0 ?

should i be using the mtu option in rad.conf to ensure that all nodes on
a link use the same MTU value i.e. 1508 ?

could you send examples of the following files to compare with mine for
any misconfigurations on my side please.
wan hostname file
lan hostname file
pppoe hostname file
rad.conf
dhcpcd.conf

thanks
shadrock


Re: Support Update

2019-07-19 Thread Ingo Schwarze
Hi,

Kihaguru Gathura wrote on Fri, Jul 19, 2019 at 10:50:22PM +0300:

> 0
> C Kenya
> P
> T Nairobi
> Z P.O. Box 30164-00100
> O Data Store Kenya
> I   Kihaguru Njenga Gathura
> A Bishops Road
> M i...@pqscript.com
> U
> B +254 7 0697 0697
> X
> N OpenBSD consulting. Speciality in web applications
> development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI
> protocol and C programming language.

Committed.

Thank you for keeping your data up to date!

Yours,
  Ingo



IPsec redirect to internal LAN

2019-07-19 Thread Lévai , Dániel
Hi all!

I've been trying to figure out how to direct traffic into internal hosts 
through IPsec (IKEv2, enc0).
My client is an Android phone, using strongSwan, connecting to an OpenBSD 6.5 
VPN concentrator.
The VPN server has two IP addresses on enc0, 172.16.0.1/24 and 172.16.0.21/24. 
I wanted to use the latter as a 1:1 map to an internal IP address, like 
192.168.0.21. Basically everything I would send to 172.16.0.21 to any port from 
the client/phone, I would want to direct that to 192.168.0.21 to the same dst 
port.

[client/phone] (172.16.0.42/24) <-> (172.16.0.1/24, 172.16.0.21/24) [OpenBSD 
VPN server] (192.168.0.1/16) <-> (192.168.0.21/16) [internal host]

I wanted to test this with icmp first, and build up from there:

# ifconfig enc0
enc0: flags=41
index 5 priority 0 llprio 3
groups: enc
status: active
inet 172.16.0.1 netmask 0xff00
inet 172.16.0.21 netmask 0xff00

/etc/pf.conf:
==8<==
match all scrub (no-df random-id)# I tried to remove this, but didn't seem 
to make any difference
[...]
pass in on egress proto udp to port {isakmp, ipsec-nat-t} label IKE
pass in on egress proto esp label IKE

match in on enc inet proto icmp from (enc:network) to 172.16.0.21 \
rdr-to 192.168.0.21 \
tag IPSEC_RDR_PASS

pass on enc tagged IPSEC_RDR_PASS
==8<==

>From the client/phone I can ping 172.16.0.1, naturally, but when it comes to 
>172.16.0.21, on the enc0 interface there's this traffic, which seems fine to 
>me:
VPN server# tcpdump -nttti enc0
tcpdump: listening on enc0, link-type ENC
Jul 19 22:27:11.842500 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 > 
172.16.0.21: icmp: echo request (DF) (encap)
Jul 19 22:27:12.861873 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 > 
172.16.0.21: icmp: echo request (DF) (encap)
Jul 19 22:27:13.921964 (authentic,confidential): SPI 0x9b57d4b8: 172.16.0.42 > 
172.16.0.21: icmp: echo request (DF) (encap)

So it seems the redirect works, meanwhile on the 192.168.0.21 host:
internal host$ sudo tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2019-07-19 22:28:40.243669 IP 172.16.0.42 > 192.168.0.21: ICMP echo request, id 
18, seq 1021, length 64
2019-07-19 22:28:40.243705 IP 192.168.0.21 > 172.16.0.42: ICMP echo reply, id 
18, seq 1021, length 64
2019-07-19 22:28:40.243974 IP 192.168.0.1 > 192.168.0.21: ICMP 172.16.0.42 
unreachable - need to frag, length 36
2019-07-19 22:28:41.283963 IP 172.16.0.42 > 192.168.0.21: ICMP echo request, id 
18, seq 1022, length 64
2019-07-19 22:28:41.283999 IP 192.168.0.21 > 172.16.0.42: ICMP echo reply, id 
18, seq 1022, length 64
2019-07-19 22:28:41.284335 IP 192.168.0.1 > 192.168.0.21: ICMP 172.16.0.42 
unreachable - need to frag, length 36

So icmp gets into the internal network, it just couldn't find its way back.

>From 192.168.0.21 I can ping 172.16.0.{1, 21} fine (both IP addresses on enc0 
>on the VPN server), but when it comes to .42 (the above IPsec client, the 
>phone), if I try to ping it, I get the same error:
internal host$ ping 172.16.0.42
PING 172.16.0.42 (172.16.0.42) 56(84) bytes of data.
>From 192.168.0.1 icmp_seq=1 Frag needed and DF set (mtu = 0)
>From 192.168.0.1 icmp_seq=2 Frag needed and DF set (mtu = 0)


Is there something fundamentally wrong with this? How would this work ideally?
I even tried to setup a NAT rule when coming in from the VPN to the LAN, so 
everything from 172.16.0/24 would be NATed to 192.168.0.1, the VPN server's 
internal IP:
match out on enc from (enc:network) to (em0:network) \
nat-to 192.168.0.1

Now this didn't do anything, at least from the above tcpdumps' point of view :-\


Thanks for any hints!

Dani


publickey - leva@ecentrum.hu - 0x66E1F716.asc
Description: application/pgp-keys


Support Update

2019-07-19 Thread Kihaguru Gathura
0
C Kenya
P
T Nairobi
Z P.O. Box 30164-00100
O Data Store Kenya
I   Kihaguru Njenga Gathura
A Bishops Road
M i...@pqscript.com
U
B +254 7 0697 0697
X
N OpenBSD consulting. Speciality in web applications
development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI
protocol and C programming language.



Re: UEFI Issue

2019-07-19 Thread Charlie Burnett
Yeahhh... I've just decided to return it and get a X1 6th gen and just get
a supported wacom usb drawing tablet for notes, no OpenBSD is kind of a
dealbreaker for me. Also keyboard on it was screwy and didn't work half the
time even with Windows so not the best machine. And Legacy mode was also a
no-go, as there was no legacy mode and any and all CSM support had been
disabled, which is rather frustrating. Also, tried booting through rEFInd,
grub, took the hard drive out and installed it on a different machine, none
worked sadly. Oddly enough, certain Linux distros seemed to have a similar
issue (namely the most recent Gentoo minimal iso) so I'm guessing there was
something really weird with the EFI on it. I've got a few old/cheap
machines with issues along the same lines, I'll try to figure out what the
issue was if I can. I appreciate all y'all's help though!

On Fri, Jul 19, 2019 at 8:14 AM Kristjan Komloši 
wrote:

> On Tue, 2019-07-16 at 18:32 +, Charlie Burnett wrote:
> > Hey, I'm looking to get OpenBSD working in UEFI only mode on newer
> > Thinkpad
> > X1 devices, because for whatever reason it hangs when loading into
> > memory
> > without CSM enabled, and some of the X1 devices no longer have a CSM
> > option. Does anyone have a fix, or advice on where I would start
> > looking if
> > I was going to patch it myself?
> New Lenovo laptops are getting kinda infamous for their comically bad
> UEFI implementations. They hardly boot anything but Windows. You may be
> on a blind path there.
>
> Try disabling secure boot if you haven't done so already, and try
> chainloading OpenBSD through a boot manager like rEFInd (I've been
> booting OpenBSD with it for a long time, albeit with CSM support).
>
> --
> Kristjan Komloši
> Mail: kristjan.koml...@gmail.com
> Tel:  +386 31 679 339
>
>


Re: adding ipv6 and pppoe to my firewall

2019-07-19 Thread shadrock uhuru
Hi Stuart
thanks for the reply

On 7/12/19 1:20 PM, misc@openbsd.org wrote:
>> hypothetical ipv4 Address and ipv6 prefix from zen:
>> ND Prefix: :::::/64
>> PD Prefix: ::::/48
>> IPv4 Address: ?? 12.34.56.78 (Subnet mask 255.255.255.255)
---
>> ?? fw1 em0: 192.168.2.2 (lan)
>> ?? fw1 em1: 12.34.56.78 (wan)
i have taken carp out of the configuration which leaves me with:

/etc/hostname.em0
mtu 1508
inet 192.168.2.2 255.255.255.0 NONE

/etc/hostname.em1
mtu 1508
inet 12.34.56.78 255.255.255.255 NONE
inet6 autoconf -autoconfprivacy -soii

/etc/hostname.pppoe
mtu 1500
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap
authname "XXX@isp" authkey "XXX" up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 -priority 8

/etc/rad.conf
interface em0

dhcpcd to be added

> If you need DHCPv6-PD then don't hardcode the addresses on the
> inside interfaces, just let PD fetch them.(For the UK ISPs I'm most familiar 
> with, zen seems to need PD otherwise
> they don't route the block to me, at least in the config they've got
> on my user account
by inside interfaces do you mean the lan facing nic on the firewall and
any tun interfaces ?
i am on zen also and will have a look at dhcpcd
> question 5
>>> do i need to put -autoconfprivacy -soii?? in the nics or should i remove it.
> Don't use autoconf on interfaces where you run rad(8), that is like
> running dhclient and dhcpd on the same interface.
>
so remove autoconf from em0 ?

should i be using the mtu option in rad.conf to ensure that all nodes on
a link use the same MTU value i.e. 1508 ?

could you send examples of the following files to compare with mine for
any misconfigurations on my side please.
wan hostname file
lan hostname file
pppoe hostname file
rad.conf
dhcpcd.conf

thanks
shadrock



Re: UEFI Issue

2019-07-19 Thread Stuart Longland
On 19/7/19 8:19 pm, Otto Moerbeek wrote:
> On Fri, Jul 19, 2019 at 08:13:09PM +1000, Stuart Longland wrote:
> 
>> On 19/7/19 6:21 pm, Otto Moerbeek wrote:
>>> Or save yourself the trouble and go for legacy mode.
>>>
>>> -Otto
>>>
>>
>> … except if legacy mode is broken on the machine in question, in which
>> case you're stuffed.
> 
> I' not guessing. Legacy mode works fine on the X1 6th gen. I'm telling
> this from experience (I use one).

Fair enough. :-)  I dare say the problem will bite us in the near future
though as more manufacturers question the need for the CSM in boot firmware.

(That said, part of me misses the BIOS… the B stood for *BASIC*,
something UEFI most definitely is not!)
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



Re: UEFI Issue

2019-07-19 Thread Otto Moerbeek
On Fri, Jul 19, 2019 at 08:13:09PM +1000, Stuart Longland wrote:

> On 19/7/19 6:21 pm, Otto Moerbeek wrote:
> > Or save yourself the trouble and go for legacy mode.
> > 
> > -Otto
> > 
> 
> … except if legacy mode is broken on the machine in question, in which
> case you're stuffed.

I' not guessing. Legacy mode works fine on the X1 6th gen. I'm telling
this from experience (I use one).

-Otto

> 
> I had a baptism of fire with a UEFI-only motherboard (Supermicro
> A2SDi-16C-HLN4F) earlier this week.
> 
> I had an existing install of Gentoo Linux that I wanted to run on it,
> but it was partitioned and set up for a BIOS-based boot set-up, not
> UEFI.  I ended up PXE-booting Ubuntu (for which there was a
> UEFI-compatible PXE image), doing a back-up to a USB drive, installing
> Ubuntu, then having gotten the machine booting, imaging Gentoo back across.
> 
> Pretty sure it refused to look at a CD with El Torito boot sectors on it
> (so there goes install65.iso and cd65.iso), and it flatly refused to
> load pxelinux.0 as shipped by Ubuntu/Debian.
> 
> Not sure if OpenBSD's boot-loader is UEFI-compatible, but if not, you'll
> strike the very same issues.
> -- 
> Stuart Longland (aka Redhatter, VK4MSL)
> 
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
> 



Re: UEFI Issue

2019-07-19 Thread Stuart Longland
On 19/7/19 6:21 pm, Otto Moerbeek wrote:
> Or save yourself the trouble and go for legacy mode.
> 
>   -Otto
> 

… except if legacy mode is broken on the machine in question, in which
case you're stuffed.

I had a baptism of fire with a UEFI-only motherboard (Supermicro
A2SDi-16C-HLN4F) earlier this week.

I had an existing install of Gentoo Linux that I wanted to run on it,
but it was partitioned and set up for a BIOS-based boot set-up, not
UEFI.  I ended up PXE-booting Ubuntu (for which there was a
UEFI-compatible PXE image), doing a back-up to a USB drive, installing
Ubuntu, then having gotten the machine booting, imaging Gentoo back across.

Pretty sure it refused to look at a CD with El Torito boot sectors on it
(so there goes install65.iso and cd65.iso), and it flatly refused to
load pxelinux.0 as shipped by Ubuntu/Debian.

Not sure if OpenBSD's boot-loader is UEFI-compatible, but if not, you'll
strike the very same issues.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



Re: UEFI Issue

2019-07-19 Thread Otto Moerbeek
On Fri, Jul 19, 2019 at 10:14:41AM +0200, Kristjan Komloši wrote:

> On Tue, 2019-07-16 at 18:32 +, Charlie Burnett wrote:
> > Hey, I'm looking to get OpenBSD working in UEFI only mode on newer
> > Thinkpad
> > X1 devices, because for whatever reason it hangs when loading into
> > memory
> > without CSM enabled, and some of the X1 devices no longer have a CSM
> > option. Does anyone have a fix, or advice on where I would start
> > looking if
> > I was going to patch it myself?
> New Lenovo laptops are getting kinda infamous for their comically bad
> UEFI implementations. They hardly boot anything but Windows. You may be
> on a blind path there.
> 
> Try disabling secure boot if you haven't done so already, and try
> chainloading OpenBSD through a boot manager like rEFInd (I've been
> booting OpenBSD with it for a long time, albeit with CSM support).
> 
> -- 
> Kristjan Komloši
> Mail: kristjan.koml...@gmail.com
> Tel:  +386 31 679 339
> 

Or save yourself the trouble and go for legacy mode.

-Otto



Re: UEFI Issue

2019-07-19 Thread Kristjan Komloši
On Tue, 2019-07-16 at 18:32 +, Charlie Burnett wrote:
> Hey, I'm looking to get OpenBSD working in UEFI only mode on newer
> Thinkpad
> X1 devices, because for whatever reason it hangs when loading into
> memory
> without CSM enabled, and some of the X1 devices no longer have a CSM
> option. Does anyone have a fix, or advice on where I would start
> looking if
> I was going to patch it myself?
New Lenovo laptops are getting kinda infamous for their comically bad
UEFI implementations. They hardly boot anything but Windows. You may be
on a blind path there.

Try disabling secure boot if you haven't done so already, and try
chainloading OpenBSD through a boot manager like rEFInd (I've been
booting OpenBSD with it for a long time, albeit with CSM support).

-- 
Kristjan Komloši
Mail: kristjan.koml...@gmail.com
Tel:  +386 31 679 339



Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-19 Thread NilsOla Nilsson
On Sat, Jul 13, 2019 at 03:47:53PM +0200, Ingo Schwarze wrote:
> Hi NilsOla,
> 
>  On 2019-07-11, Ingo Schwarze  wrote:
> 
> >>> I just did
> >>>   cd /usr/xenocara/app/xterm/
> >>>   cvs up -dP
> >>>   make clean
> >>>   make obj
> >>>   make
> >>>   doas make install
> >>> and now compose works again for me in xterm, too.
> >>> 
> >>> I have no idea what was going on.  I often have patches lying around
> >>> in my tree for diverse testing purposes, though i fail to remeber
> >>> anything in particular in xterm(1) lately, and there are no patches
> >>> there now.  Anyway, sorry for the noise.
> >>> 
> >>> To the other poster who reported problems with compose in xterm:
> >>> Can you try updating and recompiling xterm as shown above,
> >>> and does that help for you, too?
> 
> >> It works for mee too. 
> >> So, the xterm distributed in current is not the same
> >> as in the source tree? Just asking.
> 
> I don't know.  It sounds as if this aspect of xterm(1) was briefly
> broken in at least one snapshot about three weeks ago.  But i don't
> know why, i see no plausible reason.  Nothing was committed to xterm
> for four months, and i don't recall hearing about uncommitted xterm
> patches in snapshots either.
> 
> > It works also for one xterm that was started before the
> > reinstall.
> 
> Now that's very weird.  It doesn't for me.  I still have some old
> xterm binaries running, and compose still doesn't work in those,
> in the way i described, while it does work in xterms that i start
> now using the freshly recompiled /usr/X11R6/bin/xterm.

Of the xterms started before the reinstall it works
only for the one were i run the reinstallation. 

BTW I have one other machine with openbsd 6.5 stable, and
there it seems to work from the beginning

Yours 
NilsOla

-- 
Nils Ola Nilsson, 🐞 email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature