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.

if the question is about pf or ipfw, I'd say there's a decent chance it's considered on topic.

linXea: is pinging a raw ip quicker than a domain?

always check dns

Please name a terminal multiplexer (cf. tmux or screen) for freebsd.

What's wrong with either of those, they work on BSD and are in ports, tmux is usually the best choice

some people like zellij, or however you spell it. just a newer slightly fancier tmux. I like tmux

i use tmux, too.

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

I dont remember exactly but i believe screen requires suid or has a suid option, and tmux does not, and also easier to use.

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.

And with vpn but no pf everything is fine?

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

When pf and VPN are up or when pf is up, VPN both up and down?

only when VPN is up and pf active. Running pf on WAN, no issues what so ever

And running VPN without pf?

full speed, fast browsing.. no issues.

Mmh.

pfctl -d, and it instantly go back to fast browsing.

Share the pf conf?

Have you checked routing tables, just in case?

hastebin.com/share/sijoloqove.python sure, I do have a few test-lines in there, ex. MSS clamp, which made no change

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.

usually check routing tables with $ netstat -r, I check that quite early.. only one default

Do you have bridges?

no, unless you count running openvpn tun0 interface

No it's a run not a bridge.

then no, no bridges only one interface

is your vpn touching resolv.conf at all?

yes, it does

when VPN is up it will apply the providers VPN-dns

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.

I recommend simplifying it just in case.

Why do you use sloppy states?

Thats one of the things I recently tried to resolve the issue. It was suggested in a old openBSD pf thread.

I do have a conference call coming up. Will check back later. Thank you very much for the assistance.

pass quick on $ext_if proto ipv6

That is from the pf.conf(5) manpage

I think you should be using this syntax (proto ipv6) for your $vpn_if instead of inet6.

I will try that, but ipv6 is not really used, I just added it in case. My traffic is ipv4 only.

Are you sure your tun0 doesn't get an ipv6 addy?

What if you remove the ipv6 rules then?

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.

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?

You could add some log directives on the block lines and tcpdump -nei pflog0 to confirm if any traffic is blocked.

Let me know if you solve it, I'm curious (but sleepy) now

You could also just disable ipv6 in your system or remove the ipv6 IP from tun0 - supposing there is one - to confirm my hypothesis.

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.

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.

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.

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?

(watching pf blocking stuff in real-time is one of my favorite quick and dirty checks to catch mistakes)

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.

You could "set block-policy return" instead of drop and see if it improves. It should solve the timeout issue.

(But still means you need to fix the rules.)

I will clean the conf, lots of trial and error syntax present. Kind of embarrassed even showing it

+1 for live pflog

When you do you can remove at least some of the "all" or "from any to any" too. They are implied, I think.

When the installer says my home directory will be at /home, does that just mean /usr/home?

/home does not mean /usr/home

Probably /home/emmasterling

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

pretty sure that got changed recently and there is no /usr/home any more

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.

i prefer big giant zpool

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.

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.

And of course as we know everyone should be installing with zfs, right? :-)

If I was installing to a machine with an JBOD of SSDs, I'd prolly give it a try.

'til then, I'm a fairly committed UFS2 luddite.

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.

doesn't the ARC cache eat a ton of memory?

You can limit it, but it tanks (pardon the pun) performance.

that is my understanding also, which is why on my resource constrained machines I opted for ufs over zfs

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.

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.

I have a few pcengines apu2s and apu4s, the most powerful of which has only 4GB of memory and 16G of disk :3

nice to hear it's workable with less, though

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.

Who is complaining abour ARC cache?

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.

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.

Unless I throttle the ARC usage, programs die due to OOM when there's memory reclaimable from ARC.

This has been my experience; most people should not expect similar outcomes.

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.

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.

eh

i don't really need zfs snapshots

on those particular machines

Is that an "eh" as in "meh?" Or "eh" as in "eh!"??

Punctuation is the emoji of irc. Just say'n! :-)

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.

how bad is it to not have /sbin as the first PATH variable?

well first in $PATH

im still thinking about the whole fastboot issue on freebsd

/sbin/fastboot conflicts with /usr/local/bin/fastboot

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

on the other hand, a simple sed expression would fix it

ARC cache?

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.

rwp: /sbin is first

always

its /sbin/fastboot

not /usr/bin or /bin

We can agree to disagree.

And I then always prepend $HOME/bin so that I can override all of the above.

polarian: all flash-all scripts are already broken in the default configuration

because sbin is put ahead of bin

LXGHTNXNG: I am aware of this

sadly there are no standards for how "fastboot" is supposed to respond, be it by not existing or rebooting the system

14:43 < rwp> And I then always prepend $HOME/bin so that I can override

That sounds just about as smart as adding . to your path.

If you really need to depend on base or anything just a path vs depending on PATH.

CrtxReavr: How?

im trying to clean out my old bugs :p

Or set PATH before you run anything.

Is it somehow inadvisable to have any directory in your own PATH be writable to you?

dot-in-path, yeah, I see why that's inadvisable (although it is default on the plans 9)

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.

LXGHTNXNG: yes because a user shouldnt be able to edit files within the PATH

why not?

far fetched

Well, I would consider ones's home directory to be less secure that directories which are only writable by root. . .

but an exploit can add a script under your path

and you can accidentally execute it

not realising

because its in your path

but this is far fetched

a similar exploit could run a script w/o needing to put a file in your path

So bumping things in ~/bin/ ahead of those root-writable paths is probably not advisable.

not if it needs root :3

somescript is not bad until you do prepend doas or sudo >:)

And it's generally ill-adivsed to put . in your path for basically the same reason.

So... snake oil

CrtxReavr: I think its likely best to install it to afastboot imo, and then alias it

but nobody seems interested in the issue :(

orrrrrrr

better idea

Any exploit that requires you to be exploited for the exploit to work is not an exploit.

my actual configuration has ~/.local/bin prioritized; I install several useful scripts which I don't think to make globally available there

wow did i just use actual with the continental meaning

shoot me already

rwp: so privesc exploits arent exploits

because it usually requires a RCE of some sorts to exploit

RCE chained with a privesc

whole system pwned

$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.

(several english words have EU-English/continental meanings, influenced by the meaning of the same word in Romance and continental Germanic languages)

"python specific" it's closer to XDG-specific.

polarian, >> privesc exploits arent exploits: WAT?!

galaxy brane pensage happening here

rwp: you just said an exploit which depends on an exploit isnt an exploit

thus

privesc arent

they usually require another exploit to exploit

The privsec is the exploit. Full stop. Fix that one first.

oh so ignore a RCE, as long as we patch the privesc being exploited through the RCE xd

Such as the recent linux kernel copy.fail exploit.

you've been exploited by the two space virus. it makes you put two spaces between your sentences when only one is needed

which still requires local access rwp

so remote systems would still need an exploit to exploit copyfail

so

your position is that local user === root?

rwp said "Any exploit that requires you to be exploited for the exploit to work is not an exploit."

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.

... can we all agree to declare discussion bankruptcy? this thing is tumbling down a spiral.

a privesc usually requires you to be exploited already, to be exploited further. they are still separate exploits

mutually exclusive

LXGHTNXNG: sure :p

idk how we went from discussing fastboot (android) to exploits but ok :p

via $PATH

and then a form of social engineering that uses $PATH

Better not bring up ARC cache.

boru..

looo

lol*

rwp: sorry, claude needed babysitting, it was an "eh" as in "meh"

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 :(

Ah. The local (included) unbound?

opcode: broke it how?

wavefunction: no I run a split-horizon dns setup with unbound from pkg

zi: after the upgrade process, unbound was missing a .so upon which unbound-checkconf depended

that sounds a bit weird. did you do a pkg upgrade -f -y?

pretty sure? but maybe not

opcode: Is the .so still missing?

likely not. you probably have an unbound that was build against 14.3 installed

must be

in which case grr at myself

run file `which unbound-checkconf`

and that should show you what version of freebsd it was build under

sec, i just re-ran pkg upgrade -fy and it's currently rebooting

ah

well too late then

yeah sorry

no worries--but that's how you determine it for the future

noted, thx

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.

I don't claim to be more creative than people who might want to exploit me.

(page 349 of 3rd edition of the armadillo book covers $PATH well)

can i put zfs on an externel usb drive? its 2tb if that makes the difference

any reason not to?

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.

V_PauAmma_V: same setup here. ty

i have done this and it did get some checksum errors before the drive died

so i would also recommend

you can get fancy and even get a tiny bit of redundancy with "copies=2". :)

im here for compression

thats good to know though :)

some folks will just do two copies of metadata

.de is having a meltdown