Discussion:
pf ipv6 source-routing 6.9
Bastien Durel
2021-05-07 16:00:36 UTC
Permalink
Hello,

I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.

I used to route outgoing streams with :

net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router

And incoming with :

pass in on $net2_if inet6 reply-to $ovh_v6_router keep state

I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0 to let pf
load its configuration file, but this does not seems to work:

Here are incoming packets :

fremen# tcpdump -nvv -i pppoe0 host 2001:41d0:8:91a::1
tcpdump: listening on pppoe0, link-type PPP_ETHER
17:50:30.401270 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: icmp6: echo request (id:3a19 seq:100) [icmp6 cksum ok] (len 64, hlim 55)
17:50:31.409201 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: icmp6: echo request (id:3a19 seq:101) [icmp6 cksum ok] (len 64, hlim 55)

Here are outgoing ones :

fremen# tcpdump -nvv -i wg2 host 2001:41d0:8:91a::1
tcpdump: listening on wg2, link-type LOOP
17:51:14.753505 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: icmp6: echo reply (id:3a19 seq:144) [icmp6 cksum ok] [flowlabel 0xe86a] (len 64, hlim 63)
17:51:15.761535 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: icmp6: echo reply (id:3a19 seq:145) [icmp6 cksum ok] [flowlabel 0xe86a] (len 64, hlim 63)

There is a route for 2001:41d0::/32 on wg2, that's why it takes it, but
the route-to should have forced it to exit via pppoe0, isn't it ? (wg2
is in $tun_ifs)

What's the correct syntax to make route-to works with LL addresses ?

BTW, if there's a better way of handling this source-routing problem,
I'm open to suggestions

Regards,
--
Bastien
Stuart Henderson
2021-05-07 20:50:44 UTC
Permalink
Post by Bastien Durel
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
Bastien Durel
2021-05-08 07:01:46 UTC
Permalink
Post by Stuart Henderson
Post by Bastien Durel
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
Post by Stuart Henderson
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
--
Bastien Durel
Stuart Henderson
2021-05-08 08:58:34 UTC
Permalink
Post by Bastien Durel
Post by Stuart Henderson
Post by Bastien Durel
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
Post by Stuart Henderson
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
Bastien Durel
2021-05-08 09:35:03 UTC
Permalink
Post by Stuart Henderson
Post by Bastien Durel
Post by Stuart Henderson
Post by Bastien Durel
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
Post by Stuart Henderson
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried

pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state

none of these worked
--
Bastien Durel
Stuart Henderson
2021-05-08 09:56:08 UTC
Permalink
Post by Bastien Durel
Post by Stuart Henderson
Post by Bastien Durel
Post by Stuart Henderson
Post by Bastien Durel
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table <internal6> const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to !<internal6> route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
Post by Stuart Henderson
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
Those aren't exactly expected to work (I don't think pf really
handles link locals)...
Post by Bastien Durel
pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state
...but I was hoping that this would (and it might possibly be a bug
that it doesn't).
Post by Bastien Durel
none of these worked
Bastien Durel
2021-05-08 10:07:01 UTC
Permalink
Post by Stuart Henderson
Post by Bastien Durel
Post by Stuart Henderson
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
Those aren't exactly expected to work (I don't think pf really
handles link locals)...
that was my initial question, as the previous versions handled them
correctly with "(ifname LLaddr)"
Post by Stuart Henderson
Post by Bastien Durel
pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state
...but I was hoping that this would (and it might possibly be a bug
that it doesn't).
It works with IPv4, but I don't think is handled the same way IPv4 is on
this kind of links.

my hostname.pppoe0 has :

dest 0.0.0.1
inet6 eui64
!/usr/local/sbin/dhcp6c pppoe0
Post by Stuart Henderson
Post by Bastien Durel
none of these worked
If pf cannot handle LL anymore, I guess I'll have to downgrade to 6.8 :(
--
Bastien Durel
Bastien Durel
2021-05-10 10:05:16 UTC
Permalink
Post by Bastien Durel
Post by Stuart Henderson
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
Hello,

Thanks to folks of #openbsd, I found out adding an explicit route to
fe80::520f:80ff:fe65:8800 on pppoe0 make this work.
Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
rule referencing fe80::520f:80ff:fe65:8800

pf.conf:
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
pfctl -s rules:
pass in on pppoe0 inet6 all flags S/SA reply-to fe80::520f:80ff:fe65:8800

hostname.pppoe0:
!/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0

This make pf able to route to the correct interface.

Regards,
--
Bastien
Stefan Sperling
2021-05-10 10:53:12 UTC
Permalink
Post by Bastien Durel
Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
rule referencing fe80::520f:80ff:fe65:8800
I'm not sure where the scope id gets stripped, but the above may simply
be a misleading cosmetic issue.

pfctl -sr uses inet_ntop() to convert the address into printable format.
It looks like this would never print the scope id (the %pppoe0 part of
the address).

The 'route get' command uses getnameinfo() instead, and getnameinfo()
has special handling for the scope_id which inet_ntop() lacks.

Someone would need to debug this to see if the scope id is present in
the binary representation of the rule's address, or if the scope id was
dropped somewhere on the way from pf.conf to the output of pfctl -sr.
Post by Bastien Durel
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
Rergardless, I would expect the above rule to work without an extra
entry in the routing table. Out of the box 'route get' displays the
correct route. Try: route get fe80::520f:80ff:fe65:8800%pppoe0
On my system this correctly identifies the outgoing interface as pppoe0.
Post by Bastien Durel
!/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0
This make pf able to route to the correct interface.
In my opinion having to add an extra route for this is a bug.
But I have no idea where :)
David Gwynne
2021-05-10 12:51:26 UTC
Permalink
Post by Bastien Durel
Post by Bastien Durel
Post by Stuart Henderson
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
Hello,
Thanks to folks of #openbsd, I found out adding an explicit route to
fe80::520f:80ff:fe65:8800 on pppoe0 make this work.
Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
rule referencing fe80::520f:80ff:fe65:8800
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
pass in on pppoe0 inet6 all flags S/SA reply-to fe80::520f:80ff:fe65:8800
!/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0
This make pf able to route to the correct interface.
You're right, pf isn't very good at handling link-local v6 addresses. This is annoying now that route-to uses addresses as it's argument if you want to move ipv6 packets toward a host with a link local address.

In this situation the least worst way to cope with the problem for now is to use route-to (pppoe0:0). This should work because route-to doesn't do any local address checks on the destination address it resolves. Once it looks up the local address as the direction to send the packet, it should put it straight out pppoe0. ppp as a tunnel interface has no address resolution protocol, it just encapsulates the packet it is given and sends it on its way.

route-to also takes a destination address as an argument, not a gateway address. If dhcp6c sets up a route to some global address that you know about (I'm not sure this is a thing but it might be), you can use that global address as the argument to route-to and it will send it in the right direction.

dlg
Post by Bastien Durel
Regards,
--
Bastien
Bastien Durel
2021-05-10 13:45:24 UTC
Permalink
Post by David Gwynne
Post by Bastien Durel
Post by Bastien Durel
Post by Stuart Henderson
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to
fe80::520f:80ff:fe65:8800%pppoe0
keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800
keep
state
Hello,
Thanks to folks of #openbsd, I found out adding an explicit route to
fe80::520f:80ff:fe65:8800 on pppoe0 make this work.
Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
rule referencing fe80::520f:80ff:fe65:8800
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
pass in on pppoe0 inet6 all flags S/SA reply-to
fe80::520f:80ff:fe65:8800
!/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0
This make pf able to route to the correct interface.
You're right, pf isn't very good at handling link-local v6 addresses.
This is annoying now that route-to uses addresses as it's argument if
you want to move ipv6 packets toward a host with a link local
address.
In this situation the least worst way to cope with the problem for
now is to use route-to (pppoe0:0). This should work because route-to
doesn't do any local address checks on the destination address it
resolves. Once it looks up the local address as the direction to send
the packet, it should put it straight out pppoe0. ppp as a tunnel
interface has no address resolution protocol, it just encapsulates
the packet it is given and sends it on its way.
route-to also takes a destination address as an argument, not a
gateway address. If dhcp6c sets up a route to some global address
that you know about (I'm not sure this is a thing but it might be),
you can use that global address as the argument to route-to and it
will send it in the right direction.
Hello.

Thanks for the hint, but (pppoe0:0) does not work :

pf.conf:266: route spec requires :peer with dynamic interface addresses

(pppoe0:peer) make pf happy, but does not route anything (ifconfig does
not show any peer on inet6)

dhcp6c does not sets any route by its own, it only returns some DNS
resolver addresses, and registers the prefixes the ISP delegates.

Regards,
--
Bastien
p***@pascallen.nl
2021-05-08 16:53:54 UTC
Permalink
Dear all,

What would be the best way to install HASS on Openbsd?
Containers are a nogo?

Run it in virtual env from python?

Any Howto on the subject with Openbsd?


Currently I got it running as from the website with the "core" version.
But a startup script which runs with a non-root user is where I get
stuck.
--
Met vriendelijke groet,

Pascal Huisman


Fundamentally, there may be no basis for anything.
Todd
2021-05-08 19:16:44 UTC
Permalink
There is some guidance for installing Home Assistant on FreeBSD.
Probably the most useful piece of the article is the init script that
starts Home Assistant from a virtual env. I bet with minor tweaks, you
could get this to work on OpenBSD.

https://community.home-assistant.io/t/installation-of-home-assistant-on-your-freenas/195158
Post by p***@pascallen.nl
Dear all,
What would be the best way to install HASS on Openbsd?
Containers are a nogo?
Run it in virtual env from python?
Any Howto on the subject with Openbsd?
Currently I got it running as from the website with the "core" version.
But a startup script which runs with a non-root user is where I get
stuck.
--
Met vriendelijke groet,
Pascal Huisman
Fundamentally, there may be no basis for anything.
David Gwynne
2021-05-10 09:31:50 UTC
Permalink
ive been running hass on openbsd for a while now, and just did a new
install on 6.9 for my boss on the weekend.

i set up a _hass user for it to run as, and gave it /opt/hass:

hass$ getent passwd _hass
_hass:*:2000:2000:Home Assistant:/opt/hass:/sbin/nologin
hass$ getent group 2000
_hass:*:2000
hass$ ls -ld /opt/hass
drwxr-xr-x 8 _hass _hass 512 May 8 22:35 /opt/hass

i installed mosquitto, python3.8, py3-virtualenv, py3-pip,
py3-cryptography, py3-Pillow, and py3-zeroconf from ports. then
as the _hass users i set up a venv in /opt/hass with virtualenv
--system-site-packages /opt/hass, did the . /opt/hass/bin/activate
thing, then ran pip install homeassistant.

that got me far enough stuff to be able to start home assistant. you're
on your own after this.

good luck.

dlg
Post by p***@pascallen.nl
Dear all,
What would be the best way to install HASS on Openbsd?
Containers are a nogo?
Run it in virtual env from python?
Any Howto on the subject with Openbsd?
Currently I got it running as from the website with the "core" version.
But a startup script which runs with a non-root user is where I get
stuck.
--
Met vriendelijke groet,
Pascal Huisman
Fundamentally, there may be no basis for anything.
p***@pascallen.nl
2021-05-10 19:01:46 UTC
Permalink
Dear David,

How do you start homeassistant after a reboot? Manually?

-----Oorspronkelijk bericht-----
Van: David Gwynne <***@gwynne.id.au>
Aan: ***@pascallen.nl <***@pascallen.nl>
Cc: ***@openbsd.org
Onderwerp: Re: Home Assistant
Datum: Mon, 10 May 2021 19:31:50 +1000
E-mailprogramma: Mutt/1.12.2 (2019-09-21)

ive been running hass on openbsd for a while now, and just did a
newinstall on 6.9 for my boss on the weekend.
i set up a _hass user for it to run as, and gave it /opt/hass:
hass$ getent passwd _hass_hass:*:2000:2000:Home
Assistant:/opt/hass:/sbin/nologinhass$ getent group
2000_hass:*:2000hass$ ls -ld /opt/hassdrwxr-xr-x 8 _hass _hass 512
May 8 22:35 /opt/hass
i installed mosquitto, python3.8, py3-virtualenv, py3-pip,py3-
cryptography, py3-Pillow, and py3-zeroconf from ports. thenas the _hass
users i set up a venv in /opt/hass with virtualenv--system-site-
packages /opt/hass, did the . /opt/hass/bin/activatething, then ran pip
install homeassistant.
that got me far enough stuff to be able to start home assistant.
you'reon your own after this.
good luck.
dlg
Post by p***@pascallen.nl
Dear all,
What would be the best way to install HASS on Openbsd?Containers are
a nogo?
Run it in virtual env from python?
Any Howto on the subject with Openbsd?
Currently I got it running as from the website with the "core"
version.But a startup script which runs with a non-root user is where
I getstuck.
-- Met vriendelijke groet,
Pascal Huisman
Fundamentally, there may be no basis for anything.
--
Met vriendelijke groet,

Pascal Huisman


Elbonics, n.:
The actions of two people maneuvering for one armrest in a movie
theatre.
-- "Sniglets", Rich Hall & Friends
David Gwynne
2021-05-11 06:44:10 UTC
Permalink
Post by p***@pascallen.nl
Dear David,
How do you start homeassistant after a reboot? Manually?
i have these scripts. the pexp in the rc script doesnt work, but i havent needed it to yet.

apathy$ cat /etc/rc.d/hass
#!/bin/ksh

daemon="/opt/local/sbin/hass --daemon"
daemon_user="_hass"

pexp="/opt/hass/bin/hass"

. /etc/rc.d/rc.subr

rc_reload=NO

rc_cmd $1
apathy$ cat /opt/local/sbin/hass
#!/bin/ksh

. /opt/hass/bin/activate

/opt/hass/bin/hass "$@"

Loading...