Re: IPsec "road warrior" VPN not getting set up properly.
Summary of this email: 1. I respond to a couple of specific points made by other folks in this thread to clarify what I'm trying to accomplish (set up a couple of ad hoc link-local routes without having to ask my ISP for a larger subnet) and to acknowledge that I said something stupid about pings. 2. I abandon my quest to get NDP proxying added to iked and instead ask if we can add a "rtlabel" keyword to iked.conf to make it easier for me to write a separate process that monitors the routing table to detect when the tunnel gets set up. 3. I ask three questions about the intended uses of routing labels, the purpose of iked's "cloned routes," and the viability of a routing socket that checks your privileges at the time it is opened instead of the time it is used. 4. I provide a first draft of a patch which adds that "rtlabel" keyword. === Part I. Responding to the discussion === Andy Bradford wrote: >> I would also suggest comparing the "hackiness" of NDP proxying to the >> hackiness of NAT, which is how we solve this same problem in IPv4. > > I realize I'm coming in late to this discussion, and may not actually > have anything of value to add, but... > > I'm not sure how NDP proxying and NAT are related at all. I seems to > me that NDP proxying is more akin to proxy ARP than NAT: > > http://man.openbsd.org/arp#s They are related in that they are solutions to similar problems. In IPv4 we use NAT to deal with the shortage of IP addresses. In IPv6 we can use NDP proxying to deal with a local shortage of IPv6 subnets. My purpose in writing the line you quoted was to argue that NDP proxying is no more hacky than NAT, and the rest of the email tried to argue that it was less hacky. Zack Newman, at least, disagrees, and nobody jumped to defend my position. So OK, I will settle for calling them equally hacky. My goal in this discussion was to either convince someone that adding automatic NDP proxying to iked was a good idea, or to at least get agreement that it isn't a bad idea so that they would accept the code if I wrote it myself. I failed in both of these objectives. But that's why it matters to me whether NDP proxying is considered hacky or not. If it's hacky, then the iked maintainers will reject a patch that adds the ndp-proxy keyword even if I write it myself. Zack Newman wrote: > Yeah, I don't have the interest to get into it about this; but I find > it (informally) inconsistent to take an ideological stance against NAT > and not have a similar stance against NDP proxying. To this I'll say that my stance against NAT isn't ideological. It's just that NAT is more intrusive than NDP proxying. All NDP proxying does is tell nearby hosts to update their routing tables to do exactly what you want them to do. NAT, on the other hand, rewrites addresses and ports so the packet you send out isn't the packet the other end receives. And I'm not saying that people shouldn't use NAT for IPv4. I just think that in the IPv6 case, if getting more subnets isn't an easy affair, NDP proxying is a less-intrusive hack to get your VPN client's traffic routed properly than NAT is, and as such, setting it up ought to be as convenient and hassle-free as adding rules to pf. > Also not sure where you heard that ICMP does not work with NAT. Surely > you don't believe that. Go ahead and use ping(8) on any device that > relies on NAT to talk to the outside world and witness how it > "magically" works. ICMP uses the Query ID in lieu of a port number. Yikes, I wasn't thinking clearly. While it's true that an external host can't ping the NATted host (it can only ping the server which is doing the NAT), that isn't the gist of what I claimed. Yes, you are correct. > Will NDP proxying work? Depending on what you want, sure just like NAT > will likely work. Relying on a simple routing table is far more ideal. > NDP proxying is also vulnerable to NDP cache DoS. You can use your > favorite search engine to learn why NDP proxying is not as good as > simple routes. Thanks for the specific example. I looked into this and it seems that my use case might be misunderstood. The NDP cache DoS depends on a setup similar to what the "nd-reflector" project (linked to in a previous email in this thread) provides: NDP-proxying an entire subnet instead of just the one host in question. Under these circumstances, an attacker can fill the router's NDP cache with a bunch of incorrectly-proxied addresses that don't actually point to anything, just by trying to hit a bunch of random addresses in the subnet and tricking the NDP proxy into responding to all of them. The use case I have in mind is to only proxy an address when it is allocated to a client that has connected to the VPN, and to stop proxying that address when the client disconnects. That's why I thought it was something iked ought to be able to do: when the client connects to iked, iked knows what address it assigned the client so it can automatically add
Re: `pkg_add -u` and caching
On Sun, Jul 9, 2023 at 11:11 Morgan Aldridge wrote: > Hi misc@ and Marc, > > I have a script for applying all updates/upgrades for upgrading my OpenBSD > workstation, dev machines, and servers. I'm currently in the process of > improving it to better support downloading pending updates in advance of > actual review and installation (see < > https://github.com/morgant/swupdate-openbsd/issues/14>. I've been > studying the pkg_add(1) manual, testing, and also reviewing the pkg_add > Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well > structured and easy to read, the latter does take me longer to grok than > the former. > > I'm hoping you have a quick answer (even if it's 'no') to the following > question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n` > option? > > In my testing (on amd64/7.3-stable), the following will check for updates > and copy packages to `PKG_CACHE`, as described in pkg_add(1): > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu > > If I delete a cached package from the PKG_CACHE directory, re-executing > the above command will redownload the package. That's what I was hoping > for. I'm not quite sure whether some of the packages are being > re-downloaded by just looking at file modification dates (unfortunately, > `-v` doesn't note downloads, nor cache mis/hit.) > > The following seems to try to update packages from PKG_CACHE, if passed in > as PKG_PATH, but -- understandably -- does result in errors that some > packages (those that didn't need updates or have dependencies that did) > could not be found: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u > > Naturally, if I append ':installpath' to the above PKG_PATH, it will not > give such errors: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u > > However, since '-v' also doesn't note which package repository (esp. > local or not) a package was processed from, I don't know whether it's > actually preferring the local repository. > > Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it > doesn't appear that packages are downloaded to PKG_CACHE: > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 > /home/_swupdate/7.3/packages/amd64 > pkg_add -u > Typo. The above command should have been: PKG_CACHE=/home/_swupdate/7.3/packages/amd64 \ PKG_PATH=/home/_swupdate/7.3/packages/amd64 \ pkg_add -u This is confirmed by deleting a package from PKG_CACHE and re-executing the > above, after which the deleted package is still missing from PKG_CACHE. Of > course, this absolutely feels sketchy to be caching to a package > repository, but was worth a try. > Thanks in advance and please CC me if replying to the list as I'm not subscribed to misc@. Morgan > -- Morgan --- http://makkintosshu.com/ https://centresteer.com/ https://tobuji.tech/ http://unna.org/
Re: Restart of syslogd every three hours ?
On 2023-07-05 05:12, Stuart Henderson wrote: On 2023-07-04, J Doe wrote: Hi, I have a question about an OpenBSD 7.3 host that has syspatches up to today (July 4, 2023). I noticed in: /var/log/messages that the: syslogd process is restarting every three hours: /var/log/messages Jun 18 11:00:01 server syslogd[83783]: restart Jun 18 14:00:01 server syslogd[83783]: restart . . . I checked: man syslogd and looked at the cron tabs on the system and there doesn't appear to be anything related to the restarts. newsyslog signals syslogd with a HUP when rotating logs. Hi Ricky and Stuart, Thank you for your replies. Ok, this definitely gives me some clues to work with. - J
Re: Intel DRM error on T 440
On Sat, Jul 8, 2023, at 20:39, Nick Holland wrote: > I believe what you are seeing is an informative message about what is > going on under the covers, not an problem you (as a user) need to > deal with if everything is working as it should be. However, if things > are NOT working as they should, Nick: Thanks! In all other respects OpenBSD 7.3 is working flawlessly. I Googled and this problem also occurs on Linux computers too. -- Kind regards, Jonathan
`pkg_add -u` and caching
Hi misc@ and Marc, I have a script for applying all updates/upgrades for upgrading my OpenBSD workstation, dev machines, and servers. I'm currently in the process of improving it to better support downloading pending updates in advance of actual review and installation (see < https://github.com/morgant/swupdate-openbsd/issues/14>. I've been studying the pkg_add(1) manual, testing, and also reviewing the pkg_add Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well structured and easy to read, the latter does take me longer to grok than the former. I'm hoping you have a quick answer (even if it's 'no') to the following question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n` option? In my testing (on amd64/7.3-stable), the following will check for updates and copy packages to `PKG_CACHE`, as described in pkg_add(1): PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu If I delete a cached package from the PKG_CACHE directory, re-executing the above command will redownload the package. That's what I was hoping for. I'm not quite sure whether some of the packages are being re-downloaded by just looking at file modification dates (unfortunately, `-v` doesn't note downloads, nor cache mis/hit.) The following seems to try to update packages from PKG_CACHE, if passed in as PKG_PATH, but -- understandably -- does result in errors that some packages (those that didn't need updates or have dependencies that did) could not be found: PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u Naturally, if I append ':installpath' to the above PKG_PATH, it will not give such errors: PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u However, since '-v' also doesn't note which package repository (esp. local or not) a package was processed from, I don't know whether it's actually preferring the local repository. Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it doesn't appear that packages are downloaded to PKG_CACHE: PKG_CACHE=/home/_swupdate/7.3/packages/amd64 /home/_swupdate/7.3/packages/amd64 pkg_add -u This is confirmed by deleting a package from PKG_CACHE and re-executing the above, after which the deleted package is still missing from PKG_CACHE. Of course, this absolutely feels sketchy to be caching to a package repository, but was worth a try. Thanks in advance, Morgan -- Morgan --- http://makkintosshu.com/ https://centresteer.com/ https://tobuji.tech/ http://unna.org/
