Re: recommendations for web hosting in Canada?
Hi, Small town British Columbia here... I know it's not what you are asking, but... I have a Telus business plan (fiber) which gives me 2 static IP addresses and host it myself. You can't do it on a "Residential" because some of the ports are filtered. I had a huge battle with Telus over this and the only resolution was to get a business plan that "allows" me to run servers :( A UPS and things are amazing. Web (https via acme), email, nextcloud, etc. I'm using a simple fanless system with a Canadian source (https://ca.protectli.com/vault-2-port/) If you have any questions, don't hesitate to reach out to me. Cheers, Steve W. On 06/07/2023 10:31 p.m., Jonathan Thornburg wrote: I'm looking for a web hosting provider based in Canada. Performance isn't critical (the websites will be relatively small, static, and low-traffic), but I'd like a firm whose customer support doesn't core-dump if I mention Perl or OpenBSD. Any recommendations? Thanks,
recommendations for web hosting in Canada?
I'm looking for a web hosting provider based in Canada. Performance isn't critical (the websites will be relatively small, static, and low-traffic), but I'd like a firm whose customer support doesn't core-dump if I mention Perl or OpenBSD. Any recommendations? Thanks, -- -- "Jonathan Thornburg [remove -color to reply]" currently on the west coast of Canada "!07/11 PDP a ni deppart m'I !pleH" -- slashdot.org page footer, 2022-10-16 "eHpl !'I mrtpaep dnia P PD1 /107" -- slightly more plausible message given the PDP-11's little-endian byte order
Re: IPsec "road warrior" VPN not getting set up properly.
> veering slightly from the topic (typical setup for a server host would > not be to use DHCPv6 but just statically route another block - usually a > /56 or /48), but... I don't doubt this is typical for serious network operators. But I would counter that for every user who is in a position to request a statically-routed /48 there are dozens if not hundreds of us who have one /64 at home and another /64 on each of our VPSes. > (to request a prefix be routed to you, you need a DHCPv6-PD client, > not a server) Oops, correct. I was thinking "DHCPv6 daemon" when I typed it. The point is that configuring all those subnets and static routes is an awful lot of extra work when all I want to do is set up a VPN proxy. > why when people are looking for dhcpv6 software do they always find that > unmaintained-for-years run-the-whole-lot-as-root wide-dhcp6 thing? > > use dhcpcd if you want a client that can do DHCPv6. the most recent release > was a couple of months ago, it's sensibly written, uses pledge where possible, > and has decent privilege separation for the parts which can't pledge). Noted. I'm betting the reason people keep finding wide-dhcpv6 is that it is the only result for "pkg_info -Q dhcpv6". I used to search package descriptions at https://openports.se but that site is now defunct. It would be great if pkg_info could search descriptions as well as names, but so far none of the ideas that I think would be great hold much appeal to anyone else. > picking one other bit.. > >> 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. > > it might be how some people solve it for v4. others solve it in a non-hacky > way which is exactly the same as the non-hacky way for v6; put the vpn clients > on a different subnet that's routed to the vpn gateway. I would note here that "some people" includes the OpenBSD FAQ. See: https://www.openbsd.org/faq/faq17.html#clientikev2 In any event, most of us can't readily get extra publically-routable IPv4 subnets. According to Google a /24 costs about $9000 right now. I could make do with a /28 since I only really want to connect three servers at a time, but how do I get the /28 routed to my server? Either I track down an ISP that provides these directly or else I have to set up BGP. All this to connect my laptop to a VPN proxy server! Most people use NAT for IPv4 because that's all most people can afford. Maybe I'm missing something here. Why is NDP proxying considered so distasteful? Can it cause technical problems down the road? I can see how cycling the client through temporary addresses gets complicated and has a lot of moving parts, but NDP proxying involves making a change to the routing table (which iked already has to do whenever VPN clients connect and disconnect) and its only effect (as I understand it) is announcing to nodes on the local link that the VPN tunnel host is a suitable destination for the address in question. Consider the laptop-connecting-to-home-VPN-from-coffee-shop use case. Suppose my home network is a /56 and I allocate a /64 for address assignments to VPN clients like that laptop. Now: how do I make sure that traffic on my local network which is destined for the laptop actually gets sent to the laptop? Am I supposed to configure static routes on all of the nodes on my home network that the laptop might want to communicate with? That doesn't sound right. I'm guessing the right way to advertise an entire subnet is with router advertisement messages, so I would want to configure rad to support this. But that's still a whole other thing to configure. So instead of using neighbor advertisements to direct two or three addresses at a time to the VPN proxy host, I'm using router advertisements to direct a whole subnet to it---which seems reasonable if I could justify the hassle of getting that whole subnet configured and advertised properly, but again, that's a *lot* of trouble. I recognize that there are other ways to get my individual use case to work without requesting changes to iked. If I don't expect to have more than 16 simultaneous connections, I could constrain iked to allocate addresses from a /124 subnet and add those 16 addresses to the NDP proxy list at server startup to get the equivalent of static routing while still not having to reconfigure the ISP's (or hypervisor's) router. But I would consider *that* to be hackier, because now I really am using NDP to advertise a subnet instead of just advertising the addresses that are actually in use. The other option I have on the table is a shell script that runs as a daemon with root privileges, monitors /var/log/daemon for IKEv2 connection and disconnection events, and runs ndp -s and ndp -d appropriately. But if you thought wide-dhcpv6 was bad for not being privilege separated, you'd hate my shell script. And I would too! That's the point. This is something iked could do automatically. I'm
Re: IPsec "road warrior" VPN not getting set up properly.
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. Networking is a lot cleaner when it can be reasoned about with a rudimentary grasp of graph theory where a network can roughly be seen as a complete graph and a node belonging to multiple complete graphs represents a destination in a routing table. It is not challenging at all to use route(8) to subnet from a routed /48 or /56. How many subnets you want is up to you. If you want to only carve out a single /64 for all your hosts, then do so. You can then avoid DHCPv6 altogether and use rad(8) to send routing advertisements allowing clients to use SLAAC which is the much more popular way for clients to automatically configure IPv6 addresses. 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. 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. If you want to use NAT or NDP proxying, then be my guest. It is one thing to not be willing to leave your ISP because you likely don't have many to choose from, but that is not the case for VPS providers. Challenge: reach out to the maintainers of popular NDP proxying daemons and inquire if they think NDP proxying is "clean" when compared to a simple routing table. In NDP proxying a host is responsible for responding to Neighbor Solicitation messages for IPs that don't belong to it. Hm, sounds a lot like NAT where a host uses its IP to masquerade the IPs of other hosts as opposed to traffic being handled by the actual host it was intended for.
Re: IPsec "road warrior" VPN not getting set up properly.
veering slightly from the topic (typical setup for a server host would not be to use DHCPv6 but just statically route another block - usually a /56 or /48), but... On 2023-07-07, Anthony Coulter wrote: > The trouble with subnets is that they have to be configured. I would > have to install a DHCPv6 server to request that subnet. OpenBSD doesn't > have one in base so I have to install the wide-dhcp6 package. (to request a prefix be routed to you, you need a DHCPv6-PD client, not a server) why when people are looking for dhcpv6 software do they always find that unmaintained-for-years run-the-whole-lot-as-root wide-dhcp6 thing? use dhcpcd if you want a client that can do DHCPv6. the most recent release was a couple of months ago, it's sensibly written, uses pledge where possible, and has decent privilege separation for the parts which can't pledge). picking one other bit.. > 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. it might be how some people solve it for v4. others solve it in a non-hacky way which is exactly the same as the non-hacky way for v6; put the vpn clients on a different subnet that's routed to the vpn gateway.
Re: IPsec "road warrior" VPN not getting set up properly.
Summary of this email: I repeat my argument that automatic NDP proxying is the right way to handle the "road warrior" use case for IPv6. The reasons I'm pushing this so hard are that (1) including this functionality in iked would be much more robust than any hacky script I could write that tries to monitor routing state changes, and (2) both of the responses to my routing question claim that the correct way to connect a laptop to my VPN is to negotiate with my ISP to get a larger subnet which just sounds bonkers when "ndp -s" solves the technical problem so perfectly. Then I repeat my offer to fund this solution. > While I suppose the /64 your VPS provider gives you is "enormous" > compared to IPv4, I don't find such a comparison relevant since IPv6 > and IPv4 are entirely different protocols. In fact I actually think it > is small. Why? RFC 6177 (https://datatracker.ietf.org/doc/html/rfc6177) > recommends that /48 or at least /56 subnets be given to end sites, so > your _small_ /64 violates that recommendation. Hell, even my lowly > residential ISP, Xfinity/Comcast, gives me a /60. Unfortunately a great > many ISPs and VPS providers violate this. Not sure if it is due to > incompetence where they incorrectly think such allocations are > "wasteful" or what. IPv6 not only restores end-to-end communication the > way IPv4 initially started, but it is designed so that sites have many > _subnets_. This brings me to the next point. The trouble with subnets is that they have to be configured. I would have to install a DHCPv6 server to request that subnet. OpenBSD doesn't have one in base so I have to install the wide-dhcp6 package. Then I have to configure it. Can a host on my home network request a /60 from my ISP's router? Or do I have to replace the ISP's router with my own device in order to make that request? If I replace the ISP's router, I have to provide all the other router functionality, like the firewall and IPv4-style DHCP. Then there is the host on which iked is running: it needs to advertise ownership of this subnet so I have to configure rad properly. This is insane! I'm not trying to sell VPN services to customers; I just want a simple proxy for my desktop, a couple of laptops, and maybe a friend or two. It's the simple sort of low-volume, hobbyist thing that I *could* accomplish with a layer 2 VPN that tunnels entire Ethernet frames to the remote server---but that would also be a huge pain to configure because now I have to set up and configure a bunch of extra tunnel interfaces. The "road warrior" VPN (I hate that name) described in the OpenBSD FAQ is actually really simple to set up. You just have to copy the /etc/iked/local.pub keys into the appropriate places, writing a pair of very short /etc/iked.conf files, and then rcctl enable iked and away we go! Almost. The one thing iked doesn't do is "last-step routing" between the gateway router and the IKEv2 responder. So for IPv4 we also have to enable nat in /etc/pf.conf, and for IPv6 we have to *either* switch from Vultr to a fancier VPS and do a crapton of configuration to set up the subnets, *or* use NDP proxying to advertise that final hop. NDP proxying is simple. It's also elegant. What does it take for the proxied IP address to be globally routable? Three things have to happen: the Internet has to deliver the packet to the IKEv2 responder's gateway router. The gateway router has to send the packet to the IKEv2 responder. And the IKEv2 responder has to send the packet into the IPsec tunnel. The first step (internet to gateway router) is the fundamental job of the Internet and requires no extra work on our part. The last step (pushing the packet into the tunnel) is handled by iked. All that's left is the middle step: getting the packet from a router to a host on the same link. How do we do that? This is the problem NDP was designed to solve. I don't think it's hacky or unclean at all. The responder wants to tell the hosts on the local link that it is the link-layer endpoint for a single destination address that is on the local link's subnet. That's all NDP does: it instructs hosts on the lcoal link to update their local routing tables. It's perfect for this purpose. And it's even *more* perfect because OpenBSD implements this functionality by updating its own internal routing tables, which iked already does. So it would be even *more* simple if iked set up the NDP proxying automatically instead of forcing me to run a script every time I bounce the connection. 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. If we put aside all the political issues around NAT, it's still a really janky process. It only works for TCP and UDP, so you can't send ICMP messages or use any other fancy experimental protocols. You can't listen on ports unless you create specific firewall rules to forward those ports. The server has to maintain per-connection state to rewrite
Re: IPsec "road warrior" VPN not getting set up properly.
First, thank you! The "ndp -s" trick does exactly what I need. (I did not need to consider ndp-reflector.) The rest of this email could be summarized as "That works so perfectly I would pay for someone to make it automatic; meanwhile the other things I asked about were in fact bad ideas and I will stop wishing for them." > What you're actually trying to do here is respond to NDP requests as a > proxy. It's not a clean way to do it (the clean way is "upstream routes > you a subnet"), but some people are trying to do this on cheap services > that are only intended for a single host connection and that's about the > only way. > > In this case you might be able to do it with ndp -s, as the "proxied" > address is down a tunnel and not going to respond to NDP itself anyway, > so it doesn't hit the main problem for arp/ndp proxy in OpenBSD which > is that it answers on all interfaces, you can't tie it to one in > particular. > > (For some other use cases, where you're on a /64 behind an ISP router, > and have other hosts on a different ethernet interface, it looks like > https://github.com/toru-mano/nd-reflector might do the trick). What makes it unclean? (The "ndp -s" trick is simple and works perfectly; I'm trying to understand why it's architecturally bad.) The use case is: - I have a whole /64 subnet. - I cannot easily modify the gateway router on this subnet. - I want to connect a single client to this network over a tunnel that is administered by a host (not the gateway router!) on that network. - I want the client to be assigned a single [dynamic] IPv6 address on the /64 subnet. This address must be globally routable! - IPv4 is explicitly out-of-scope because addresses are hard to come by; I'm fine just using NAT for IPv4. These items describe both my VPS (where the hypervisor has allocated me an entire /64 subnet but only delivers packets to the vio0 interface when their destination addresses can be found among my NDP neighbor advertisements) and my physical network at home (where again the whole /64 is mine, but replacing the ISP-provided router is a nontrivial affair). Since iked already supports dynamic address assignments, that part is noncontroversial. What is needed for this address to be globally routable? The Internet at large already knows how to look at the top 64 bits of an address to figure out what gateway router to deliver the packet to, and if the packet somehow reaches the IKEv2 responder, iked has already set up the routes necessary to push the packet down the tunnel to its final destination. All we're missing is the step between the gateway router and the IKEv2 responder. They're on the same link. What is the proper way to for iked to announce the dynamic IPv6 address to other hosts on the local link? NDP. And it turns out that OpenBSD already has a utility in base that does NDP proxying. It seems like this should be the recommended solution for IPv6. Taking responsibility for routing the whole /64 subnet just to support a couple of IPsec tunnels seems wrong. I'm not trying to bridge networks; I just want to use an IPsec tunnel to proxy traffic from my laptop. The "ndp -s" trick seems simple and elegant, and it does exactly what we need it to and no more. I would go a step further and ask if *this* functionality could be done automatically by iked. I looked at the code in the ndp utility and it appears to work just by writing messages to a kernel routing socket. Seeing as iked *already* writes messages to a routing socket whenever a flow starts or stops, it seems like it would be easy (and architecturally sound) to add an option to tell iked to do the equivalent of calling "ndp -s $client_addr $server_mac proxy" when a client connects and "ndp -d $client_addr" when it disconnects---just treat it like any other routing step. It could be enabled with a configuration option like "ndp-proxy vio0". (The point of the interface name is to free me from the burden of entering the MAC address by hand.) The option would only be valid for connections with a "config address" option where the address is an IPv6 address, because of course that is the address which would be added to the NDP proxy list. I would gladly pay $200 to a developer who can add this functionality to iked. That's one reason I care so much about whether this is really a "clean" solution. If it isn't clean then maybe adding it isn't such a good idea. But to *me* it looks like iked is already responsible for updating routing information to match the currently-active flows, and the code in the ndp utility suggests that from the kernel's point of view, neighbor advertisements are a routing issue controlled through a routing socket. I can automate this process with a script, but I really do think this is the right way to do "road warrior" IPv6 connections. >> So what would be fantastic is if instead of >> putting "config address 2001:db8:2::/64" in the responder's iked.conf, >> I could put "config inet6 autoconf vio0"
dmesg Framework 13, 13th gen
Works: - Touchpad (it sucks, but it works) - Camera - Microphone - WiFi - Ethernet with the Framework Ethernet adapter - HDMI output with the Framework HDMI adapter - DRM - Suspend (zzz) Doesn't work: - Bluetooth (scnr) - Resume ... it comes back to life in that it shows the contents of ttyC0, and will eventually emit warm air. It doesn't react to anything but a hard reset, though. That makes suspend only half as useful :-) Not tested yet: - DP Adapter - micro-SD Adapter I'm booting from the Framework external storage module, which gave me some sync failures for every mounted partition exactly once in a series of unsuccessful attempts at making it suspend *and* resume. Overall nice machine, though! OpenBSD 7.3-current (GENERIC.MP) #1270: Wed Jul 5 21:29:08 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34005487616 (32430MB) avail mem = 32955215872 (31428MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x3efb8000 (54 entries) bios0: vendor INSYDE Corp. version "03.03" date 04/07/2023 bios0: Framework Laptop (13th Gen Intel Core) efi0 at bios0: UEFI 2.8 efi0: INSYDE Corp. rev 0x303 acpi0 at bios0: ACPI 5.3 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT SDEV SSDT TPM2 SSDT LPIT WSMT SSDT SSDT DBGP DBG2 NHLT ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT SSDT SSDT FPDT PHAT ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) XHCI(S4) XDCI(S4) HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 13th Gen Intel(R) Core(TM) i5-1340P, 4590.02 MHz, 06-ba-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE cpu1 at mainbus0: apid 8 (application processor) cpu1: 13th Gen Intel(R) Core(TM) i5-1340P, 4590.14 MHz, 06-ba-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache cpu1: smt 0, core 4, package 0 cpu2 at mainbus0: apid 16 (application processor) cpu2: 13th Gen Intel(R) Core(TM) i5-1340P, 4390.53 MHz, 06-ba-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 8-way L3 cache cpu2: smt 0, core 8, package 0 cpu3 at mainbus0: apid 24 (application processor) cpu3: 13th Gen Intel(R) Core(TM) i5-1340P, 4390.50 MHz, 06-ba-02 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 48KB 64b/line 12-way D-cache,
Re: IPsec "road warrior" VPN not getting set up properly.
While I suppose the /64 your VPS provider gives you is "enormous" compared to IPv4, I don't find such a comparison relevant since IPv6 and IPv4 are entirely different protocols. In fact I actually think it is small. Why? RFC 6177 (https://datatracker.ietf.org/doc/html/rfc6177) recommends that /48 or at least /56 subnets be given to end sites, so your _small_ /64 violates that recommendation. Hell, even my lowly residential ISP, Xfinity/Comcast, gives me a /60. Unfortunately a great many ISPs and VPS providers violate this. Not sure if it is due to incompetence where they incorrectly think such allocations are "wasteful" or what. IPv6 not only restores end-to-end communication the way IPv4 initially started, but it is designed so that sites have many _subnets_. This brings me to the next point. You would like to rely on SLAAC for your VPN peers, but SLAAC will likely not work on anything smaller than /64. Why? Because the first 64 bits of an IPv6 address is designated as the network identifier. You already carved out some IPs from the /64 though which means you have less than /64 to use for SLAAC inside the tunnel. I used to use Vultr; but when they were unwilling to provide something bigger than a /64 in addition to actually routing the entire block, I left them. If you insist on using IPv6 without relying on NAT or NDP proxying, then I recommend you find another provider. What you are trying to do is trivial when IPv6 is done properly. I have a similar setup myself except I use WireGuard, but I'm confident IKEv2/IPSec would be easy to set up as well.
Re: Question regarding pf rules: block in on em0: ...
On 7/6/23 06:14, Why 42? The lists account. wrote:
Hi,
I see that I was not clear enough.
You were not. One of the first things in your initial e-mail was the
following:
"While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen."
Is it a pf problem or not? If it is the case your "scanner" thing
doesn't work with pf disabled and no active rules, then this entire
thread makes no sense as you are focusing on something that is not
relevant.
Next steps. Disable pf _and_ flush the rules. Confirm there are no
active rules with pfctl -s all. Run the following:
tcpdump -ntt -i em0 -w pkts.dat &
Check if your "scanner" thing works.
Case 1: it doesn't work. Reply to this thread closing it due to the
completely irrelevant nature of both its title and content since you
have an entirely separate issue you need to solve first. If you are
unable to figure it out, then start a new thread with a more relevant
title where you only focus on things that matter. The only part of that
thread that should mention pf is how you have it completely disabled,
so you know it is something else. In that thread include the contents
of the tcpdump.
Case 2: it does work. Reply to this thread retracting you false claim
that pf "doesn't seem to the the issue". In that response include the
contents of the tcpdump.
For added clarity, this tcpdump you show is with pf disabled and all
its rules flushed. The tcpdump you showed in the initial e-mail
clearly was with active pf rules.
In the event that you require some form of traffic manipulation (e.g.,
NAT), then obviously you cannot disable pf. In that situation, make
sure your pf.conf rules only contain something similar to the following:
set skip on lo
pass out quick on inet from { :network
:network ... :network } nat-to static-port
pass quick
Re: Question regarding pf rules: block in on em0: ...
On Tue, Jul 04, 2023 at 10:42:39AM -0600, Zack Newman wrote: > ... > I am guessing you didn't flush the rules after disabling pf since > clearly pf rules are still being used. Run pfctl -F all after disabling > pf. Run pfctl -s all to verify there are no active rules. Hi, I see that I was not clear enough. My question is not about how to disable pf, but rather why the packets are see as "in" when coming from my own address, and, why they are blocked i.e. I noticed these block messages being logged when I click "discover/refresh" in simple-scan: Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 255.255.255.255.3289: udp 15 [ttl 1] Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 255.255.255.255.1124: udp 37 [ttl 1] 192.168.178.11 is my OpenBSD desktop (where of is running). I don't understand what I'm seeing here ... 1. Why am I seeing traffic coming _in_ from my own address? Is that not slightly weird? Is it because it is _to_ the .255 broadcast address? 2. And why is it being blocked? Do I have explicitly allow broadcast traffic e.g. with rules to handle broadcast addresses? I don't think I ever considered doing that before ... The more I use pf, the less I seem to understand? Danke im Voraus! Robb.
Re: IPsec "road warrior" VPN not getting set up properly.
On 2023-07-05, Anthony Coulter wrote: > OK, I've sorted out my network issues server but it turns out that I > was misinterpreting the tcpdump output on my VPS. When an external > computer tries to ping my client's virtual IP address, the VPS's > gateway router is *not* forwarding the pings to my server where they > can be shoved into the IPsec tunnel to the client. So it looks like > the iked responder needs to send IPv6 neighbor advertisements for the > allocated address after all. Is there a way to do this? Your simplest options are either to ask upstream to route traffic to you for the whole subnet (this will probably involve adding a new subnet and routing it via the existing address), or NAT traffic so it comes from the address the upstream router is expecting. > I have tried two things so far: > > 1. Manually assign the [randomly allocated] IP address to the >responder's physical network interface so it knows it has ownership >of that address: > > # ifconfig vio0 inet6 alias 2001:db8:2::1234:5678 > > Of course, this breaks the tunnel. When the responder sees packets with > destination 2001:db8:2::1234:5678 it consumes them locally instead of > routing them down the IPsec tunnel. What you're actually trying to do here is respond to NDP requests as a proxy. It's not a clean way to do it (the clean way is "upstream routes you a subnet"), but some people are trying to do this on cheap services that are only intended for a single host connection and that's about the only way. In this case you might be able to do it with ndp -s, as the "proxied" address is down a tunnel and not going to respond to NDP itself anyway, so it doesn't hit the main problem for arp/ndp proxy in OpenBSD which is that it answers on all interfaces, you can't tie it to one in particular. (For some other use cases, where you're on a /64 behind an ISP router, and have other hosts on a different ethernet interface, it looks like https://github.com/toru-mano/nd-reflector might do the trick). > Here is my vision of a perfect world. It's common for IPv6 nodes to > request a new random IPv6 address every couple of hours; OpenBSD's > inet6 autoconf does this by default. There is no shortage of IPv6 > addresses on a LAN, and the process of requesting new ones is pretty > well standardized . On a LAN, yes there's a common way to do it. Not so much over a tunnel though. > So what would be fantastic is if instead of > putting "config address 2001:db8:2::/64" in the responder's iked.conf, > I could put "config inet6 autoconf vio0" instead. Then iked would > make sure that vio0 is using autoconf addresses and, if so, it would > request a new address via SLAAC (preferably randomizing all 64 bits > instead of just the bottom 32 bits like it does right now), assign > that address to the client, configure all the routing, and then would > somehow configure vio0 to claim ownership of that address for > NDP neighbor solicitation purposes, but have the kernel *not* claim > the address for routing purposes. The client config wouldn't change > at all; it would still say "request address any". autoconf privacy addresses require that old addresses stay active so that long-running connections don't die. You're asking hell of a lot from a number of different subsystems, some of which do not have a way to handle this, to make it all work. -- Please keep replies on the mailing list.
