Re: installing openbsd on raspberry pi 4

[Benjamin Ludwig]

Hello,

I'm not Sure but shouldn't it be 
cd: /mnt/usr/share/zoneinfo 
instead of:
cd: /mnt/user/share/zoneinfo
?

regards 

Am 13. September 2021 15:48:02 MESZ schrieb Sandeep Gupta 
:
>Hello,
>
> I am stuck on installing openbsd 6.8 (or 6.9) on rpi 4. I am able to
>boot the openbsd installer off  of USB
> drive using  UEFI boot loader (on sd card). However the installer
>fails at the step "What timezone are you in?".
> It doesn't like any timezone I input. Just before this step I get the
>error "cd: /mnt/user/share/zoneinfo -- No such file or directory".
> I am not able to tell installer to skip this step.
>
>Another issue I am facing is that installer giving warning:
>"Are you *SURE* your install is complete without bsd" and other
>similar warnings.
>where should I place bsd, bsd.mp, and other files for installer to
>pick those up. On the usb drive I have only
>written miniroot68.img. This creates two partitions. None of these
>partitions seems like there correct place
>for bsd and other distribution sets files. Any pointers/help would be great.
>
>Thanks
>-S
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: ipsec with default route and routing of internal networks

[Stuart Henderson]

On 2021-09-13, Hrvoje Popovski  wrote:
> On 13.9.2021. 14:08, Tom Smyth wrote:
>> Can you do  an exception for the ranges ...  so internet - private ips
>> you dont want over the tunnel)
>> 
>> ike esp from 10.90.0.0/24  to any encrypt  
>> and 
>> 
>>  10.90.0.0/24  to   NOT  [networks you dont want
>> over the tunnel)  ? 
>> 
>
>:) this was the first thought that i've had ... but i couldn't find how
> to do it ... at least in man ipsec.conf or isakmpd.conf
>
>

You do this with a "bypass flow" in /etc/ipsec.conf:

flow from $network/$prefix to $network/$prefix type bypass

and loading it with ipsecctl. Note if you use iked, you cannot configure
this directly in iked.conf, but you can still use ipsecctl and ipsec.conf
for this purpose in conjunction with iked for tunnel setup.

installing openbsd on raspberry pi 4

[Sandeep Gupta]

Hello,

 I am stuck on installing openbsd 6.8 (or 6.9) on rpi 4. I am able to
boot the openbsd installer off  of USB
 drive using  UEFI boot loader (on sd card). However the installer
fails at the step "What timezone are you in?".
 It doesn't like any timezone I input. Just before this step I get the
error "cd: /mnt/user/share/zoneinfo -- No such file or directory".
 I am not able to tell installer to skip this step.

Another issue I am facing is that installer giving warning:
"Are you *SURE* your install is complete without bsd" and other
similar warnings.
where should I place bsd, bsd.mp, and other files for installer to
pick those up. On the usb drive I have only
written miniroot68.img. This creates two partitions. None of these
partitions seems like there correct place
for bsd and other distribution sets files. Any pointers/help would be great.

Thanks
-S

Re: Why is tmpfs not working on OpenBSD?

[Marc Espie]

On Wed, Sep 08, 2021 at 09:54:52AM -0700, Chris Bennett wrote:
> On Mon, Sep 06, 2021 at 12:44:59AM +, iio7 wrote:
> > > > Why isn't it removed? It is kinda "misguiding".
> > >
> > > Shucks, you must feel terrible about our decision.
> > 
> > Well, compared to the fact that you, back in 2016, wrote that,
> > "We don't spend hours of our time adding unimportant notes to that file.", 
> > concerning updating the FAQ about this, maybe
> > instead of giving these useless comments, that you apparently
> > have got plenty of time to do, you should actually provide some
> > kind of useful information somewhere!
> > 
> 
> Wow. I guess a 2500 page FAQ would be much better.
> 
> But, I do believe I have found an important issue to add to the porting
> section of the FAQ.
> Although it covers submitting a single port, it does not cover how to
> deal with submitting a larger project with 20+ submissions.
> 
> I learned the hard way that the methods I was using to submit ports for
> a larger project just didn't work for getting these looked at and getting
> the two OK's needed for new ports. Oops.

Note that the main current issue wrt OpenBSD ports is the chronical lack
of time to look at everything that gets submitted.

"perfect submissions" tend to get looked at more easily, but it is
frequent to have to nag a bit to get people to look at it, especially when
it is not the most used port in the world.

(I do follow the "okay required to new ports rule" and I have to nag to
get things in as well)

-- 
Marc

Re: ipsec with default route and routing of internal networks

[Hrvoje Popovski]

On 13.9.2021. 14:08, Tom Smyth wrote:
> Can you do  an exception for the ranges ...  so internet - private ips
> you dont want over the tunnel)
> 
> ike esp from 10.90.0.0/24  to any encrypt  
> and 
> 
>  10.90.0.0/24  to   NOT  [networks you dont want
> over the tunnel)  ? 
> 

:) this was the first thought that i've had ... but i couldn't find how
to do it ... at least in man ipsec.conf or isakmpd.conf

Re: ipsec with default route and routing of internal networks

[Tom Smyth]

Can you do  an exception for the ranges ...  so internet - private ips you
dont want over the tunnel)

ike esp from 10.90.0.0/24 to any encrypt
and

 10.90.0.0/24 to   NOT  [networks you dont want over the tunnel)  ?

On Mon, 13 Sept 2021 at 13:02, Hrvoje Popovski  wrote:

> Hi,
>
> On 13.9.2021. 12:58, Tom Smyth wrote:
> > Hi Hrvoje,
> >
> > is 10.90.0.0/24  local to your firewall, and if I
> > understand your rule,
> > ike esp from 10.90.0.0/24  to anyyou are
> saying
> > encrypt all traffic comming from 10.90.0.0/24 
> >
> > should the tunnel be more specific ? like
> >
> > from 10.90.0.0/24   to another network across the
> > tunnel
> >
>
> 10.90/24 is my local internal network, as other networks (10.91/24,
> 10.92/24).
> i need "ike esp from 10.90.0.0/24 to any"... because hosts on that
> network need to go out to internet over ipsec tunnel ... but at the same
> time hosts in that 10.90/24 network needs to communicate to other
> internal networks...
>


-- 
Kindest regards,
Tom Smyth.

Re: ipsec with default route and routing of internal networks

[Hrvoje Popovski]

Hi,

On 13.9.2021. 12:58, Tom Smyth wrote:
> Hi Hrvoje, 
> 
> is 10.90.0.0/24  local to your firewall, and if I
> understand your rule,
> ike esp from 10.90.0.0/24  to any    you are saying  
> encrypt all traffic comming from 10.90.0.0/24  
> 
> should the tunnel be more specific ? like 
> 
> from 10.90.0.0/24   to another network across the
> tunnel  
> 

10.90/24 is my local internal network, as other networks (10.91/24,
10.92/24).
i need "ike esp from 10.90.0.0/24 to any"... because hosts on that
network need to go out to internet over ipsec tunnel ... but at the same
time hosts in that 10.90/24 network needs to communicate to other
internal networks...

Re: ipsec with default route and routing of internal networks

[Tom Smyth]

Hi Hrvoje,

is 10.90.0.0/24 local to your firewall, and if I understand your rule,
ike esp from 10.90.0.0/24 to anyyou are saying
encrypt all traffic comming from 10.90.0.0/24

should the tunnel be more specific ? like

from 10.90.0.0/24  to another network across the tunnel

ike esp from 10.90.0.0/24 to  {list of private network ranges that are
across the tunnel}

(remove any and replace with specific subnets to be routed across the Ipsec
tunnel)

without a diagram I cant help much more...


On Mon, 13 Sept 2021 at 11:36, Hrvoje Popovski  wrote:

> Hi all,
>
> I have a firewall that routes few internal networks, 10.90/24, 10.91/24,
> 10.92/24. And i have some static routes to other firewalls, but i don't
> think that is relevant to this problem.
>
> For network 10.90/24 i have ipsec tunnel, and i need to push any traffic
> from that network to the internet, but not to local networks,
> over that ipsec tunnel.
>
> something like this:
> ike esp from 10.90.0.0/24 to any
>
> I thought that the routing table will take care of that, but i seems
> that when ipsec tunnel is up, i can't connect from local networks
> (10.91/24, 10.92/24) to 10.90/24 and I can't even ping hosts on the
> 10.90/24 network ...
> something like this ping -I 10.90.0.1 10.90.0.8 ...
> traffic from 10.90/24 to the internet is working just fine ..
>
> I need to make network 10.90/24 reachable to all local networks.
> Could someone please point me in the right direction on what to look and
> configure?
>
> Thank you ..
>
>

-- 
Kindest regards,
Tom Smyth.

Re: OpenSMTPd: Ignoring /etc/hosts file?

[Simon Hoffmann]

> do you have "lookup file bind" record in your /etc/resolv.conf file?


This option is not available in the current debian version.
And I have to admit I have no clue what did the dns resolving. NetworkManager 
was
disabled, systemd-resolved was disabled, ...
Changes to the /etc/resolv.conf file would be overwritten by DHCP...

Really strange.

For now its fixed, I will supply the fix in another mail.
I should and will switch to OpenBSD tho in the near future.

Thanks!



signature.asc
Description: PGP signature

Resolved: OpenSMTPd: Ignoring /etc/hosts file?

[Simon Hoffmann]

I managed to resolve this issue with some strange workaround.

I must confess, I dont exactly know which service was handling DNS before, as
NetworkManager and systemd-resolved were both disabled.

/etc/resolv.conf was overwritten by each DHCP request.

So I did the following.

I configured systemd-resolved to also listen on 192.168.158.200:53, and to use
192.168.158.1 as DNS Server.

I then set the 6 domain-name-server DNS option on DNS for the host 
192.168.158.200 to
point to 192.168.158.200 (127.0.0.1 was not allowed).

So each DNS request is not sent to 192.168.158.200:53, which is the local
systemd-resolved. This then looks at the /etc/hosts file for matches, and 
forwards
queries to 192.168.158.1 if no matches are found.

Now OpenSMTP connects to the internal IP, but can still use SSL/TLS and verify 
the
certificate.


Strange strange...

When I have some more time I will switch OS to OpenBSD.

Thanks for your help!

Simon

> 
> Hey yall, 
> 
> in my smtpd.conf file I have "relay smtps://host.domain.tld"
> 
> host.domain.tld does resolve to a public IP, and this needs to be a public IP 
> on
> public DNS.
> However, OpenSMTPd needs to relay to the local IP address of the smarthost.
> Since I have no DNS server running on that network, and i dont want to setup 
> a DNS
> server only for OpenSMTPd, I added an enty to /etc/hosts, assigning the local 
> IP to
> the FQDN.
> When i ping the FQDN it correctly resolves to the internal IP of the 
> smarthost.
> However, OpenSMTPd ignores the entry in /etc/hosts and still tries to connect 
> to the
> public IP of the host.
> 
> Is this known that OpenSMTPd ingores /etc/hosts? Or is this a problem on 
> Debian?
> Is there a workaround? Specifying "relay smtps://192.168.158.1" will not 
> work, as the
> private IP is not part of the Cert. 
> Can I force OpenSMTPd to use the internal IP? Can I disable Cert checking for 
> the
> smarthost?
> 
> Thanks!
> 
> System details:
> 
> root@mx01:~# lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux 11 (bullseye)
> Release:11
> Codename:   bullseye
> root@mx01:~# smtpd -h
> version: OpenSMTPD 6.8.0p2
> usage: smtpd [-dFhnv] [-D macro=value] [-f file] [-P system] [-T trace]
> 
> root@mx01:~# cat /etc/network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> source /etc/network/interfaces.d/*
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The primary network interface
> allow-hotplug ens192
> iface ens192 inet dhcp
> 
> 
> Any info else you need?
> 
> Cheers, 
> 
> Simon




signature.asc
Description: PGP signature

ipsec with default route and routing of internal networks

[Hrvoje Popovski]

Hi all,

I have a firewall that routes few internal networks, 10.90/24, 10.91/24,
10.92/24. And i have some static routes to other firewalls, but i don't
think that is relevant to this problem.

For network 10.90/24 i have ipsec tunnel, and i need to push any traffic
from that network to the internet, but not to local networks,
over that ipsec tunnel.

something like this:
ike esp from 10.90.0.0/24 to any

I thought that the routing table will take care of that, but i seems
that when ipsec tunnel is up, i can't connect from local networks
(10.91/24, 10.92/24) to 10.90/24 and I can't even ping hosts on the
10.90/24 network ...
something like this ping -I 10.90.0.1 10.90.0.8 ...
traffic from 10.90/24 to the internet is working just fine ..

I need to make network 10.90/24 reachable to all local networks.
Could someone please point me in the right direction on what to look and
configure?

Thank you ..

Re: OpenSMTPd: Ignoring /etc/hosts file?

[misc]

do you have "lookup file bind" record in your /etc/resolv.conf file?

On Mon, Sep 13, 2021 at 10:20:30AM +0200, Simon Hoffmann wrote:
> 
> 
> > Has been reported previously -
> > https://github.com/OpenSMTPD/OpenSMTPD/issues/1115
> 
> Thanks for the link, this did not come up in my searches.
> 
> However, 
> 
> > The link also contains a workaround which may be useful for you.
> 
> the only "workaround" I could find was to specify the internal IP instead of 
> the
> hostname. I've tried this before and I've tried this just now, in both cases 
> it does
> not work, because, as I said, the private IP is not part of the certificate 
> and
> OpenSMTPd checks the certificate.
> 
> Is there a way to disable cert checking?
> 
> Log output: 
> 
> Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta connecting 
> address=smtp+tls://192.168.158.1:25 host=uhura.hoffmann.computer
> Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta connected
> Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta tls 
> ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
> Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta ssl_check_name: no 
> match for '192.168.158.1' in cert
> Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta error reason=SSL 
> certificate check failed
> Sep 13 10:04:54 mx01 smtpd[25157]: smtp-out: Disabling route [] <-> 
> 192.168.158.1 (uhura.hoffmann.computer) for 15s
> Sep 13 10:04:56 mx01 smtpd[25157]: smtp-out: No valid route for 
> [connector:[]->[relay:192.168.158.1,port=25,smtp+tls,mx,heloname=mx01.klm.hoffbox.net],0x0]
> 
> 
> Thanks, 
> 
> Simon
> 
> > 
> > Best,
> > Aisha
> > 
> > On 9/12/21 5:28 PM, Simon Hoffmann wrote:
> > > Hey yall,
> > > 
> > > in my smtpd.conf file I have "relay smtps://host.domain.tld"
> > > 
> > > host.domain.tld does resolve to a public IP, and this needs to be a 
> > > public IP on
> > > public DNS.
> > > However, OpenSMTPd needs to relay to the local IP address of the 
> > > smarthost.
> > > Since I have no DNS server running on that network, and i dont want to 
> > > setup a DNS
> > > server only for OpenSMTPd, I added an enty to /etc/hosts, assigning the 
> > > local IP to
> > > the FQDN.
> > > When i ping the FQDN it correctly resolves to the internal IP of the 
> > > smarthost.
> > > However, OpenSMTPd ignores the entry in /etc/hosts and still tries to 
> > > connect to the
> > > public IP of the host.
> > > 
> > > Is this known that OpenSMTPd ingores /etc/hosts? Or is this a problem on 
> > > Debian?
> > > Is there a workaround? Specifying "relay smtps://192.168.158.1" will not 
> > > work, as the
> > > private IP is not part of the Cert.
> > > Can I force OpenSMTPd to use the internal IP? Can I disable Cert checking 
> > > for the
> > > smarthost?
> > > 
> > > Thanks!
> > > 
> > > System details:
> > > 
> > > root@mx01:~# lsb_release -a
> > > No LSB modules are available.
> > > Distributor ID: Debian
> > > Description:Debian GNU/Linux 11 (bullseye)
> > > Release:11
> > > Codename:   bullseye
> > > root@mx01:~# smtpd -h
> > > version: OpenSMTPD 6.8.0p2
> > > usage: smtpd [-dFhnv] [-D macro=value] [-f file] [-P system] [-T trace]
> > > 
> > > root@mx01:~# cat /etc/network/interfaces
> > > # This file describes the network interfaces available on your system
> > > # and how to activate them. For more information, see interfaces(5).
> > > 
> > > source /etc/network/interfaces.d/*
> > > 
> > > # The loopback network interface
> > > auto lo
> > > iface lo inet loopback
> > > 
> > > # The primary network interface
> > > allow-hotplug ens192
> > > iface ens192 inet dhcp
> > > 
> > > 
> > > Any info else you need?
> > > 
> > > Cheers,
> > > 
> > > Simon
> > 
> 

Re: OpenSMTPd: Ignoring /etc/hosts file?

[Simon Hoffmann]

> Has been reported previously -
> https://github.com/OpenSMTPD/OpenSMTPD/issues/1115

Thanks for the link, this did not come up in my searches.

However, 

> The link also contains a workaround which may be useful for you.

the only "workaround" I could find was to specify the internal IP instead of the
hostname. I've tried this before and I've tried this just now, in both cases it 
does
not work, because, as I said, the private IP is not part of the certificate and
OpenSMTPd checks the certificate.

Is there a way to disable cert checking?

Log output: 

Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta connecting 
address=smtp+tls://192.168.158.1:25 host=uhura.hoffmann.computer
Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta connected
Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta ssl_check_name: no 
match for '192.168.158.1' in cert
Sep 13 10:04:54 mx01 smtpd[25157]: 10ba299cf5ba5905 mta error reason=SSL 
certificate check failed
Sep 13 10:04:54 mx01 smtpd[25157]: smtp-out: Disabling route [] <-> 
192.168.158.1 (uhura.hoffmann.computer) for 15s
Sep 13 10:04:56 mx01 smtpd[25157]: smtp-out: No valid route for 
[connector:[]->[relay:192.168.158.1,port=25,smtp+tls,mx,heloname=mx01.klm.hoffbox.net],0x0]


Thanks, 

Simon

> 
> Best,
> Aisha
> 
> On 9/12/21 5:28 PM, Simon Hoffmann wrote:
> > Hey yall,
> > 
> > in my smtpd.conf file I have "relay smtps://host.domain.tld"
> > 
> > host.domain.tld does resolve to a public IP, and this needs to be a public 
> > IP on
> > public DNS.
> > However, OpenSMTPd needs to relay to the local IP address of the smarthost.
> > Since I have no DNS server running on that network, and i dont want to 
> > setup a DNS
> > server only for OpenSMTPd, I added an enty to /etc/hosts, assigning the 
> > local IP to
> > the FQDN.
> > When i ping the FQDN it correctly resolves to the internal IP of the 
> > smarthost.
> > However, OpenSMTPd ignores the entry in /etc/hosts and still tries to 
> > connect to the
> > public IP of the host.
> > 
> > Is this known that OpenSMTPd ingores /etc/hosts? Or is this a problem on 
> > Debian?
> > Is there a workaround? Specifying "relay smtps://192.168.158.1" will not 
> > work, as the
> > private IP is not part of the Cert.
> > Can I force OpenSMTPd to use the internal IP? Can I disable Cert checking 
> > for the
> > smarthost?
> > 
> > Thanks!
> > 
> > System details:
> > 
> > root@mx01:~# lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Debian
> > Description:Debian GNU/Linux 11 (bullseye)
> > Release:11
> > Codename:   bullseye
> > root@mx01:~# smtpd -h
> > version: OpenSMTPD 6.8.0p2
> > usage: smtpd [-dFhnv] [-D macro=value] [-f file] [-P system] [-T trace]
> > 
> > root@mx01:~# cat /etc/network/interfaces
> > # This file describes the network interfaces available on your system
> > # and how to activate them. For more information, see interfaces(5).
> > 
> > source /etc/network/interfaces.d/*
> > 
> > # The loopback network interface
> > auto lo
> > iface lo inet loopback
> > 
> > # The primary network interface
> > allow-hotplug ens192
> > iface ens192 inet dhcp
> > 
> > 
> > Any info else you need?
> > 
> > Cheers,
> > 
> > Simon
> 



signature.asc
Description: PGP signature

Re: npppd - changing clients' route table

[Stuart Henderson]

On 2021-09-12, Radek  wrote:
> Sorry for the late reply, adding ":framed-ip-netmask=255.255.255.0:" doesn't 
> solve the problem. Tested on Win10.

framed-ip-netmask controls addition of the route on the npppd machine,
not the client. You only use it if you have multiple addresses behind
one VPN client machine. i.e. one machine connects in and provides
service for multiple clients.

PPP does not have support for classless internet addressing, only the
old style classful addressing  where the netmask is fixed depending on
the address itself.

See 
https://en.m.wikipedia.org/wiki/Classful_network#Classful_addressing_definition

As Yasuoka-san wrote, you need to use a network where the "classful"
netmask is 255.255.255.0, which means the address is between 192.0.0.0
and 223.255.255.255, so for a RFC1918 address you must use something
starting with 192.168.

In order to reach 10.55.0.0/24 without setting the default gateway, you
can use the feature of the Microsoft client where it uses DHCP over
L2TP to fetch more information. This lets you tell the client to route
traffic to 10.55.0.0/24 via the VPN without extra config on the client.



> On Mon, 22 Feb 2021 14:55:52 +0900 (JST)
> YASUOKA Masahiko  wrote:
>
>> Hi,
>> 
>> On Sun, 21 Feb 2021 19:18:48 +0100
>> Radek  wrote:
>> >> The interface which terminate the tunnel has "192.168.4.254".
>> >> Right?
>> > Do you mean the other end of the tunnel? It is 10.109.4.254
>> > interface pppx0 address 10.109.4.254 ipcp IPCP
>> 
>> Sorry, "192.168.4.244" should have been "10.109.4.254".
>> 
>> >> How about if you configure the npppd-users
>> >> 
>> >> rdk:
>> >>   :password=pasword:\
>> >>   :framed-ip-address=10.109.4.254:\
>> >>   :framed-ip-netmask=255.255.255.0:
>> >> 
>> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> >> session authenticated by the above "rdk".
>> > I have tried to configure npppd-users with netmask /24, but it doesnt make 
>> > any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel 
>> > to 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 
>> > through the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through 
>> > default gw or sometimes some traffic to 10.0.0.0/8 through another tunnel 
>> > at the same time. Now if the PPP tunnel is established the VPN catches all 
>> > the 10.0.0.0/8 traffic.
>> > 
>> > The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
>> > 
>> > Example:
>> > I have a public, static IP. There is configured route to 10.55.0.0/24 at 
>> > the ISP's side and I dont need any VPN tunnel to access 10.55.. 
>> > Somewhere over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
>> > If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
>> > can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.
>> 
>> The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
>> this case, is configured by Windows automatically.  I don't know a way
>> to stop or override this.  But by using another addresses for the
>> tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
>> routes configuration.
>> 
>> For example,
>> 
>> 1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
>>10.0.0.0/8.
>> 
>>ipcp IPCP {
>>   pool-address 192.168.255.1-192.168.255.32
>> :
>>interface pppx0 address 192.168.255.254 ipcp IPCP
>>---
>>rdk:
>> :password=pasword:\
>> :framed-ip-address=192.168.255.32:
>> 
>> 2. Configure dhcpd
>> 
>>/etc/dhcpd-l2tp.conf
>>
>>subnet 192.168.255.0 netmask 255.255.255.0 {
>>  option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
>>  option classless-static-routes10.109.3.0/24 192.168.255.254;
>>}
>>---
>>   
>>$ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf
>> 
>> > On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
>> > YASUOKA Masahiko  wrote:
>> > 
>> >> Hello,
>> >> 
>> >> On Sat, 20 Feb 2021 21:14:24 +0100
>> >> Radek  wrote:
>> >> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> >> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> >> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 
>> >> > goes via 10.109.4.254
>> >> > 
>> >> > client> route print 
>> >> > Network Destination   Netmask  Gateway  Interface Metric
>> >> >   0.0.0.0  0.0.0.0   192.168.1.1
>> >> > 192.168.1.101 20
>> >> > 10.0.0.0  255.0.0.0 10.109.4.254  
>> >> > 10.109.4.1 21
>> >> > 10.109.4.1  255.255.255.255 On-link
>> >> > 10.109.4.1276
>> >> > [...]
>> >> 
>> >> The interface which terminate the tunnel has "192.168.4.254".
>> >> Right?
>> >> 
>> >> > $ cat /etc/npppd/npppd-users
>> >> > rdk:\
>> >> > :password=pasword:\
>> >> > :framed-ip-address=10.109.4.1:
>> >> >