Re: ndp for ND (ipv6) proxying on /64 prefix is failing cryptically.
When I was with Vultr—keyword there being “was”—I simply set up NAT66 for Wireguard to work. I believe that if you want NDP proxying to work you need something like ndppd (https://github.com/DanielAdolfsson/ndppd). Personally, depending on how big of an IPv6 “snob” you are, I would leave Vultr for another VPS/dedicated-server provider that “does IPv6 correctly". While there are some well-respected people in the OpenBSD community—most notably Henning Brauer—that are not big fans of IPv6, I personally find it to be MUCH better than IPv4. To me NDP proxying and NAT are hacks that should be avoided when you can. IETF recommends (https://datatracker.ietf.org/doc/html/rfc6177) /48 or at least /56 prefixes to be routed to end sites for the purpose of subnetting (e.g., for VPNs), so the fact the Vultr gives out /64s is annoying to say the least. I mean even my residential ISP, Comcast/Xfinity, is willing to give out /60s. I really liked Vultr when I was a customer, but I was too big of a “snob” so I ended up leaving them. I made sure to inform them that I am leaving purely because they only route /64s; and that if they ever changed that, I would seriously consider coming back. While I am sure there are other providers out there that provide more than /64s, I ended up going with a company called ARP Networks. They only have two locations: one in Los Angeles, CA and one in Frankfurt, Germany. They also don’t have nearly as nice of a GUI, but I have been very happy with them. They give you a static /48 when requested. It is also super easy to set up pointer records for both IPv6 and IPv4.
Re: TCP FIN hangups in encrypted ESP tunnel
Hi, not sure if related but my Linux box (also in Hetzner) also started to have flaky connection lately. -- Regards, Ville On Wed 7. Jul 2021 at 19.58, Peter J. Philipp wrote: > Hi, > > My VPS at Hetzner has very weird behaviour: > > last week it started hanging up scp'ing of large backups, so I worked hard > to > get these encrypted if it was a hangup attack. Well surprise to me too the > hangups are back. I have tcpdump'ed the enc0 from both sides and the FIN > does originate from the Hetzner VPS. It's inside the secure channel but I > did not activate it knowingly. Even a ktrace does not show much, no > signal, > no close(), no shutdown(). The connection just drops on FIN and resulting > RST's. Here is a catpure of the FIN: > > seen from pod: > > 18:02:59.040443 (authentic,confidential): SPI 0xf2d38877: > 2a01:4f8:c010:71dd::1 > 2003:a:60f:ce01::108: 2a01:4f8:c010:71dd::1.1022 > > 2003:a:60f:ce01::108.40358: FP [tcp sum ok] 45961186:45962414(1228) ack > 15902 win 268 [class 0x20] > [flowlabel 0x3fceb] (len 1260, hlim 64) [class 0x20] (len 1300, hlim 64) > > seen from arda: > > 18:02:59.064240 (authentic,confidential): SPI 0xf2d38877: > 2a01:4f8:c010:71dd::1 > 2003:a:60f:ce01::108: 2a01:4f8:c010:71dd::1.1022 > > 2003:a:60f:ce01::108.40358: FP [tcp sum ok] 45961186:45962414(1228) ack > 15902 win 268 [class 0x20] > [flowlabel 0x3fceb] (len 1260, hlim 64) (len 1300, hlim 55) > > The download downloads a few MB and then it hangs up. > > Has anyone seen this sort of behaviour? I don't think I changed much in my > pf rules because up until last month backups downloaded flawlessly. Here > is > my dmesg (after my signature): > > Best Regards, > -peter > > > OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun 7 08:21:26 MDT 2021 > r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > GENERIC.MP > real mem = 2080227328 (1983MB) > avail mem = 2001866752 (1909MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b10 (9 entries) > bios0: vendor Hetzner version "2017" date 11/11/2017 > bios0: Hetzner vServer > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC HPET MCFG > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD EPYC Processor (with IBPB), 2495.71 MHz, 17-01-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1 > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 1000MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD EPYC Processor (with IBPB), 2495.40 MHz, 17-01-02 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1 > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu1: smt 0, core 0, package 1 > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 1 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xb000, bus 0-255 > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > "APP0005" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > acpicpu1 at acpi0: C1(@1 halt!) > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 > vga1 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci1
TCP FIN hangups in encrypted ESP tunnel
Hi, My VPS at Hetzner has very weird behaviour: last week it started hanging up scp'ing of large backups, so I worked hard to get these encrypted if it was a hangup attack. Well surprise to me too the hangups are back. I have tcpdump'ed the enc0 from both sides and the FIN does originate from the Hetzner VPS. It's inside the secure channel but I did not activate it knowingly. Even a ktrace does not show much, no signal, no close(), no shutdown(). The connection just drops on FIN and resulting RST's. Here is a catpure of the FIN: seen from pod: 18:02:59.040443 (authentic,confidential): SPI 0xf2d38877: 2a01:4f8:c010:71dd::1 > 2003:a:60f:ce01::108: 2a01:4f8:c010:71dd::1.1022 > 2003:a:60f:ce01::108.40358: FP [tcp sum ok] 45961186:45962414(1228) ack 15902 win 268 [class 0x20] [flowlabel 0x3fceb] (len 1260, hlim 64) [class 0x20] (len 1300, hlim 64) seen from arda: 18:02:59.064240 (authentic,confidential): SPI 0xf2d38877: 2a01:4f8:c010:71dd::1 > 2003:a:60f:ce01::108: 2a01:4f8:c010:71dd::1.1022 > 2003:a:60f:ce01::108.40358: FP [tcp sum ok] 45961186:45962414(1228) ack 15902 win 268 [class 0x20] [flowlabel 0x3fceb] (len 1260, hlim 64) (len 1300, hlim 55) The download downloads a few MB and then it hangs up. Has anyone seen this sort of behaviour? I don't think I changed much in my pf rules because up until last month backups downloaded flawlessly. Here is my dmesg (after my signature): Best Regards, -peter OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun 7 08:21:26 MDT 2021 r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2080227328 (1983MB) avail mem = 2001866752 (1909MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b10 (9 entries) bios0: vendor Hetzner version "2017" date 11/11/2017 bios0: Hetzner vServer acpi0 at bios0: ACPI 3.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC Processor (with IBPB), 2495.71 MHz, 17-01-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1 cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC Processor (with IBPB), 2495.40 MHz, 17-01-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1 cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: smt 0, core 0, package 1 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "APP0005" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 96:00:00:a5:ca:09 virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int 22, xH
Re: pkg_add multiple package install weird output
I have another instance of this, maybe someone can look if it really is of interest. Somehow, the current package name is messed up. geda-0.1p1:gerbv-2.7.0p0: 184/194 geda-0.1p1:tcl-8.5.19p4: 185/199 geda-0.1p1:tk-8.5.19p1: 186/199 geda-0.1p1:gtkglext-1.2.0.20191219: 187/199 geda-0.1p1:gd-2.3.2: 188/199 geda-0.1p1:libsigsegv-2.12: 189/200 geda-0.1p1:m4-1.4.18p1: 190/200 geda-0.1p1:pcb-4.3.0v0: 191/200 geda-0.1p1:gnucap-0.35p9: 192/200 geda-0.1p1:iverilog-11.0p0: 193/200 geda-0.1p1:gtkwave-3.3.108: 194/200 geda-0.1p1:slib-3b4p0: 195/202 geda-0.1p1:guile-1.8.8p9: 196/202 geda-0.1p1:geda-gaf-1.6.0p21: 197/202 geda-0.1p1:ngspice-31: 198/202 geda-0.1p1: 199/202 qucs-s-0.0.22p0:qt4-4.8.7p25: 200/203 qucs-s-0.0.22p0: 201/203 avr-0.1p0:avr-binutils-2.30: 202/209 avr-0.1p0:libmpc-1.1.0: 203/210 avr-0.1p0:avr-gcc-5.4.0p3: 204/210 avr-0.1p0:avr-libc-2.0.0: 205/210 avr-0.1p0:libconfuse-3.2.2: 206/214 avr-0.1p0:libusb1-1.0.23p2: 207/214 avr-0.1p0:libftdi1-1.5: 208/214 avr-0.1p0:libusb-compat-0.1.5p0: 209/214 avr-0.1p0:avrdude-6.3: 210/214 avr-0.1p0:arduino-1.8.10v0: 211/214 avr-0.1p0:avr-gdb-6.8p10: 212/214 geda-0.1p1:simulavr-0.1.2.7p0: 213/214 ^^^ here is invoked another package name avr-0.1p0: 213/214 Old post included: > Hello, I use to run pkg_add with multiple package names, something like: pkg_add -vV gimp libreoffice geeqie audacity inkscape vlc mupdf I am sure gimp is ahead of vlc in the command line. I saw something strange in output: [ ... ] gimp-2.10.22p1:aalib-1.4p7: 63/78 gimp-2.10.22p1:OpenEXR-2.5.4: 64/78 gimp-2.10.22p1:py3-cairo-1.20.0p0: 65/81 gimp-2.10.22p1:py3-gobject3-3.38.0p1: 66/81 gimp-2.10.22p1:exiv2-0.27.2v0: 67/81 gimp-2.10.22p1:libgexiv2-0.12.1p2: 68/81 gimp-2.10.22p1: 69/81 ^ < gimp finish [ ... ] inkscape-1.0.1p0:aspell-0.60.6.1p10: 151/160 inkscape-1.0.1p0:liberation-fonts-2.00.1p1: 152/160 inkscape-1.0.1p0:potrace-1.16: 153/160 inkscape-1.0.1p0:double-conversion-3.1.5: 154/160 inkscape-1.0.1p0:gcc-libs-8.4.0p1: 155/164 inkscape-1.0.1p0:blas-3.8.0p0: 156/164 inkscape-1.0.1p0:lapack-3.8.0p1: 157/164 inkscape-1.0.1p0:cblas-1.0p7: 158/164 inkscape-1.0.1p0:py3-numpy-1.16.5p1: 159/164 inkscape-1.0.1p0: 160/164 vlc-3.0.11.1p0:libcddb-1.3.2p0: 161/184 vlc-3.0.11.1p0:sdl-1.2.15p10: 162/184 vlc-3.0.11.1p0:libtar-1.2.20: 163/184 vlc-3.0.11.1p0:libnfs-4.0.0: 164/184 vlc-3.0.11.1p0:libebml-1.4.0: 165/184 vlc-3.0.11.1p0:libdvdcss-1.4.2p1: 166/185 vlc-3.0.11.1p0:libdvdread-6.1.1: 167/185 vlc-3.0.11.1p0:dbus-glib-0.110p1v0: 168/189 vlc-3.0.11.1p0:geoclue-0.12.99p9: 169/189 vlc-3.0.11.1p0:libxkbcommon-1.0.3: 170/189 vlc-3.0.11.1p0:pcre2-10.35: 171/189 gimp-2.10.22p1:iodbc-3.52.12p1: 172/189 ^ vlc-3.0.11.1p0:qtbase-5.13.2p0: 172/189 vlc-3.0.11.1p0:qtsvg-5.13.2: 173/189 vlc-3.0.11.1p0:libsmb2-3.0.0: 174/189 vlc-3.0.11.1p0:libdvdnav-6.1.0v0: 175/189 vlc-3.0.11.1p0:libplacebo-2.72.2: 176/189 vlc-3.0.11.1p0:qtx11extras-5.13.2: 177/189 vlc-3.0.11.1p0:libdvbpsi-1.3.3: 178/189 vlc-3.0.11.1p0:libb2-0.98.1v0: 179/190 vlc-3.0.11.1p0:libarchive-3.5.1: 180/190 vlc-3.0.11.1p0:sdl-image-1.2.12p4: 181/190 vlc-3.0.11.1p0:libbluray-1.2.1: 182/190 vlc-3.0.11.1p0:libidn-1.36: 183/190 vlc-3.0.11.1p0:protobuf-3.13.0: 184/190 vlc-3.0.11.1p0:taglib-1.11.1p3: 185/190 vlc-3.0.11.1p0:libmatroska-1.6.2: 186/190 vlc-3.0.11.1p0: 187/190 [ ... ] Long after gimp install finish, there is an entry about gimp in the middle of vlc install. Is this fine? <
ndp for ND (ipv6) proxying on /64 prefix is failing cryptically.
Hello, everyone I am running an OpenBSD 6.9 Vultr node. Vultr is issuing /64 prefixes with SLAAC. I have a few machines behind this node, connected via wireguard. For simplicity, let us say that vio0 is the default interface, configured the way Vultr suggests: hostname.vio0 dhcp inet6 autoconf -temporary -soii wireguard is configured like this: hostname.wg0 inet6 128 !/usr/local/bin/wg setconf wg0 /etc/wireguard/server.conf from the outside I cannot pint , the response being 2401:c080:1c00:a4::33 icmp_seq=3 Destination unreachable: Address unreachable If my understanding is correct, that is because wg0 cannot respond to ND requests from the router. Trying to set up proxy NDP, I am running ndp like thi: ndp -s temp proxy If I understand correctly, this should make "vio0" announce the static ip to the router. (the words "temp" and "proxy" seem to have no effect) However, ndp errs: ndp: set: cannot configure a new entry There seems to have been a similar error in 2008: http://openbsd-archive.7691.n7.nabble.com/error-with-ndp-only-on-sparc64-td200752.html and https://marc.info/?l=openbsd-ipv6&m=120731349004033&w=2 sysctl: net.inet6.ip6.forwarding=1 but net.inet6.ip6.accept_rtadv=0 seems to have disappeared. What is it that I am doing wrong? The nabble message mentions some bug in ndp, but it should have disappeared long ago. Perhaps, an FAQ entry related to ndp would be nice to have? Ipv6 is supposed to have the adoption rate of 33%, not such an uncommon thing any more. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
PF annoying messages
HI All, 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 Then some rules are used to pass the authorized packets. One of the rule is pass from to pass from to where the table "multicast" contains all the multicast address and the table "TV_nets" the networks used for IT TV. In the log regularly the following message is produced: Jul 07 10:44:40.049159 rule 26/(match) pass in on vlan120: 192.168.88.1 > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] where vlan120 is part of an OpenBSD bridge used in egress part of the firewall. A lot of similar rules (many vlan are used) and some other pass rules are defined but only this one (26) produces a message. Is it possible to remove a such message? The message is not useful and it clutters the log. Thanks for your help,
