12:50:34 <linXea> Hi, I got an peculiar issue on pf. Are there any specific channel (network?) where I can ask firewall specific questions? I am experiencing slow browsing when connected to openvpn whenever the firewall is enabled.
13:38:53 <scoobybejesus> if the question is about pf or ipfw, I'd say there's a decent chance it's considered on topic.
13:43:13 <morpho> linXea: is pinging a raw ip quicker than a domain?
13:43:26 <morpho> always check dns
14:53:09 <sebboh> Please name a terminal multiplexer (cf. tmux or screen) for freebsd.
14:56:19 <o0x1eef> What's wrong with either of those, they work on BSD and are in ports, tmux is usually the best choice
14:57:35 <scoobybejesus> some people like zellij, or however you spell it.  just a newer slightly fancier tmux.  I like tmux
14:57:49 <nxjoseph> i use tmux, too.
14:58:38 <nxjoseph> i also have a script that launches my terminal emulator with tmux and then newer works until that window is closed. Taughts me to not open any terminals when i have tmux running :p
14:58:47 <o0x1eef> I dont remember exactly but i believe screen requires suid or has a suid option, and tmux does not, and also easier to use.
15:43:13 <linXea> morpho, yes, direct IP is fast, as well as some sites, e.g. popular news sites. DNS for VPN is resolved automatically, from the VPN-provider and found in resolve.conf when VPN-interface tun0 is up. It seem like pf somehow throttle encrypted packets over tun0. My config is quite basic and nothing really out of the ordinary.
16:02:22 <Defenso-QTH> And with vpn but no pf everything is fine?
16:03:14 <linXea> yes, no issues. direct IP traffic has the same speed regardless. It is only actual browsing that is impacted (like 15s delay) when pf is up
16:04:09 <Defenso-QTH> When pf and VPN are up or when pf is up, VPN both up and down?
16:04:39 <linXea> only when VPN is up and pf active. Running pf on WAN, no issues what so ever
16:05:37 <Defenso-QTH> And running VPN without pf?
16:05:52 <linXea> full speed, fast browsing.. no issues.
16:06:28 <Defenso-QTH> Mmh.
16:06:28 <linXea> pfctl -d, and it instantly go back to fast browsing.
16:07:16 <Defenso-QTH> Share the pf conf?
16:07:35 <Defenso-QTH> Have you checked routing tables, just in case?
16:08:05 <linXea> https://hastebin.com/share/sijoloqove.python   sure, I do have a few test-lines in there, ex. MSS clamp, which made no change
16:08:42 <Defenso-QTH> I had an issue yesterday with a server that had two default routes, with only one working, and the result was partially-working but very slow.
16:09:42 <linXea> usually check routing tables with $ netstat -r, I check that quite early.. only one default
16:09:44 <Defenso-QTH> Do you have bridges?
16:10:24 <linXea> no, unless you count running openvpn tun0 interface
16:15:03 <Defenso-QTH> No it's a run not a bridge.
16:15:20 <linXea> then no, no bridges only one interface
16:15:34 <spork_css> is your vpn touching resolv.conf at all?
16:16:00 <linXea> yes, it does
16:16:40 <linXea> when VPN is up it will apply the providers VPN-dns
16:17:54 <Defenso-QTH> I don't see an issue in your pf.conf yet but it is unnecessarily verbose: state policy floating is default, keep state everywhere although it's default, almost all rules are quick, even the last one.
16:18:09 <Defenso-QTH> I recommend simplifying it just in case.
16:20:42 <Defenso-QTH> Why do you use sloppy states?
16:21:46 <linXea> Thats one of the things I recently tried to resolve the issue. It was suggested in a old openBSD pf thread.
16:23:35 <linXea> I do have a conference call coming up. Will check back later. Thank you very much for the assistance.
16:23:47 <Defenso-QTH> pass quick on $ext_if proto ipv6
16:24:08 <Defenso-QTH> That is from the pf.conf(5) manpage
16:25:07 <Defenso-QTH> I think you should be using this syntax (proto ipv6) for your $vpn_if instead of inet6.
16:26:12 <linXea> I will try that, but ipv6 is not really used, I just added it in case. My traffic is ipv4 only.
16:27:05 <Defenso-QTH> Are you sure your tun0 doesn't get an ipv6 addy?
16:27:51 <Defenso-QTH> What if you remove the ipv6 rules then?
16:28:30 <Defenso-QTH> Because I think that could be consistent with your experienced slowness: DNS resolved both ipv6 and ipv4, your browser tries v6 and waits for timeout before getting a result over v4.
16:29:48 <Defenso-QTH> You don't see it without VPN because you don't have a v6 addy on your physical WAN, and you don't see it with VPN+pf because your VPN actually works in v6, but pf blocks it?
16:30:42 <Defenso-QTH> You could add some log directives on the block lines and tcpdump -nei pflog0 to confirm if any traffic is blocked.
16:31:14 <Defenso-QTH> Let me know if you solve it, I'm curious (but sleepy) now
16:34:32 <Defenso-QTH> You could also just disable ipv6 in your system or remove the ipv6 IP from tun0 - supposing there is one - to confirm my hypothesis.
16:41:46 <Defenso-QTH> Actually that proto ipv6 is if you are doing 6in4. I have no idea how openvpn works and how pf would see packets in the tun0. So pflog will probably tell you more than my random ideas.
16:51:19 <linXea> that do make sense. I will try that later. I cannot lose connection at the moment. Thank you very much, I am 90% sure that will be the solution.
16:53:44 <spork_css> I'm probably wrong, but I think vpn + dns server change + pf anti-leak rules are combining to make one DNS resolver unreachable and your delay is the timeout to try another resolver in the list.
16:55:34 <spork_css> when you're having issues, can you manually resolve hostnames using every resolver IP in resolv.conf? If you tcpdump the pflog interface for blocks (eg: "tcpdump -n -e -ttt -i pflog0"), do you see anything being blocked while running the VPN?
16:56:18 <spork_css> (watching pf blocking stuff in real-time is one of my favorite quick and dirty checks to catch mistakes)
16:56:46 <linXea> another thing I need to check when I can afford to lose connection. I think I tested that, and had a lot more permissive rules to start with, with same error.
16:57:13 <Defenso-QTH> You could "set block-policy return" instead of drop and see if it improves. It should solve the timeout issue.
16:57:35 <Defenso-QTH> (But still means you need to fix the rules.)
16:58:23 <linXea> I will clean the conf, lots of trial and error syntax present. Kind of embarrassed even showing it
16:58:33 <Defenso-QTH> +1 for live pflog
17:00:28 <Defenso-QTH> When you do you can remove at least some of the "all" or "from any to any" too. They are implied, I think.
17:03:16 <EmmaSterling> When the installer says my home directory will be at /home, does that just mean /usr/home?
17:04:59 <joepublic> /home does not mean /usr/home
17:07:23 <Defenso-QTH> Probably /home/emmasterling
17:17:57 <CrtxReavr> The FreeBSD installer, if you didn't create a dedicated /home mount, it would create /usr/home, with a symlink from /home to /usr/home
17:20:14 <nimaje> pretty sure that got changed recently and there is no /usr/home any more
17:35:59 <CrtxReavr> Honestly, I feel like the installer has kinda gone to shit. . . it used to default to (encourage) separate /, /usr, /tmp, & /var volumes. . . where as more recently, it's seemed to default to the "big, giant /" model of sysadmin.
17:38:50 <rtprio> i prefer big giant zpool
18:06:14 <rwp> Yes.  Recent FreeBSD installer now creates zroot/home and zroot/home/rwp for home directories.  It's more like other operating systems that way.  It accomplishes the same effect as /usr/home did previously.  I think it is a good change.
18:07:07 <rwp> CrtxReavr, If you install using zfs you get all of the traditional separate datasets.  Nothing changed there for some time, other than the /home change just mentioned.
18:07:33 <rwp> And of course as we know everyone should be installing with zfs, right?  :-)
18:08:25 <CrtxReavr> If I was installing to a machine with an JBOD of SSDs, I'd prolly give it a try.
18:08:42 <CrtxReavr> 'til then, I'm a fairly committed UFS2 luddite.
18:13:33 <rwp> I use zfs on "small" 1 GB RAM virtual machines with 8 GB of storage because I have become a fairly zfs user.  It just makes everything so much easier.
18:17:17 <opcode> doesn't the ARC cache eat a ton of memory?
18:17:42 <boru> You can limit it, but it tanks (pardon the pun) performance.
18:18:24 <opcode> that is my understanding also, which is why on my resource constrained machines I opted for ufs over zfs
18:20:01 <boru> I ran a home NAS with 8GB of RAM for a while. It wasn't _that_ bad, but for a lot of users, you're going to feel it.
18:20:40 <spork_css> rwp: same, I have handful of very small VPS's out there with 1GB RAM and it's not at all like the 8.4 days, zfs does fine these days with a tiny amount of RAM.
18:20:54 <opcode> I have a few pcengines apu2s and apu4s, the most powerful of which has only 4GB of memory and 16G of disk :3
18:21:21 <opcode> nice to hear it's workable with less, though
18:22:14 <rwp> I personally don't understand why everyone is complaining about ARC cache because I don't personally see problems with it.  But as with all things it will be workload dependent.  Just because I don't see any problems doesn't discount other people seeing problems.  So I don't usually say anything.
18:22:50 <boru> Who is complaining abour ARC cache?
18:24:03 <rwp> Honestly my belief is that people don't understand memory.  And the best use thereof.  They want to see that their system has completely unused memory.  But that unused memory is not working for you.  So the system puts it to work as file system buffer cache.  That's good!  Then it is faster.
18:24:10 <rwp> But when they look they don't see the memory as being free and idle and they try to tune the system to stop it.  That's bad because it slows the system down.  And is unnecessary.
18:24:37 <LXGHTNXNG> Unless I throttle the ARC usage, programs die due to OOM when there's memory reclaimable from ARC.
18:25:01 <LXGHTNXNG> This has been my experience; most people should not expect similar outcomes.
18:25:35 <rwp> I have not seen that myself.  That's all I know.  And as I said, it depends upon the workload put upon the system.  Different people will be doing different things with their system.
18:27:56 <rwp> opcode, I would be running zfs on those "small" 4GB nodes.  Those are bigger than my single purpose VMs.  And anything bigger will be bigger and be fine.
18:29:03 <opcode> eh
18:29:19 <opcode> i don't really need zfs snapshots
18:29:24 <opcode> on those particular machines
18:29:39 <rwp> Is that an "eh" as in "meh?"  Or "eh" as in "eh!"??
18:30:39 <rwp> Punctuation is the emoji of irc.  Just say'n!  :-)
18:31:39 <rwp> I once got into trouble and took some heat because I read a sentence that had no punctuation as being a question and the person intended it as a statement.  Now I am once burned and twice cautious.
18:37:44 <polarian> how bad is it to not have /sbin as the first PATH variable?
18:37:54 <polarian> well first in $PATH
18:38:07 <polarian> im still thinking about the whole fastboot issue on freebsd
18:38:15 <polarian> /sbin/fastboot conflicts with /usr/local/bin/fastboot
18:38:59 <polarian> I have suggested making /usr/local/bin/fastboot --> /usr/local/bin/afastboot (android fastboot) but this would break all flash-all.sh scripts distributed by android vendors
18:39:08 <polarian> on the other hand, a simple sed expression would fix it
18:39:12 <CrtxReavr> ARC cache?
18:42:06 <rwp> polarian, I believe /usr/local/bin should be ahead of /usr/bin ahead of /bin so that the later layers have the ability to override the more base layers.  That's usually what is wanted.
18:42:42 <polarian> rwp: /sbin is first
18:42:44 <polarian> always
18:42:49 <polarian> its /sbin/fastboot
18:42:53 <polarian> not /usr/bin or /bin
18:43:09 <rwp> We can agree to disagree.
18:43:29 <rwp> And I then always prepend $HOME/bin so that I can override all of the above.
18:44:00 <LXGHTNXNG> polarian: all flash-all scripts are already broken in the default configuration
18:44:11 <LXGHTNXNG> because sbin is put ahead of bin
18:44:22 <polarian> LXGHTNXNG: I am aware of this
18:44:40 <LXGHTNXNG> sadly there are no standards for how "fastboot" is supposed to respond, be it by not existing or rebooting the system
18:44:41 <CrtxReavr> 14:43 < rwp> And I then always prepend $HOME/bin so that I can override
18:44:52 <CrtxReavr> That sounds just about as smart as adding . to your path.
18:45:01 <polarian> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284429
18:45:04 <skered> If you really need to depend on base or anything just a path vs depending on PATH.
18:45:04 <LXGHTNXNG> CrtxReavr: How?
18:45:07 <polarian> im trying to clean out my old bugs :p
18:45:30 <skered> Or set PATH before you run anything.
18:45:33 <LXGHTNXNG> Is it somehow inadvisable to have any directory in your own PATH be writable to you?
18:45:53 <LXGHTNXNG> dot-in-path, yeah, I see why that's inadvisable (although it is default on the plans 9)
18:45:56 <rwp> CrtxReavr, No.  It's not.  "." depends upon your present working directory.  $HOME/bin is your own directory always under your own control.  Not the same in the least.
18:45:56 <polarian> LXGHTNXNG: yes because a user shouldnt be able to edit files within the PATH
18:46:16 <LXGHTNXNG> why not?
18:46:23 <polarian> far fetched
18:46:30 <CrtxReavr> Well, I would consider ones's home directory to be less secure that directories which are only writable by root. . .
18:46:31 <polarian> but an exploit can add a script under your path
18:46:35 <polarian> and you can accidentally execute it
18:46:37 <polarian> not realising
18:46:41 <polarian> because its in your path
18:46:48 <polarian> but this is far fetched
18:46:48 <LXGHTNXNG> a similar exploit could run a script w/o needing to put a file in your path
18:46:57 <CrtxReavr> So bumping things in ~/bin/ ahead of those root-writable paths is probably not advisable.
18:46:57 <polarian> not if it needs root :3
18:47:13 <polarian> somescript is not bad until you do prepend doas or sudo >:)
18:47:24 <CrtxReavr> And it's generally ill-adivsed to put . in your path for basically the same reason.
18:47:41 <LXGHTNXNG> So... snake oil
18:47:42 <polarian> CrtxReavr: I think its likely best to install it to afastboot imo, and then alias it
18:47:56 <polarian> but nobody seems interested in the issue :(
18:48:03 <polarian> orrrrrrr
18:48:05 <polarian> better idea
18:48:15 <rwp> Any exploit that requires you to be exploited for the exploit to work is not an exploit.
18:48:26 <LXGHTNXNG> my actual configuration has ~/.local/bin prioritized; I install several useful scripts which I don't think to make globally available there
18:48:39 <LXGHTNXNG> wow did i just use actual with the continental meaning
18:48:42 <LXGHTNXNG> shoot me already
18:49:01 <polarian> rwp: so privesc exploits arent exploits
18:49:12 <polarian> because it usually requires a RCE of some sorts to exploit
18:49:16 <polarian> RCE chained with a privesc
18:49:20 <polarian> whole system pwned
18:49:24 <rwp> $HOME/.local/bin is a python specific thing that has crept into a lot of common use now.  I do not like it.  It's basically just another $HOME/bin.
18:49:25 <LXGHTNXNG> (several english words have EU-English/continental meanings, influenced by the meaning of the same word in Romance and continental Germanic languages)
18:49:44 <LXGHTNXNG> "python specific" it's closer to XDG-specific.
18:49:47 <rwp> polarian, >> privesc exploits arent exploits: WAT?!
18:50:00 <LXGHTNXNG> galaxy brane pensage happening here
18:50:02 <polarian> rwp: you just said an exploit which depends on an exploit isnt an exploit
18:50:04 <polarian> thus
18:50:06 <polarian> privesc arent
18:50:11 <polarian> they usually require another exploit to exploit
18:50:21 <rwp> The privsec is the exploit.  Full stop.  Fix that one first.
18:50:36 <polarian> oh so ignore a RCE, as long as we patch the privesc being exploited through the RCE xd
18:50:40 <rwp> Such as the recent linux kernel copy.fail exploit.
18:50:51 <LXGHTNXNG> you've been exploited by the two space virus. it makes you put two spaces between your sentences when only one is needed
18:50:54 <polarian> which still requires local access rwp
18:51:11 <polarian> so remote systems would still need an exploit to exploit copyfail
18:51:18 <LXGHTNXNG> so
18:51:26 <LXGHTNXNG> your position is that local user === root?
18:51:34 <polarian> rwp said "Any exploit that requires you to be exploited for the exploit to work is not an exploit."
18:51:35 <rwp> This entire conversation has degraded into irrationality and I can tell I am not going to change your mind.  And I have work to do that I am not working on while debating this here.  So I am going to focus on work.
18:51:40 <LXGHTNXNG> ... can we all agree to declare discussion bankruptcy? this thing is tumbling down a spiral.
18:52:15 <polarian> a privesc usually requires you to be exploited already, to be exploited further. they are still separate exploits
18:52:18 <polarian> mutually exclusive
18:52:35 <polarian> LXGHTNXNG: sure :p
18:52:52 <polarian> idk how we went from discussing fastboot (android) to exploits but ok :p
18:53:10 <LXGHTNXNG> via $PATH
18:53:20 <LXGHTNXNG> and then a form of social engineering that uses $PATH
18:53:21 <boru> Better not bring up ARC cache.
18:53:30 <LXGHTNXNG> boru..
18:53:43 <polarian> looo
18:53:45 <polarian> lol*
19:00:07 <opcode> rwp: sorry, claude needed babysitting, it was an "eh" as in "meh"
19:24:34 <opcode> grr, speaking of which I followed the handbook to the letter upgrading from 14.3-RELEASE-p5 to 15.0-RELEASE and it still broke unbound :(
19:26:36 <wavefunction> Ah. The local (included) unbound?
19:26:38 <zi> opcode: broke it how?
19:27:06 <opcode> wavefunction: no I run a split-horizon dns setup with unbound from pkg
19:27:24 <opcode> zi: after the upgrade process, unbound was missing a .so upon which unbound-checkconf depended
19:28:37 <zi> that sounds a bit weird.  did you do a pkg upgrade -f -y?
19:29:11 <opcode> pretty sure?  but maybe not
19:29:58 <skered> opcode: Is the .so still missing?
19:30:11 <zi> likely not.  you probably have an unbound that was build against 14.3 installed
19:30:29 <opcode> must be
19:30:38 <opcode> in which case grr at myself
19:30:43 <zi> run file `which unbound-checkconf`
19:31:06 <zi> and that should show you what version of freebsd it was build under
19:32:40 <opcode> sec, i just re-ran pkg upgrade -fy and it's currently rebooting
19:32:57 <zi> ah
19:32:58 <zi> well too late then
19:33:05 <opcode> yeah sorry
19:33:15 <zi> no worries--but that's how you determine it for the future
19:33:20 <opcode> noted, thx
20:42:17 * spork_css wanders up to dead horse...
20:43:10 <spork_css> I was taught in my early days that you always. want trusted, base binaries first in $PATH and I've never felt a need to diverge from that.
20:43:33 <spork_css> I don't claim to be more creative than people who might want to exploit me.
20:50:24 <spork_css> (page 349 of 3rd edition of the armadillo book covers $PATH well)
21:51:59 <morpho> can i put zfs on an externel usb drive? its 2tb if that makes the difference
21:52:25 <morpho> any reason not to?
21:59:59 <V_PauAmma_V> morpho, that's definitely an option (I use ZFS on my USB backup disk as well as ZFS on root for my laptop's internal disk) and I see no reason why you shouldn't.
22:03:28 <morpho> V_PauAmma_V: same setup here. ty
22:13:34 <rtprio> i have done this and it did get some checksum errors before the drive died
22:13:38 <rtprio> so i would also recommend
22:14:13 <spork_css> you can get fancy and even get a tiny bit of redundancy with "copies=2". :)
22:15:39 <morpho> im here for compression
22:16:24 <morpho> thats good to know though :)
22:39:35 <scoobybejesus> some folks will just do two copies of metadata
23:57:47 <Macer> .de is having a meltdown