Re: packet filter silently ignores a rule
Hello!
This was the first thing I checked.
But I think there was a deadly combo of two factors:
1) the continuation character
2) The nuance described in man pf.conf:
"Care should be taken when
commenting out multi-line text: the comment is effective until the end of
the entire block."
After continuous experimenting with the rules there are too many
commented lines mixed with real config blocks in my pf.conf.
I really have to do some cleaning.
Thank you everybody for all your help!
On Tue May 21 16:49:00 2024, Steve Williams wrote:
> A lot of Unix configuration files have an issue with the continuation
> character "\" IF THERE IS A SPACE AFTER IT!!
>
> Make sure that the \ is the last character on the line!
>
> S.
>
> On 20/05/2024 11:01 p.m., Maksim Rodin wrote:
> > I solved the problem by copying the entire rule block right after
> > the old one and commenting out the old one.
> >
> > New:
> > pass in on egress inet proto tcp to (egress) port $mail_ports \
> > keep state (max-src-conn 20, \
> > max-src-conn-rate 35/300, overload \
> > flush global) \
> > rdr-to $mail_server
> >
> > Old:
> > pass in on egress inet proto tcp to (egress) \
> > port $mail_ports \
> > keep state (max-src-conn 20, \
> > max-src-conn-rate 35/300, overload \
> > flush global) rdr-to $mail_server
> >
> > I only split one line and merged two other lines into one
> > but I think I did it correctly and I do not see any logical
> > changes in the block.
> >
> > I still cannot understand what happened because there were no
> > uncommented excess lines within the old block.
> >
> > Before copying the entire rule block I even occasionally made
> > a typo in the old rule and checked it with pfctl -nf /etc/pf.conf.
> > PF still did as if there were no block with the typo at all:
> >
> > pass in on egress inet proto tcp to (egress) \
> > ort $mail_ports \
> > keep state (max-src-conn 20, \
> > max-src-conn-rate 35/300, overload \
> > flush global) rdr-to $mail_server
> >
> >
> >
> > On Mon May 20 11:43:21 2024, Maksim Rodin wrote:
> > > Hello,
> > > I use OpenBSD 7.5 stable amd64.
> > > I uncommented an old rule and the corresponding macro in pf.conf
> > > which definitely worked when the
> > > machine was on version 7.3 and possibly 7.4.
> > >
> > > After that:
> > > pfctl -nf /etc/pf.conf shows nothing
> > > pfctl -f /etc/pf.conf shows nothing
> > > So Packet Filter seems to be happy with the config as a whole.
> > >
> > > pfctl -vvsr shows the old rules WITHOUT the uncommented one.
> > > pfctl -vvnf /etc/pf.conf warns that the uncommented macro
> > > used in the uncommented rule is NOT used.
> > >
> > > The output of pfctl -vvnf /etc/pf.conf is appended as
> > > pfctl_vvnf file
> > > The output of pfctl -vvsr is appended as
> > > pfctl_vvsr file
> > >
> > >
> > > Did I miss something when changing the configuration?
> > >
> > > The uncommented section 1 is:
> > > mail_ports = "{ submission imaps }"
> > >
> > > The uncommented section 2 is:
> > > pass in on egress inet proto tcp to (egress) \
> > > port $mail_ports \
> > > keep state (max-src-conn 20, \
> > > max-src-conn-rate 35/300, overload \
> > > flush global) rdr-to $mail_server
> > >
> > >
> > > My whole pf.conf (all uncommented lines):
> > > int_if = "{ vether1 em1 em2 em3 }"
> > > table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 \
> > > 169.254.0.0/16 172.16.0.0/12 192.0.2.0/24 \
> > > 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
> > > }
> > > table persist
> > > table persist file "/etc/mail/nospamd"
> > > table persist file "/etc/pf/bad_ips"
> > >
> > > transmission_server = "192.168.1.65"
> > > mail_server = "192.168.1.171"
> > >
> > > mail_ports = "{ submission imaps }"
> > >
> > > block log all
> > > set limit table-entries 100
> > > set block-policy drop
> > > set syncookies adaptive (start 29%, end 15%)
> > > set skip on lo
> > >
> > > match in all scrub (no-df random-id max-mss 1440)
> > > match out on egress inet from (vether1:network) \
> > > to any nat-to (egress:0)
> > >
> > > block in quick on egress from to any
> > > block return out quick on egress from any to
> > > block quick from
> > >
> > > pass out quick inet
> > > pass in on $int_if inet
> > >
> > > pass in on egress inet proto tcp \
> > > to (egress) port 22 keep state \
> > > (max-src-conn 2, max-src-conn-rate 2/300, \
> > > overload flush global)
> > >
> > > pass in on egress inet proto { tcp udp } \
> > > to (egress) port domain keep state \
> > > (max-src-states 10) \
> > > rdr-to 127.0.0.1 port 8053
> > >
> > > pass in on $int_if inet proto { tcp udp } from \
> > > (vether1:network) to (egress) port domain
> > >
> > > pass in on egress inet proto { tcp udp } \
> > > to (egress) port 5 \
> > > rdr-to $transmission_server
> > >
> > > pass in on egress inet proto tcp to (egress) \
> > > port $mail_ports \
> > > keep state (max-src-conn 20, \
> > >
Re: IPv6 routing problems with vether and vmm
Greetings, > > I also don't control the entire /48. > > > > Here is the information I was given: > > > > My IPv6 Address Subnet: 2602:fccf:400:41::/64 > > Hypervisor' IPv6 Gateway: 2602:fccf:400::1 > > > > I was only given a /64. > > So you should use a /64 prefix length not the /48 which you have. > > See EXAMPLES in route(8) for how to set the gateway. Please excuse my ignorance here, as I am unfamiliar with networking. Can you explain why /64 is the correct prefix length? I am confused because it seems not analogous to IPv4. In the IPv4 example, my address is 104.167.241.211, the gateway is 104.167.241.193, and the subnet mask 255.255.255.192. The network length then is /26. I don't control the entire /26 subnet, only one single IPv4 address within it, but my network would have a prefix length of /26. Isn't using a prefix length of /48 the same in the case of IPv6? I don't control the entire /48, but the gateway 2602:fccf:400::1 shares the first 48 network bits with my IPv6 address 2602:fccf:400:41:: If I were to set the routing prefix length to 64, then I could manually add an extra route to the IPv6 gateway. But then, wouldn't I want to set my IPv4 address with a subnet mask of 255.255.255.255, so that the network length would be 32 rather than 26, and also add a manual route there? -- jrmu IRCNow (https://ircnow.org) signature.asc Description: PGP signature
Re: IPv6 routing problems with vether and vmm
. On 21/05/2024 22:04, jrmu wrote: Greetings, Here is my configuration: Inside hypervisor: hypervisor$ cat /etc/hostname.em1 inet 104.167.241.211 0xffc0 inet6 2602:fccf:400:41:: 48 Why are you using 48 as mask here and not 64? I don't have control over the hypervisor's gateway, that is provided by my ISP. Okay but my question still apply here. em1 IPv6 address should have /64 as mask and not 48. Your gateway must have a (static) route saying we can reach 2602:fccf::/36 (or a any smaller subnet you will use in your hypervisor) via em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to use for all your VMs. I also don't control the entire /48. Here is the information I was given: My IPv6 Address Subnet: 2602:fccf:400:41::/64 Hypervisor' IPv6 Gateway: 2602:fccf:400::1 I was only given a /64. When you manage a hypervisor, using only 1x/64 is less than ideal. It's just not enough because you can have more than 1 'type of usage'. I always request at least 1x/56. You have at least 2 solutions: 1. Use the prefix 2602:fccf:400:41::/64 for all your interfaces . For em1 , avoid the first address. It works but some device will not happily accept your packets. Use anything else between 2602:fccf:400:41::1 and 2602:fccf:400:41:::: . Again use 64 as your mask and not 48 on em1. 2. Ask your ISP 2 things: 2.1 Establish point to point with you from 1 prefix 2.2 Route you *another* prefix (as explained in my previous email). If they find difficult to route more than 1x/64 (that will be a shame ) they can stick to 1x/64 but honestly it should not be a big deal. -- Willy Manga
Re: IPv6 routing problems with vether and vmm
On 2024-05-21, jrmu wrote: > > --qhuug7BO2jqFJSbi > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Greetings, > >> > Here is my configuration: >>=20 >> > Inside hypervisor: >>=20 >> > hypervisor$ cat /etc/hostname.em1 >> > inet 104.167.241.211 0xffc0 >> > inet6 2602:fccf:400:41:: 48 >>=20 >> Why are you using 48 as mask here and not 64? > > I don't have control over the hypervisor's gateway, that is provided by > my ISP. > >> Your gateway must have a (static) route saying we can reach 2602:fccf::/36 >> (or a any smaller subnet you will use in your hypervisor) via >> em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to >> use for all your VMs. > > I also don't control the entire /48. > > Here is the information I was given: > > My IPv6 Address Subnet: 2602:fccf:400:41::/64 > Hypervisor' IPv6 Gateway: 2602:fccf:400::1 > > I was only given a /64. So you should use a /64 prefix length not the /48 which you have. See EXAMPLES in route(8) for how to set the gateway.
Important message for Apple Silicon OpenBSD/arm64 users
As indicated here: https://social.treehouse.systems/@AsahiLinux/112449204541186432 The system firmware that comes with macOS Sonoma 14.5 triggers a bug in the m1n1 bootloader that is used to boot OpenBSD on these machines. The bug will prevent OpenBSD from booting on some machines after the macOS update has been installed. The recommended fix is to update the "stage1" m1n1 by booting into macOS and running: $ curl https://alx.sh | sh choosing the 'm' option when prompted to upgrade as indicated in the aforementioned post. This should work even if you've already installed the macOS update. We've also released a new version of the "apple-boot" firmware (which contains a "stage2" m1n1) that has a workaround for the bug. To install this new firmware on OpenBSD 7.5 or -current, you can do: # fw_update # installboot sd0 This must be done before updating macOS. You can verify that the workaround is installed with the following command: # eeprom -p | grep m1n1 asahi,m1n1-stage2-version: '1.4.14' If the displayed version number is 1.4.14 or later, the workaround is installed. OpenBSD 7.4 users should upgrade to OpenBSD 7.5. Cheers, Mark
Re: IPv6 routing problems with vether and vmm
Greetings, > > Here is my configuration: > > > Inside hypervisor: > > > hypervisor$ cat /etc/hostname.em1 > > inet 104.167.241.211 0xffc0 > > inet6 2602:fccf:400:41:: 48 > > Why are you using 48 as mask here and not 64? I don't have control over the hypervisor's gateway, that is provided by my ISP. > Your gateway must have a (static) route saying we can reach 2602:fccf::/36 > (or a any smaller subnet you will use in your hypervisor) via > em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to > use for all your VMs. I also don't control the entire /48. Here is the information I was given: My IPv6 Address Subnet: 2602:fccf:400:41::/64 Hypervisor' IPv6 Gateway: 2602:fccf:400::1 I was only given a /64. Thanks for your help. -- jrmu IRCNow (https://ircnow.org) signature.asc Description: PGP signature
Re: IPv6 routing problems with vether and vmm
Hi On 21/05/2024 04:01, jrmu wrote: > Here is my configuration: > Inside hypervisor: > hypervisor$ cat /etc/hostname.em1 > inet 104.167.241.211 0xffc0 > inet6 2602:fccf:400:41:: 48 Why are you using 48 as mask here and not 64? Here is a suggestion in term of routing. From your configuration, you can even restrict the mask here since it's a point to point between your hypervisor and your gateway. something like /etc/hostname.em1 inet6 2602:fccf::2 127 should be okay. Of course you configure your gateway with 2602:fccf::3/127 > hypervisor$ cat /etc/mygate > 104.167.241.193 > 2602:fccf:400::1 From my suggestion, you can change that IPv6 with 2602:fccf::3 Your gateway must have a (static) route saying we can reach 2602:fccf::/36 (or a any smaller subnet you will use in your hypervisor) via em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to use for all your VMs. Assuming your gateway is running OpenBSD, the route will be: route add -inet6 2602:fccf:400::/48 2602:fccf::2 Now from the hypervisor, you originate that prefix. e.g route add -inet6 -blackhole 2602:fccf:400::/48 ::1 All packets in that block by default is 'swallowed' here. Now any subnet used by any interface (like vether0) here will be reachable from the Internet and of course the VM as well will reach other networks. -- Willy Manga
Re: how to fsck automatically at boot
On 2024-05-21, Nick Holland wrote: > On 5/20/24 09:37, Jan Stary wrote: >> On May 20 13:22:26, mikyde...@yahoo.fr wrote: >>> Hello, >>> >>> I have two use cases and problems with fsck. >>> >>> 1) When my openbsd boots after an outage, the system asks me to fsck /, >>> /usr, /var or /home manually. >>> So I do >>> fsck /dev/sd0a >>> And then I'm asked questions and I usually answer F >>> >>> So my question is that I want this process to be done automatically at boot >>> time for each partition that has a problem. >> >> The /etc/rc boot script calls fsck -p; >> if that fails, it means fsck -p was unable to fix a major problem. >> It is the point that it requires an admin's intervention. >> >> You would have to change the fsck call to fsck -y; >> but don't do that. AIUI the rationale for not using -y by default is that fsck may do further damage to a badly damaged disk. But in practice many people wouldn't do anything other than hit 'y' lots or 'F' when fsck complains, in which case patching /etc/rc to run -y by default isn't going to be any worse... And there are certainly some classes of system where you don't really care about losing data (i.e. you can recreate from config management or backups) but you do want to maximise the chances of being able to connect in remotely, and in that case -y can definitely help. > I'd look at why your file systems are always needing these manual > interventions after a hard shutdown. I routinely power down my > personal systems with yanking the power cord if it would take me > longer "properly" connect a console and properly shut down. That really depends on what the system is doing. >>> When I remove that disk the boot sequence stops and asks for a fsck >>> I would like that this disk is mounted when it's present, but when it's not >>> installed I don't want the boot sequence to stop >> >> Make it also "noauto" in fstab and mount it in rc.local. > > Last I tried this, it didn't do what I wanted -- "noauto" still expects > to have the disk there and will fsck it on boot. Failure to be able to > do this stops the boot. It's been a while since I last tried this, so > perhaps something has changed (including my recollection?) See fstab(5) about fs_passno. > And this might be a solution for the OP's problem: > make /usr and /usr/* "ro" during normal operation reorder_kernel is run in the background from /etc/rc; for RO /usr you need to wait for that to finish. -- Please keep replies on the mailing list.
Re: how to fsck automatically at boot
On 5/20/24 09:37, Jan Stary wrote: On May 20 13:22:26, mikyde...@yahoo.fr wrote: Hello, I have two use cases and problems with fsck. 1) When my openbsd boots after an outage, the system asks me to fsck /, /usr, /var or /home manually. So I do fsck /dev/sd0a And then I'm asked questions and I usually answer F So my question is that I want this process to be done automatically at boot time for each partition that has a problem. The /etc/rc boot script calls fsck -p; if that fails, it means fsck -p was unable to fix a major problem. It is the point that it requires an admin's intervention. You would have to change the fsck call to fsck -y; but don't do that. I'd look at why your file systems are always needing these manual interventions after a hard shutdown. I routinely power down my personal systems with yanking the power cord if it would take me longer "properly" connect a console and properly shut down. yeah, I get fscks, but I rarely get a manual intervention required. It does happen...but rarely. (Also, don't let a server have power outages, obviously.) This is because I use a small server without screen and keyboard. So what? That is no excuse to leave broken filesystems unattended. 2) I have another disk in my small server, and I mount one partition of it with in fstab aa929243b0f5.a /var/mylogs ffs rw,nodev,nosuid 1 2 When I remove that disk the boot sequence stops and asks for a fsck I would like that this disk is mounted when it's present, but when it's not installed I don't want the boot sequence to stop Make it also "noauto" in fstab and mount it in rc.local. Last I tried this, it didn't do what I wanted -- "noauto" still expects to have the disk there and will fsck it on boot. Failure to be able to do this stops the boot. It's been a while since I last tried this, so perhaps something has changed (including my recollection?) I have some backup servers with big file systems that can take hours to fsck. I pulled the mount lines out of /etc/fstab and put them in a separate script that is invoked at boot from /etc/rc.local And this might be a solution for the OP's problem: make /usr and /usr/* "ro" during normal operation, and move all the "lots of volatile data" stuff over to partitions that are mounted post boot by a separate script. Maybe make /tmp an MFS if that's an option. That will minimize the fsck problems, and allow the system to come up for either manual, remote fixing or even fsck -y in the mountall script. Don't forget you ro'd the /usr partitions, otherwise your upgrades will be unpleasant. :) Nick.
Re: packet filter silently ignores a rule
On 2024-05-21, Maksim Rodin wrote: > I solved the problem by copying the entire rule block right after > the old one and commenting out the old one. > > New: > pass in on egress inet proto tcp to (egress) port $mail_ports \ > keep state (max-src-conn 20, \ > max-src-conn-rate 35/300, overload \ > flush global) \ > rdr-to $mail_server > > Old: > pass in on egress inet proto tcp to (egress) \ > port $mail_ports \ > keep state (max-src-conn 20, \ > max-src-conn-rate 35/300, overload \ > flush global) rdr-to $mail_server > > I only split one line and merged two other lines into one > but I think I did it correctly and I do not see any logical > changes in the block. ... >> My whole pf.conf (all uncommented lines): We can't tell if it was done correctly because you excluded commented lines from the file you showed. Read pf.conf(5) DESCRIPTION section, paragraph starting "The current line can be extended over multiple lines".
Re: packet filter silently ignores a rule
I solved the problem by copying the entire rule block right after
the old one and commenting out the old one.
New:
pass in on egress inet proto tcp to (egress) port $mail_ports \
keep state (max-src-conn 20, \
max-src-conn-rate 35/300, overload \
flush global) \
rdr-to $mail_server
Old:
pass in on egress inet proto tcp to (egress) \
port $mail_ports \
keep state (max-src-conn 20, \
max-src-conn-rate 35/300, overload \
flush global) rdr-to $mail_server
I only split one line and merged two other lines into one
but I think I did it correctly and I do not see any logical
changes in the block.
I still cannot understand what happened because there were no
uncommented excess lines within the old block.
Before copying the entire rule block I even occasionally made
a typo in the old rule and checked it with pfctl -nf /etc/pf.conf.
PF still did as if there were no block with the typo at all:
pass in on egress inet proto tcp to (egress) \
ort $mail_ports \
keep state (max-src-conn 20, \
max-src-conn-rate 35/300, overload \
flush global) rdr-to $mail_server
On Mon May 20 11:43:21 2024, Maksim Rodin wrote:
> Hello,
> I use OpenBSD 7.5 stable amd64.
> I uncommented an old rule and the corresponding macro in pf.conf
> which definitely worked when the
> machine was on version 7.3 and possibly 7.4.
>
> After that:
> pfctl -nf /etc/pf.conf shows nothing
> pfctl -f /etc/pf.conf shows nothing
> So Packet Filter seems to be happy with the config as a whole.
>
> pfctl -vvsr shows the old rules WITHOUT the uncommented one.
> pfctl -vvnf /etc/pf.conf warns that the uncommented macro
> used in the uncommented rule is NOT used.
>
> The output of pfctl -vvnf /etc/pf.conf is appended as
> pfctl_vvnf file
> The output of pfctl -vvsr is appended as
> pfctl_vvsr file
>
>
> Did I miss something when changing the configuration?
>
> The uncommented section 1 is:
> mail_ports = "{ submission imaps }"
>
> The uncommented section 2 is:
> pass in on egress inet proto tcp to (egress) \
> port $mail_ports \
> keep state (max-src-conn 20, \
> max-src-conn-rate 35/300, overload \
> flush global) rdr-to $mail_server
>
>
> My whole pf.conf (all uncommented lines):
> int_if = "{ vether1 em1 em2 em3 }"
> table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 \
>169.254.0.0/16 172.16.0.0/12 192.0.2.0/24 \
>192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
> }
> table persist
> table persist file "/etc/mail/nospamd"
> table persist file "/etc/pf/bad_ips"
>
> transmission_server = "192.168.1.65"
> mail_server = "192.168.1.171"
>
> mail_ports = "{ submission imaps }"
>
> block log all
> set limit table-entries 100
> set block-policy drop
> set syncookies adaptive (start 29%, end 15%)
> set skip on lo
>
> match in all scrub (no-df random-id max-mss 1440)
> match out on egress inet from (vether1:network) \
> to any nat-to (egress:0)
>
> block in quick on egress from to any
> block return out quick on egress from any to
> block quick from
>
> pass out quick inet
> pass in on $int_if inet
>
> pass in on egress inet proto tcp \
> to (egress) port 22 keep state \
> (max-src-conn 2, max-src-conn-rate 2/300, \
> overload flush global)
>
> pass in on egress inet proto { tcp udp } \
> to (egress) port domain keep state \
> (max-src-states 10) \
> rdr-to 127.0.0.1 port 8053
>
> pass in on $int_if inet proto { tcp udp } from \
> (vether1:network) to (egress) port domain
>
> pass in on egress inet proto { tcp udp } \
> to (egress) port 5 \
> rdr-to $transmission_server
>
> pass in on egress inet proto tcp to (egress) \
> port $mail_ports \
> keep state (max-src-conn 20, \
> max-src-conn-rate 35/300, overload \
> flush global) rdr-to $mail_server
>
> pass in on egress proto tcp to (egress) \
> port smtp divert-to 127.0.0.1 port spamd
> pass in on egress proto tcp from to (egress) \
> port smtp rdr-to $mail_server
> pass in log on egress proto tcp from \
> to (egress) port smtp \
> rdr-to $mail_server
> pass out on egress proto tcp to (egress) port smtp
>
>
> --
> Best regards
> Maksim Rodin
> warning: macro 'mail_ports' not used
> Loaded 714 passive OS fingerprints
> int_if = "{ vether1 em1 em2 em3 }"
> table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16
> 172.16.0.0/12 192.0.2.0/24 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 }
> table persist
> table persist file "/etc/mail/nospamd"
> table persist file "/etc/pf/bad_ips"
> transmission_server = "192.168.1.65"
> mail_server = "192.168.1.171"
> mail_ports = "{ submission imaps }"
> set limit table-entries 100
> set block-policy drop
> set syncookies adaptive (start 29%, end 15%)
> set skip on { lo }
> @0 block drop log all
> @1 match in all scrub (no-df random-id max-mss 1440)
> @2 match out on egress inet from
