Re: PF annoying messages
On 07Jul2021 10:59, Pierre Dupond <76nem...@gmx.ch> wrote: > I am setting up a firewall with PF. The strategy used is quite > common: > set block-policy return > set loginterface none > set skip on lo0 > match in all scrub (random-id reassemble tcp) > block log I think this sets _both_ block and log as the packet acceptance state. _Not_ "log if I block" i.e. a pass rule will still log. Try putting just "block" here, and annotating only the rules you want to log with "log". I was going to suggest a final "block log", but that will only work if all your pass rules have "quick", preventing further rules from applying. Cheers, Cameron Simpson
Re: pf, relayd, TCP keep alive and NAT, oh my!
On 01Jun2021 20:43, Stuart Henderson wrote: >On 2021-06-01, Cameron Simpson wrote: >> If I had TCP keep alive turned on, both ends might tidy themselves up. >> I can't enable that on the clients (various mail readers) or, >> apparently, on the server configuration. I can't do it in PF because PF >> just copies packets. I can't seem to do it in relayd either, though that >> seems the obvious way to intercept the connection for this purpose. > >It looks like courier-imap does enable SO_KEEPALIVE if available. Hmm. Ok. I wonder how recent that is? I have 5.0.6 IIRC, and current is 5.1.something. >By default, keepalive timers are long; on a random Linux I had handy: > >$ grep . /proc/sys/net/ipv4/tcp_keepalive_* >/proc/sys/net/ipv4/tcp_keepalive_intvl:75 >/proc/sys/net/ipv4/tcp_keepalive_probes:9 >/proc/sys/net/ipv4/tcp_keepalive_time:7200 > >7200s (2h) initially, then every 75 seconds. (OpenBSD default times are >long too; 14400 "slowhz" intervals = also 2h). Ah. A long time indeed. Yes, winding these down will help - the above times are in the same magnitude as the time required to hit the connection limits. >> Plan B is to build the latest courier-imap from source if I find the >> time, but there may be no build option for this. I guess a single >> setsockopt() call in the source would be enough, _if_ that can be done >> on the accept end, which I haven't checked. > >https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/addsupport.html but I don't think >you'll need it. Ta. >So you probably just need to lower tcp_keepalive_time, and perhaps adjust >tcp_keepalive_intvl. Note there is a tradeoff especially with mobile >clients; they will need to wake and transmit more often, so faster >keepalives will result in more battery/data use. I can wind it down to a handful of minutes without any serious impact I'd expect. >> Plan B0 might be to disable IMAP IDLE support. Hmm. > >Depends on timings whether that will help; think it's a last ditch effort >though, I think it will make things noticably worse for clients. Courier lets me change the advertised capabilities (it is not clear if that affects the actual capabilities). Not joy; possibly some clinets will try IDLE even if it isn't advertised and just cope if not supported, so maybe some clients are using IDLE successfully anyway. At any rate, dropping IDLE from the advertised list didn't help, and my hourly "restart imapd" cron is live again :-( I'll look at the keepalive settings on the server, many thanks! Cheers, Cameron Simpson
Re: pf, relayd, TCP keep alive and NAT, oh my!
On 01Jun2021 11:04, Claudio Jeker wrote: >Make sure you use 'block return' at least for the imap connections. I already do: set block-policy return [... and the first rule ...] # reject everything except as detailed below block return log >This >way when the state is dropped the firewall will issue a RST packet to the >server which will close the connection. Alas, no. I believe that the _modem_ is dropping its NAT state (or some upstream stateful switch is getting likewise bored) and that the connection is idle. The firewall's modem's probably sending an RST to the client if it tries to use the connection after the modem forgets it, or something, causing the client to make a new connection to recover. The state table on the firewall itself seems fine (about 30 connections, in keeping with the staff and devices in the office). The problem is server side (cloud mail server). The connection goes idle, the office modem forgets the NAT, the server never sees _any_ indication that the TCP is no longer valid because it's idle. >On OpenBSD there is the 'net.inet.tcp.always_keepalive' sysctl to >enable keepalive by default. So that is something you can enable on the IMAP >server to force keep-alive on there. Other systems have similar knobs. The IMAP server is Linux, so I'll look at that. Thanks! Also, setting this on the firewall and interposing relayd would also do the same trick. SO that will be my fallback plan. Thanks, Cameron Simpson
Re: pf, relayd, TCP keep alive and NAT, oh my!
On 01Jun2021 08:53, Dirk Coetzee wrote: >As a first guess, I would consider changing / implementing "set >optimization". This made massive difference on our customers satellite >internet connection. The customer has a terrestrial ISP connection. I've got satellite at home, and do indeed use this setting. I'm not sure it will help my client though. Cheers, Cameron Simpson
pf, relayd, TCP keep alive and NAT, oh my!
Can I enforce or implement TCP keep alives on a TCP stream via my firewall? Background: I've got a client with an OpenBSD firewall and a Telstra NBN modem as their modem. Their IMAP server is upstream in the cloud (Unbuntu, courier imap). I have this odd problem which I am beginning to suspect is the NBN modem getting bored and dropping its NAT entries. Let me explain... At the firewall end I see about 30 ESTABLISHED connections to the IMAP server. At the IMAP server I see over 500, which is about where the IMAP service stops accepting new connections, leading to errors from the client mail readers. My current theory is that the IMAP client connections issue the IMAP IDLE command and go passive, waiting for email notifications from the server. So we have an idle TCP connection across the firewall and across the NBN modem (which NATs). My conjecture is that at some point the modem discards idle connection states. (This could just as well happen at any other intermediate stateful router too.) After that event, the client end does something which tries to use the connection, gets an RST from the modem, clean tidyup happens on the client and in the firewall. At the server end, none of this is seen and the imapd just sits around idle, never releasing the connection and never stopping the matching daemon process. This gradually rises to hit the server's configured connection limit and it stops accepting new things. If I had TCP keep alive turned on, both ends might tidy themselves up. I can't enable that on the clients (various mail readers) or, apparently, on the server configuration. I can't do it in PF because PF just copies packets. I can't seem to do it in relayd either, though that seems the obvious way to intercept the connection for this purpose. Any suggestions? I haven't fully validated my conjecture yet, BTW. It just fits the symptoms I see. Plan B is to build the latest courier-imap from source if I find the time, but there may be no build option for this. I guess a single setsockopt() call in the source would be enough, _if_ that can be done on the accept end, which I haven't checked. Plan B0 might be to disable IMAP IDLE support. Hmm. Cheers, Cameron Simpson
odd ARP problem - arp requests not being made when I expect them
I'm running OpenBSD 6.0 i386 on a Soekris as my local firewall. We had/have a problem with network dropouts on our NBN satellite connection which I believe I've traced to the firewall's ARP entry for the upstream gateway expiring. The problem appears to be that once the ARP entry expires, the firewall does not issue an ARP who-was request to renew the entry. As a consequence packets can't be forwarded to the gateway and it looks like an ISP outage. This state persists for periods of up to 10 minutes. During the "outage" DHCP on the ISP link works (presumably because that doesn't involve the arp table) but pings to the gateway do not, and nor does any other normal IP traffic which requires using the gateway. I left a tcpdump running for the gateway host IP and noticed this morning that immediately after an ARP request occurred and was answered (immediately) that traffic commenced working again, which led to to pursuing this. I don't understand why, since the gateway address doesn't have a current ARP entry, the firewall does not imemdiately issue an ARP request for it. Even a ping directly from the firewall to the gateway address does not cause an ARP request. In case it is relevant, all the through traffic is directed via PF nat-to rules, but I suspect this isn't related because direct ping traffic from the firewall also doesn't work. On the other hand, there's a secondary interface to a 3G modem which doesn't do this, and traffic through that interface is not NATed because the 3G modem does it. Finally, I've done the following to verify the issue: Waited for the ARP entry to expire, and saw throughput cease and direct pings of the gateway from the firewall fail: ping 172.16.20.254 PING 172.16.20.254 (172.16.20.254): 56 data bytes ping: sendto: Host is down ping: wrote 172.16.20.254 64 chars, ret=-1 ping: sendto: Host is down ping: wrote 172.16.20.254 64 chars, ret=-1 I added the ARP entry by hand with the arp command and throughput and pings resumed immediately. I've manually removed the ARP entry and seem identical symptoms, and I've manually added a static ARP entry for the gateway and the connection has been solid for several hours now. Versus "outages" every hour, if not more frequently. I would like to understand this behaviour and to know if it is, as it appears, a bug. Cheers, Cameron Simpson <c...@cskk.id.au>
Re: OpenBSD 4.7 amd64 on IBM x3550 M2 panics at boot
On 19Jul2010 17:08, I wrote: | Full of optimism I have installed OpenBSD 4.7 on a new machine. | The amd64 install CD boots just fine, installs just fine. | After the install, the /bsd kernel panics with a stack trace looking | like this (hand retyped): | [...] | acpiprt5 at acpi0: bus -1 (PCI9) | acpicpu0 at acpi0uvm_fault(0x80c9e980, 0x0, 0, 1) - e | kernel: page fault trap, code=0 | Stopped at acpucpu_getpss_0xbf: movq 0(%rax),%rdi | acpicpu_getpss() at acpicpu_getpss+0xbf | acpicpu_attach() at acpicpu_attach+0x154 | config_attach() at config_attach+0x11b [...] | How do I troubleshoot this? | Is ACPI a problem, and can I avoid that subsystem? | Are there command line options I can supply the booting kernel? Well: boot -c disable acpi and it boots. Post boot: cd / cp bsd bsd.orig config -e -o bsd bsd.orig disable apci quit and I've got a happy unattended boot. Is the ACPI failure because the install kernel deliberately tries to avoid these problematic subsystems? Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ A monkey has the right to copy what he sees other monkeys doing. Shouldn't humans have equivalent rights? - Alien Being http://slashdot.org/~Alien%20Being
OpenBSD 4.7 amd64 on IBM x3550 M2 panics at boot
Full of optimism I have installed OpenBSD 4.7 on a new machine.
The amd64 install CD boots just fine, installs just fine.
After the install, the /bsd kernel panics with a stack trace looking
like this (hand retyped):
[...]
acpiprt5 at acpi0: bus -1 (PCI9)
acpicpu0 at acpi0uvm_fault(0x80c9e980, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at acpucpu_getpss_0xbf: movq 0(%rax),%rdi
acpicpu_getpss() at acpicpu_getpss+0xbf
acpicpu_attach() at acpicpu_attach+0x154
config_attach() at config_attach+0x11b
acpi_add_device() at acpi_add_device+0x95
aml_walknodes() at aml_walknodes+0x6e
aml_walknodes() at aml_walknodes+0x41
aml_walknodes() at aml_walknodes+0x41
acpi_attach() at acpi_attach+0x45d
config_attach() at config_attach+0x11b
bios_attach() at bios_attach+0xb7
end trace frame: 0x80d99d80, count: 0
ddb{0}
and at the ddb prompt the keyboard doesn't work. It's USB only on this
machine.
If it stop the auto boot and boot the /bsd.rd from the monitor it boots
happily, though it then offers an install:-(
How do I troubleshoot this?
Is ACPI a problem, and can I avoid that subsystem?
Are there command line options I can supply the booting kernel?
_Why_ does the install CD install a kernel that doesn't cope with the
machine while the bsd.rd kernel that it also installs obviously does?
Cheers,
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I've watched C-beams glitter in the dark near the
Tannhauser Gate. All these memories will be lost in time, like tears in rain.
- Roy Baty, _Blade Runner_
Re: installing amd64 using i386 to boot then amd64 for install?
On 15Mar2010 23:11, J.C. Roberts list-...@designtools.org wrote: | On Tue, 16 Mar 2010 14:59:01 +1100 Cameron Simpson c...@zip.com.au | wrote: | | I have the apparently common problem of CD2 (amd64) from the OpenBSD | distro not booting on an IBM x336. And of course there's no floppy | and the box won't boot off a USB device at all. | | apparently common ? --Never heard of it. This is the bought amd64+macppc CD2 disc image. It seems common enough for the shipped install instructions to suggest using the floppy image as a boot alternative for this architecture and for me to have tripped over this issue in the past. For what it's worth, I've downloaded the 4.5 amd64 install45.iso image and _it_ boots just fine. I've installed from there now. However, if I use the amd64 disc from the bought distro, it does not boot. I'm presuming its weird and different, perhaps doing something odd in an attempt to also boot on a PPC system? Just guessing. | If there is something wrong with your install media for amd64, then | download the ISO and burn a new copy. | ftp://ftp.openbsd.org/pub/OpenBSD/4.6/amd64/install46.iso | Even better, since we're right next to 4.7 release, install the | most recent -current snapshot: | ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install47.iso | Your subsequent upgrade to 4.7 -release in a month or two will go a lot | more smoothly. I'm actually going with 4.5 to match this machine's partner machine. | One of the avenues I'm considering is booting off the i386 CD1 and | then using the CD2 disc for the install data. Will that work, or will | the i386 install still load up some inappropriate i386 items (eg the | boot sector)? | | Why shoot yourself in the foot? Because I was facing an install on a machine which won't boot off USB, has no floppy and an apparently useless amd64 install CD. Hence my desire to try getting off the ground with the i386 CD. | A better and supported alternative is to netboot the system with | the correct bsd.rd kernel and install the sets via ftp. I'll try to find the time to try out such a setup at home sometime. I was in a co-lo with few resources and some time pressure. I'd like to thank folks for the many replies to my unusual query. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ ep0: 3c509 in test mode. Erase pencil mark! This means that someone has scribbled with pencil in the test area on the card. Erase the pencil mark and reboot. (This is not a joke). - OpenBSD 2.3 ep(4) ethernet drive manual entry
Re: mismatch output net-snmp -current
On 17Apr2009 07:48, uno83 johan.unos...@gmail.com wrote: | Agung T. Apriyanto-2 wrote: | i found mismatch output from snmpwalk in -current net-snmp, sample bellow | | r...@cadangan[patches]# snmpwalk -v 1 -c public localhost | .1.3.6.1.2.1.4.20.1.2 | IP-MIB::ipAdEntIfIndex.10.100.0.1 = INTEGER: 1 | IP-MIB::ipAdEntIfIndex.10.100.66.1 = INTEGER: 5 | IP-MIB::ipAdEntIfIndex.10.100.67.1 = INTEGER: 6 | IP-MIB::ipAdEntIfIndex.10.100.68.1 = INTEGER: 7 | IP-MIB::ipAdEntIfIndex.10.100.69.1 = INTEGER: 8 | IP-MIB::ipAdEntIfIndex.58.145.172.241 = INTEGER: 2 | IP-MIB::ipAdEntIfIndex.127.0.0.1 = INTEGER: 4 | | r...@cadangan[patches]# snmpwalk -v 1 -c public localhost | .1.3.6.1.2.1.2.2.1.3 | IF-MIB::ifType.1 = INTEGER: softwareLoopback(24) | IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.4 = INTEGER: 244 | IF-MIB::ifType.5 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.6 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.7 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.8 = INTEGER: ethernetCsmacd(6) | IF-MIB::ifType.9 = INTEGER: 245 | | interface index 5,6,7,8 have the right ip, but there's a mismatch at | index 1, 2 and 4 of IP-MIB. | | any of you have the same problems ? | | We are seeing the same problem. Me too, using net-snmp on OpenBSD 4.5. How is the base OS snmpd in 4.5? It was insufficient back on 4.3 and I ended up using net-snmp, but we recently added another NIC to the box and now net-snmp reports no interfaces at all:-( Am trying today to upgrade (or re-install) to 4.5 on this box to match our working equivalent box (redundant pair of machine with staggered install times, hence the mismatch), but of course the AMD64 install CD doesn't boot :-( Cheers, -- Cameron Simpson c...@zip.com.au DoD#743
installing amd64 using i386 to boot then amd64 for install?
I have the apparently common problem of CD2 (amd64) from the OpenBSD distro not booting on an IBM x336. And of course there's no floppy and the box won't boot off a USB device at all. One of the avenues I'm considering is booting off the i386 CD1 and then using the CD2 disc for the install data. Will that work, or will the i386 install still load up some inappropriate i386 items (eg the boot sector)? Has anyone done this? -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ If you can't make it out of coathanger wire, you just aren't thinking. - John Whitmore
Re: pf beginner: my firewall passes tcp but not icmp
On 04Nov2005 07:52, Ryan McBride [EMAIL PROTECTED] wrote: | On Fri, Nov 04, 2005 at 05:16:22PM +1100, Cameron Simpson wrote: | [var/[EMAIL PROTECTED] pfctl -s rules | block return all | pass quick proto tcp from any to any port = ssh flags S/SA keep state | pass in quick proto icmp all keep state | ^^ | How are the packets supposed to get OUT of the firewall? You have to | think of the traffic crossing both interfaces. I was imagining the keep state stuff handled that. So - for my mental model - a packet being forwarded traverses the rules twice: once on the way in and once on the way out? My original attempt was stateless - I just wanted echoreq and echoreply to have free passage, and so it had no directions or state. | (I have also tried pass quick proto icmp all with no useful effect.) | | With the simple ruleset above, or something more complicated? The latter. I'll try some more systematic experiments now. | This should work (as should the above without the direction) Ok. | Also, I have seen elsewhere in list archives debug output showing what rules | got applied. I have not found out how to produce such debugging myself. | | Add the 'log' keyword to at least your block rule, and maybe your pass | rules as well. Then do: | | # tcpdump -vvvpleni pflog0 -s 1518 Ah. I'd been trying without the -s and getting data format complaints. | I'm loading up the rules like this: | pfctl -F rules -v pfctl -xm -f /etc/pf.conf -v echo YES | | Don't explicitly flush the ruleset like this, pf does that for you and | with such a command you're running without any ruleset at all for at | least a moment, more if your new ruleset is buggy and fails to load. Indeed. The pf -F was again my growing paranoia. The pfctl man page seemed to suggest the flush was automatic, since there were options to not flush things, but wasn't explicit in the positive. So I was just trying to ensure I really was discarding the old set of rules entirely. Glad to know it's wasteful and dangerous. | What else can I do to further debug this? | | tcpdump on the pflog interface is probably the most powerful tool; you | can also look at pfctl -si to see if packets are being dropped for some | other reason than ruleset evaluation, and perhaps do tcpdump on the | physical interfaces you think the traffic should be crossing, to see if | it's maybe actually coming out on the other side but being dropped | elsewhere on your network. Well I'd reduced my test to pinging the firewall itself. An earlier tcpdump was showing pings coming in and no replies. Would that imply pings arriving and being dropped, and thus no replies attempted by the OS? Anyway, I'll proceed not with better debugging and return with a diagnosis or at least more data:-( Thanks! -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ Hello, my name is Yog-Sothoth, and I'll be your eldritch horror today. - Heather Keith [EMAIL PROTECTED]
Re: pf beginner: my firewall passes tcp but not icmp
I'm an idiot. I was pinging with some ip-options set (route tracking) and pf was dropping packets with such options. Not the rules at all. Thanks for the help! -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ alt.skunks A newsgroup for enthusiasts of skunks and other mustelidae.
pf beginner: my firewall passes tcp but not icmp
I'm setting up an OpenBSD 3.7 firewall for the first time. I've been flailing at this all afternoon and have exhausted my ideas. My ruleset looks like this (from pfctl -s rules): [var/[EMAIL PROTECTED] pfctl -s rules block return all pass quick proto tcp from any to any port = ssh flags S/SA keep state pass in quick proto icmp all keep state It was more complex, but this is as simple as I can get it and demo the problem. (I have also tried pass quick proto icmp all with no useful effect.) With these rules in place and enabled, existing ssh sessions continue thanks to their kept state, and new ssh connections work also. However my pings, which work fine with pf disabled, get nothing back when I enable pf (pfctl -e) and of course spring back into life with pfctl -d. Does anyone have any idea what I'm doing wrong here? Also, I have seen elsewhere in list archives debug output showing what rules got applied. I have not found out how to produce such debugging myself. I'm loading up the rules like this: pfctl -F rules -v pfctl -xm -f /etc/pf.conf -v echo YES What else can I do to further debug this? -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ What the hell, it's only 4 month's grant - I can live in a cardboard box, and catch pigeons for food. After all, I've got raytracing to do! - [EMAIL PROTECTED]
