Re: npppd - changing clients' route table
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-link10.109.4.1
>> > 276
>> > [...]
>>
>> 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:
>> > #:framed-ip-netmask=255.255.255.0:
>>
>> 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".
>>
>>
>> On Sat, 20 Feb 2021 21:14:24 +0100
>> Radek wrote:
>> > Hi,
>> > 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-link10.109.4.1
>> > 276
>> > [...]
>> >
>> > I need to redirect the traffic to 10.109.4.254 only if it goes to the
>> > remote LAN (10.109.3.0/24), the rest should go via def gw.
>> > How can I configure it on the router/server side ?
>> >
>> > $ cat /etc/npppd/npppd.conf
>> > # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
>> > # sample npppd configuration file. see npppd.conf(5)
>> >
>> > set max-session 200
>> > set user-max-session 4
>> >
>> > authentication LOCAL type local {
>> > users-file
pf on bridge interface not working
This came through to me from the list with “no content”, so I’m trying again.
——
My box has three interfaces, dc0 to manage, em0 and em1 for bridging external
LAN to internal LAN.
hostname.em0: up
hostname.em1: up
hostname.bridge0: add em0 add em1 up
Bridge works, traffic flows across no problem.
Add filtering.
pf.conf:
filtered = "{ em1 }”
not_filtered = "{ lo, dc0, em0, bridge0 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on em1 all
`tcpdump -nettti pflog0` shows lots of filtered packets. Traffic is blocked.
-But-
make one simple change to filter on the bridge0 interface—
pf.conf:
filtered = "{ bridge0 }”
not_filtered = "{ lo, dc0, em0, em1 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on bridge0 all
traffic is NOT blocked and everything flows right on through. (!?)
`tcpdump -nettti pflog0` shows no packets being filtered.
Am I overlooking something?
E
Re: pf on bridge interface not working
On Sat, Feb 20, 2021 at 04:17:11PM -0600, Eric Zylstra wrote:
> -But-
> make one simple change to filter on the bridge0 interface—
>
> pf.conf:
> filtered = "{ bridge0 }”
> not_filtered = "{ lo, dc0, em0, em1 }”
> block log on $filtered
> set skip on $not_filtered
>
> `doas pfctl -sr`
> block drop log on bridge0 all
>
> traffic is NOT blocked and everything flows right on through. (!?)
> `tcpdump -nettti pflog0` shows no packets being filtered.
>
> Am I overlooking something?
Perhaps this from bridge(4):
--8<--
NOTES
Bridged packets pass through pf(4) filters once as input on the receiving
interface and once as output on all interfaces on which they are
forwarded. In order to pass through the bridge packets must pass any in
rules on the input and any out rules on the output interface. Packets
may be blocked either entering or leaving the bridge.
-->8--
I partly recall a phrasing that I cannot find again now, unsure whether
it was from a manpage or from the FAQ; Something along: "Due to the
nature of bridged interfaces [...] you really have to understand this
very well to do [packet filtering] right".
Erling
Re: pf on bridge interface not working
Re: sndiod on by default (does it need to be ? )
On Sun, Feb 21, 2021 at 1:38 PM Stuart Henderson wrote:
> I don't honestly think it's worth going to the trouble of disabling.
> Look at the other software you run which isn't enabled in OpenBSD by
> default - that's where your attack surface is ;)
Also look at your hardware, and look at the documentation on the
software you're using.
Unless your concern is malware specifically targeted at your
environment, the consequences of being hit by malware probably aren't
going to be too far away from the consequences of running on faulty
hardware and/or not understanding your software.
(Malware specifically targeted at your environment would most likely
be motivated along the lines of discrediting you and/or your efforts.
And that's usually more easily accomplished using other methods, like
capitalizing on your most obvious mistakes.)
(If your concern is protection of trade secrets or loss of critically
important information: ink on paper does a pretty good job of holding
comprehensible information, and it has an attack surface which is
quite small, etc. But mostly, if those are concerns for you, it's
going to be about the people you're working with, and their
motivations. Also, mostly: NASA is a much better source of good
technical information, for those who want that.)
("Don't worry about people stealing an idea. If it's original, you
will have to ram it down their throats." -- Howard H. Aiken)
Anyways, the point I am trying to make here is that you're going to
notice some problems too late (so having plans for dealing with
failures is good, and having a variety of ways of isolating failures
is good).
That said: planning for the wrong disaster is usually better than not
planning for any disasters.
Good luck,
--
Raul
Re: OpenBSD NTFS experience
Thanks for your reply Maurice, I tried the read-only driver on an earlier version maybe 6.6 and it crashed. I wasn't able to debug it myself but I suppose it could have been my external hard drive, the NTFS version or a particular file that caused that issue as it happened with a large data copy and a particularly large file (multiple GB). I'm finding poor performance with USB drives on 6.8 with a hard disk and a card reader. It could be ntfs-3g with the hard drive but the card is FAT32. I am wondering if it's to do with the default shm kernel variables or maxfiles and such. It causes various hangs in thunar file manager. I previously had increased shm variables because of a KDE application recommending it for lots of file accesses. I know ntfs-3g is using FUSE rather than a native driver. Regards Ed Gray On Sun, 21 Feb 2021, 6:51 pm Maurice McCarthy, wrote: > Native read-only support is excellent. > I find writing with ntfs-3g quite a lot slower than native Windows > Best >
Fw: Re: npppd - changing clients' route table
Hello,
> 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
> 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.
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-link10.109.4.1
> > 276
> > [...]
>
> 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:
> > #:framed-ip-netmask=255.255.255.0:
>
> 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".
>
>
> On Sat, 20 Feb 2021 21:14:24 +0100
> Radek wrote:
> > Hi,
> > 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-link10.109.4.1
> > 276
> > [...]
> >
> > I need to redirect the traffic to 10.109.4.254 only if it goes to the
> > remote LAN (10.109.3.0/24), the rest should go via def gw.
> > How can I configure it on the router/server side ?
> >
> > $ cat /etc/npppd/npppd.conf
> > # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
> > # sample npppd configuration file. see npppd.conf(5)
> >
> > set max-session 200
> > set user-max-session 4
> >
> > authentication LOCAL type local {
> > users-file "/etc/npppd/npppd-users"
> > }
> > tunnel L2TP protocol l2tp {
> > listen on X.X.X.X
> > }
> >
> > ipcp IPCP {
> > pool-address 10.109.4.1-10.109.4.32
> > dns-servers 1.1.1.1
> > }
> >
> > # use pppx(4) interface. use an interface per a ppp session.
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> > bind tunnel from L2TP authenticated by LOCAL to pppx0
> >
> > $ cat /etc/npppd/npppd-users
> > rdk:\
> > :password=pasword:\
> > :framed-ip-address=10.109.4.1:
> > #:framed-ip-netmask=255.255.255.0:
> >
> > $ dmesg | head
> > OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021
> >
> > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > --
> > Radek
> >
>
--
Radek
Re: sndiod on by default (does it need to be ? )
Thanks Stuart, appreciate your time on this, and explanation of the sndiod design it was a case of I dont understand, dont use so I just disable. and then I proceeded to ask out of turn shouldn't everyone else disable because I dont understand or use it my self :/ Re attack surface / risk of other software that I use on top of OpenBSD I couldn't agree more with you Thanks again.. On Sun, 21 Feb 2021 at 18:42, Stuart Henderson wrote: > > On 2021-02-21, Tom Smyth wrote: > > my thinking is by having the service off by default would reduce the > > default attack surface of the OS ? > > The attack surface is tiny. > > sndiod has a pair of processes each run as their own dedicated uid, one > in a chroot jail containing no files and pledged to not allow access to > read/write files anyway, the other (which needs to access audio-related > nodes in /dev) using unveil to restrict itself to only the necessary > ones. The pledges are very restrictive. No network access unless you use > -L to enable the network server. > > I don't honestly think it's worth going to the trouble of disabling. > Look at the other software you run which isn't enabled in OpenBSD by > default - that's where your attack surface is ;) > > -- Kindest regards, Tom Smyth.
Re: sndiod on by default (does it need to be ? )
On 2021-02-21, Tom Smyth wrote: > my thinking is by having the service off by default would reduce the > default attack surface of the OS ? The attack surface is tiny. sndiod has a pair of processes each run as their own dedicated uid, one in a chroot jail containing no files and pledged to not allow access to read/write files anyway, the other (which needs to access audio-related nodes in /dev) using unveil to restrict itself to only the necessary ones. The pledges are very restrictive. No network access unless you use -L to enable the network server. I don't honestly think it's worth going to the trouble of disabling. Look at the other software you run which isn't enabled in OpenBSD by default - that's where your attack surface is ;)
Re: sndiod on by default (does it need to be ? )
If you are planning to deploy many systems in the near future and your deployment script is very invovled then you might want to consider building your own release and using that to install instead. This way you don't need to append your deployment script to either /install.site or /etc/rc.firsttime each time you install a new system. Sincerely, Jean-Pierre On 21/02/21 05:34pm, Tom Smyth wrote: > Hi folks, > thanks for everyone who replied on and off list, > I had not considered the console only user who uses audio also... > (I had not even considered this so pardon my ignorance folks, > and thanks to Sebastian, Abel, and David for replying on and off list > > I guess Ill just add rcctl disable sndiod to my deploy ment scripts > for my use cases :) > > Thanks again to all who considered it > > :) > > > > On Sun, 21 Feb 2021 at 14:28, Tom Smyth wrote: > > > > Hi Sebastian > > I get users want to listen to audio but if the only hardware is a buzzer > > and the user is not running x what are the chances they are using audio on > > the console only ? > > > > I can keep running > > rcctl disable sndiod > > Post install > > > > I thought linking audio support on by default to x would make sense as it > > is likely such system is for users who may need audio > > > > Just a thought > > Thanks > > > > > > On Sunday, 21 February 2021, Sebastian Benoit wrote: > >> > >> Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > >> > Hello, > >> > > >> > I was wondering should sndiod (default) startup be determined based on > >> > whether or not > >> > it the install is a typical headless install (off) or an install for > >> > a user machine with running X > >> > > >> > is there a reason why one would need to run this daemon by default? > >> > >> Because users want to listen to audio. > >> > >> > my thinking is by having the service off by default would reduce the > >> > default attack surface of the OS ? > >> > >> How big is that attack surface? And especially compared to X? > >> > >> > perhaps the installer could use the answer to the question do you > >> > intend to run X to determine whether or not to enable the sndiod > >> > daemon ? > >> > >> The difference is that a running sndiod is not noticable to you. Running X > >> is - you dont have a console anymore on your screen. > >> > >> Whereas a not running sndiod is noticable - no sound. > >> > >> Next to security, we try to make it easy for people to use OpenBSD. Not > >> asking questions when not needed is just that. > >> > >> /Benno > > > > > > > > -- > > Kindest regards, > > Tom Smyth. > > > > -- > Kindest regards, > Tom Smyth. >
Re: sndiod on by default (does it need to be ? )
Hi folks, thanks for everyone who replied on and off list, I had not considered the console only user who uses audio also... (I had not even considered this so pardon my ignorance folks, and thanks to Sebastian, Abel, and David for replying on and off list I guess Ill just add rcctl disable sndiod to my deploy ment scripts for my use cases :) Thanks again to all who considered it :) On Sun, 21 Feb 2021 at 14:28, Tom Smyth wrote: > > Hi Sebastian > I get users want to listen to audio but if the only hardware is a buzzer and > the user is not running x what are the chances they are using audio on the > console only ? > > I can keep running > rcctl disable sndiod > Post install > > I thought linking audio support on by default to x would make sense as it is > likely such system is for users who may need audio > > Just a thought > Thanks > > > On Sunday, 21 February 2021, Sebastian Benoit wrote: >> >> Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: >> > Hello, >> > >> > I was wondering should sndiod (default) startup be determined based on >> > whether or not >> > it the install is a typical headless install (off) or an install for >> > a user machine with running X >> > >> > is there a reason why one would need to run this daemon by default? >> >> Because users want to listen to audio. >> >> > my thinking is by having the service off by default would reduce the >> > default attack surface of the OS ? >> >> How big is that attack surface? And especially compared to X? >> >> > perhaps the installer could use the answer to the question do you >> > intend to run X to determine whether or not to enable the sndiod >> > daemon ? >> >> The difference is that a running sndiod is not noticable to you. Running X >> is - you dont have a console anymore on your screen. >> >> Whereas a not running sndiod is noticable - no sound. >> >> Next to security, we try to make it easy for people to use OpenBSD. Not >> asking questions when not needed is just that. >> >> /Benno > > > > -- > Kindest regards, > Tom Smyth. -- Kindest regards, Tom Smyth.
OpenBSD NTFS experience
Hi, Has anyone had experience using NTFS with OpenBSD and if so any pointers particularly around performance and any problems encountered? I realise NTFS is probably not used by many people but I have an external drive which is formatted with it. It would be useful to know if anyone is using the read-only NTFS driver or ntfs-3g port successfully and if there are any known bugs with these. Regards Ed Gray https://www.linkedin.com/in/ed-gray-55079422
Re: sndiod on by default (does it need to be ? )
On Sun, Feb 21, 2021 at 8:39 AM Tom Smyth wrote: > Hi Sebastian > I get users want to listen to audio but if the only hardware is a buzzer > and the user is not running x what are the chances they are using audio on > the console only ? > > I can keep running > rcctl disable sndiod > Post install > > I thought linking audio support on by default to x would make sense as it > is likely such system is for users who may need audio > > Just a thought > Thanks > > > On Sunday, 21 February 2021, Sebastian Benoit > wrote: > > > Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > > > Hello, > > > > > > I was wondering should sndiod (default) startup be determined based on > > > whether or not > > > it the install is a typical headless install (off) or an install for > > > a user machine with running X > > > > > > is there a reason why one would need to run this daemon by default? > > > > Because users want to listen to audio. > > > > > my thinking is by having the service off by default would reduce the > > > default attack surface of the OS ? > > > > How big is that attack surface? And especially compared to X? > > > > > perhaps the installer could use the answer to the question do you > > > intend to run X to determine whether or not to enable the sndiod > > > daemon ? > > > > The difference is that a running sndiod is not noticable to you. Running > X > > is - you dont have a console anymore on your screen. > > > > Whereas a not running sndiod is noticable - no sound. > > > > Next to security, we try to make it easy for people to use OpenBSD. Not > > asking questions when not needed is just that. > > > > /Benno > > > I use audio with mpd + ncmpc, without X need. No thanks... > -- > Kindest regards, > Tom Smyth. >
Re: sndiod on by default (does it need to be ? )
Hi Sebastian I get users want to listen to audio but if the only hardware is a buzzer and the user is not running x what are the chances they are using audio on the console only ? I can keep running rcctl disable sndiod Post install I thought linking audio support on by default to x would make sense as it is likely such system is for users who may need audio Just a thought Thanks On Sunday, 21 February 2021, Sebastian Benoit wrote: > Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > > Hello, > > > > I was wondering should sndiod (default) startup be determined based on > > whether or not > > it the install is a typical headless install (off) or an install for > > a user machine with running X > > > > is there a reason why one would need to run this daemon by default? > > Because users want to listen to audio. > > > my thinking is by having the service off by default would reduce the > > default attack surface of the OS ? > > How big is that attack surface? And especially compared to X? > > > perhaps the installer could use the answer to the question do you > > intend to run X to determine whether or not to enable the sndiod > > daemon ? > > The difference is that a running sndiod is not noticable to you. Running X > is - you dont have a console anymore on your screen. > > Whereas a not running sndiod is noticable - no sound. > > Next to security, we try to make it easy for people to use OpenBSD. Not > asking questions when not needed is just that. > > /Benno > -- Kindest regards, Tom Smyth.
Re: npppd - changing clients' route table
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.1192.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-link10.109.4.1
> 276
> [...]
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:
> #:framed-ip-netmask=255.255.255.0:
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".
On Sat, 20 Feb 2021 21:14:24 +0100
Radek wrote:
> Hi,
> 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.1192.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-link10.109.4.1
> 276
> [...]
>
> I need to redirect the traffic to 10.109.4.254 only if it goes to the remote
> LAN (10.109.3.0/24), the rest should go via def gw.
> How can I configure it on the router/server side ?
>
> $ cat /etc/npppd/npppd.conf
> # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
> # sample npppd configuration file. see npppd.conf(5)
>
> set max-session 200
> set user-max-session 4
>
> authentication LOCAL type local {
> users-file "/etc/npppd/npppd-users"
> }
> tunnel L2TP protocol l2tp {
> listen on X.X.X.X
> }
>
> ipcp IPCP {
> pool-address 10.109.4.1-10.109.4.32
> dns-servers 1.1.1.1
> }
>
> # use pppx(4) interface. use an interface per a ppp session.
> interface pppx0 address 10.109.4.254 ipcp IPCP
> bind tunnel from L2TP authenticated by LOCAL to pppx0
>
> $ cat /etc/npppd/npppd-users
> rdk:\
> :password=pasword:\
> :framed-ip-address=10.109.4.1:
> #:framed-ip-netmask=255.255.255.0:
>
> $ dmesg | head
> OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021
>
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> --
> Radek
>
Re: sndiod on by default (does it need to be ? )
Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > Hello, > > I was wondering should sndiod (default) startup be determined based on > whether or not > it the install is a typical headless install (off) or an install for > a user machine with running X > > is there a reason why one would need to run this daemon by default? Because users want to listen to audio. > my thinking is by having the service off by default would reduce the > default attack surface of the OS ? How big is that attack surface? And especially compared to X? > perhaps the installer could use the answer to the question do you > intend to run X to determine whether or not to enable the sndiod > daemon ? The difference is that a running sndiod is not noticable to you. Running X is - you dont have a console anymore on your screen. Whereas a not running sndiod is noticable - no sound. Next to security, we try to make it easy for people to use OpenBSD. Not asking questions when not needed is just that. /Benno
Re: pf on bridge interface not working
On 2021-02-20, Eric Zylstra wrote:
> -But- make one simple change to filter on the bridge0 interface--
> pf.conf:
>
> filtered = "{ bridge0 }"
> not_filtered = "{ lo, dc0, em0, em1 }"
> block log on $filtered
> set skip on $not_filtered
>
>
>> doas pfctl -f /etc/pf.conf
>
>> doas pfctl -sr
>
> block drop log on bridge0 all
>
>
>
> Despite the rules displayed by pfctl, traffic is NOT filtered. (!?)
> `tcpdump -nettti pflog0` shows no packets being filtered.
>
>
>
> What am I overlooking?
bridge(4) doesn't work like that on OpenBSD. You need to filter the member
ports instead.
On the whole bridge and PF interactions are a bit complicated. Keep an eye
out for veb(4) (https://marc.info/?l=openbsd-tech=161335364329307=2)
which maybe coming to a tree near you soon which will simplify things a lot.
