Re: how to debug iked failures?
Finally found a rather awkward workaround: 1) On the VPN GW, set an ip alias from a different subnet (192.168.100.1/24) on the primary interface 2) Set up iked.conf with ikev2 ... from 0.0.0.0/0 to 192.168.100.0/24 config address 192.168.100.0/24 config address 192.168.100.2 (yes, both ...) 3) On the client, configure tunnel mode instead of transport mode, configure remote subnet to be 192.168.100.0/24, but still request ip configuration from IKEv2. When this comes up, the client gets two IP addresses (192.168.100.2 and a random one from the same subnet, but strongswan fails if it is sent the static one alone ...) So now I can connect from the client (from its 192.168.100.2 address) to the VPN GW (on its 192.168.100.1 alias) - which is what this was all about (hence the transport mode). As a by-note: It seems that iked, after authenticating the peer, always sends the "to" address from iked.conf as TSi and the "from" address as TSr in the IKE_AUTH response. In my understanding, this should be the other way round. Thanks for bearing with me :-) krgds /markus
Re: hp proliant dl 320e gen 8 for openbsd 5.5 64 bit ?
On 8/8/2014 7:54 AM, Matthias Appel wrote: "HP Dynamic Smart Array is a RAID solution combining a storage host bus adapter (HBA) and proprietary software components." You don't want to use this...hell, nobody should want to use this! The theory behind these fakeraid controllers is that you can start with the fakeraid, then install a real RAID card later and plug in the drives without reformatting. Of course, nobody actually upgrades like that. I have a bunch of low-end HPs with the 120i/320i controllers under CentOS. I hate them. You have to install a binary blob even under Linux. Until the latest driver revision the OS would sometimes see both drives of the array as separate drives, causing data loss. (I'm guessing it only wrote to one drive, then later used the other.)
Re: a half-baked analysis of the verification chicken-and-egg problem, and request
>One suggestion/request, to make it even harder for the man-in-the-middle >attack to be successfully employed, could the current checksums be posted in >the announcement of the new version? http://www.openbsd.org/55.html signify(1) pubkeys for this release: base: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h fw: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO pkg: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5 For the upcoming 5.6 release (few months yet), the keys are already included in your 5.5 install, or you can find them in your /etc/signify directory. Or, check http://www.openbsd.org/56.html (warning: incomplete) signify(1) pubkeys for this release: base: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV fw: RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw pkg: RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb In fact the snapshots available since about a month ago already include the public keys for the 5.7 release next May
Re: a half-baked analysis of the verification chicken-and-egg problem, and request
Checksums? SHA256 files? There are no SHA256 files. Now there are SHA256.sig files. You are at least 6 months behind the times. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/signify.1?query=signify&arch=i386 See the EXAMPLES section. You can visually verify the (very short) signify keys by finding them in one or two places -- in /etc/signify/ of previous install, in the source tree, on twitter or google, or anywhere else you like. Ask questions if you see once which disagree. Then follow the procedure described in EXAMPLES. This is more than a checksum. In any case, please do buy the CDs as an out of band mechanism as well. If not enough of them sell, maybe we should consider disabling the signify mechanism to encourage CD sales >My understanding of the problem: > >(Bear with me. I'm trying not to ramble too much here.) > >For catching simple data errors in the download, there is no problem, >of course. The "attacker" is random chance, so downloading the SHA256 >file and comparing the checksums should be sufficient. > >The probability of an error in the image download being matched by an >error in the checksum file download is pretty close to zero. > >However, if we consider the possibility that the image has been >deliberately modified, we must also consider the possibility that the >checksum file has also been deliberately modified. In this case the >probability that the modified image matches the modified checksums is >close to one. > >Therefore, for man-in-the-middle attacks, we are presented with a >logical vicious cycle, a problem of whether we trust the chicken first >or the egg, or rather, whether we trust the image first, which contains >the cryptographic key and the verification tool for testing the >checksums, or the checksums themselves first, which can be tested with >the sha256sum tool from some other source. > >Out-of-band information is the way to break the vicious cycle, thus the CDs >are worth the price. > >Now, for the general attack, we can assume that it would be hard enough for a >single government, or even several in collusion, to dynamically maintain >man-in-the-middle modifications and prevent the developers from noticing at >the same time as preventing the receiver from noticing. If checksums don't >match, enough people will ask questions, and the attacker's hand is tipped. > >For focused attacks, we can posit the interception of a few sets of CDs and >DNS poisoning of a few individuals' internet connection. There seems to be >very little to do to avoid this. > >I downloaded the install CD55.iso and the checksums from a nearby mirror. I >also downloaded the checksums from the central server and several other >mirrors (somewhere in the US, Africa, South America, Europe, IIRC). And I >compared the checksum files with each other, and they matched. So the mirrors >agree, and I can assume I'm fairly safe from rogue mirrors. > >If I were the target of a focused attack (low probability, but must be >considered), the attackers might be filtering my stream and mechanically >replacing every query against a known mirror with their altered mirror, with >its altered images and checksums. And they would have to be able to intercept >my physical CDs, as well. > >That's possible, but it's a lot of work for the attackers. And if they attack >too many individuals, as I note above, the chance of their hand being tipped >rises high enough to be a significant extra cost to them. Thus, this kind of >attack has to be limited to a one-shot, carefully coordinated attack, too >expensive to use for small game. > >So I can download the checksums on separate days, to make it harder for them >to maintain the attack successfully, and wait to actually install the system >until I've got checksums from several different mirrors, several different >times. Downloading multiple copies of the checksums at different times reduces >my exposure to man-in-the-middle attacks. Not perfect, but better than nothing. > >One suggestion/request, to make it even harder for the man-in-the-middle >attack to be successfully employed, could the current checksums be posted in >the announcement of the new version? > >When those announcements get echoed by magazines or by other bloggers, they >could produce copies of the checksums that are going to be much harder for an >attacker to catch in its filters. (Might require asking the magazines and >bloggers to echo the checksums with the announcements.) > >-- >Joel Rees
pkg_mgr error: "Fatal error: Ustar ... Eror while reading header"
I'm running OpenBSD -stable.When I run pkg_mgr and try to install something, I get an error message "Fatal error: Ustar ... Error while reading header" But if I install a program from the command line, all goes well. Doing the following command... echo installpath=http://ftp.openbsd.org/pub/OpenBSD/5.5/packages/amd64 > /etc/pkg.conf seemed to resolve the issue at first, but it's still happening. Hmm. Daniel
a half-baked analysis of the verification chicken-and-egg problem, and request
My understanding of the problem: (Bear with me. I'm trying not to ramble too much here.) For catching simple data errors in the download, there is no problem, of course. The "attacker" is random chance, so downloading the SHA256 file and comparing the checksums should be sufficient. The probability of an error in the image download being matched by an error in the checksum file download is pretty close to zero. However, if we consider the possibility that the image has been deliberately modified, we must also consider the possibility that the checksum file has also been deliberately modified. In this case the probability that the modified image matches the modified checksums is close to one. Therefore, for man-in-the-middle attacks, we are presented with a logical vicious cycle, a problem of whether we trust the chicken first or the egg, or rather, whether we trust the image first, which contains the cryptographic key and the verification tool for testing the checksums, or the checksums themselves first, which can be tested with the sha256sum tool from some other source. Out-of-band information is the way to break the vicious cycle, thus the CDs are worth the price. Now, for the general attack, we can assume that it would be hard enough for a single government, or even several in collusion, to dynamically maintain man-in-the-middle modifications and prevent the developers from noticing at the same time as preventing the receiver from noticing. If checksums don't match, enough people will ask questions, and the attacker's hand is tipped. For focused attacks, we can posit the interception of a few sets of CDs and DNS poisoning of a few individuals' internet connection. There seems to be very little to do to avoid this. I downloaded the install CD55.iso and the checksums from a nearby mirror. I also downloaded the checksums from the central server and several other mirrors (somewhere in the US, Africa, South America, Europe, IIRC). And I compared the checksum files with each other, and they matched. So the mirrors agree, and I can assume I'm fairly safe from rogue mirrors. If I were the target of a focused attack (low probability, but must be considered), the attackers might be filtering my stream and mechanically replacing every query against a known mirror with their altered mirror, with its altered images and checksums. And they would have to be able to intercept my physical CDs, as well. That's possible, but it's a lot of work for the attackers. And if they attack too many individuals, as I note above, the chance of their hand being tipped rises high enough to be a significant extra cost to them. Thus, this kind of attack has to be limited to a one-shot, carefully coordinated attack, too expensive to use for small game. So I can download the checksums on separate days, to make it harder for them to maintain the attack successfully, and wait to actually install the system until I've got checksums from several different mirrors, several different times. Downloading multiple copies of the checksums at different times reduces my exposure to man-in-the-middle attacks. Not perfect, but better than nothing. One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version? When those announcements get echoed by magazines or by other bloggers, they could produce copies of the checksums that are going to be much harder for an attacker to catch in its filters. (Might require asking the magazines and bloggers to echo the checksums with the announcements.) -- Joel Rees
Re: I have several questions
Just riffing off of what has already been said, not claiming any expertise. Just relating personal and unfortunately painful at times experience. There are folks out there with amazing knowledge and experience. Some choose to be malicious. The ones that have both patience and discipline combined with the above... yikes. You can certainly build a mighty fortress with OpenBSD, but if you get sloppy with the foundation it is gonna fail. Applies to any in life. Malicious types can shim BIOS, boot loaders, craft insane hidden disklabels, and who knows what else. They can also mess with downloads. e.g. can't get a foothold right now, i'll just mess with basexx.tgz for neophyte obsd user (me). Partial extract before failure... He'll reboot and then let's see what he does... Mirror traffic is watched, certainly possible to get hammered on during upgrades... Anywho, lots of knowledge available here. Just gotta poke around a bit ;) As an aside, if your online banking 'requires' either Java or Flash, that is rather disturbing.
Re: Good thing
On 2014-08-11 00:32, Gustav Fransson Nyvell wrote: On 08/11/14 09:22, Peter N. M. Hansteen wrote: On Mon, Aug 11, 2014 at 09:02:29AM +0200, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. does the word 'dependencies' ring a bell? - P Oh, I thought you had to keep all programs up to date on OpenBSD because that's the "OpenBSD way?" Just because the package is up to date doesn't mean the package uses the latest autotools.
Re: [LibreSSL] unable to encrypt file
> I'm trying to encrypt a file using openssl and a prompted password on OpenBSD. > Unfortunately there is no prompt and all I get is a 'bad password read': I'll guess you're using a snapshot from one or two weeks old. This has been fixed since.
Re: pf queuing not limiting bandwidth
HI Loïc,
just setting max does not work for me. I reached my intent with
queue root on alc0 bandwidth 600M, min 100M, max 100M default
pass out on alc0 inet from any to 192.168.2.2 flags S/SA set ( queue root )
Thank you for that insight!
On 12 August 2014 04:10, Loïc Blot wrote:
>
> Hi Raimundo,
>
> please use max directive:
>
> queue root on alc0 bandwidth 600M, max 500M
> --
> Best regards,
>
> Loïc BLOT, Engineering
> UNIX Systems, Security and Network Engineer
> http://www.unix-experience.fr
>
>
> Le mardi 12 août 2014 à 02:11 -0300, Raimundo Santos a écrit :
> > Hello misc!
> >
> > I am with a very non expected behaviour. With this simple pf.conf
> >
> > # pfctl -vnf /etc/pf.conf
> >
> > set skip on { lo }
> >
> > queue root on alc0 bandwidth 600M default
> >
> > pass out on alc0 all flags S/SA set ( queue root )
> >
> > I got this queue output when running tcpbench in client mode
> >
> > # pfctl -vvvsq
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > queue root on alc0 bandwidth 600M default qlimit 50
> >
> > [ pkts:6099167 bytes: 9233990662 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 0.0 packets/s, 0 b/s ]
> >
> > queue root on alc0 bandwidth 600M default qlimit 50
> >
> > [ pkts:6500911 bytes: 9842225822 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 80348.8 packets/s, 973.18Mb/s ]
> >
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 0.0 packets/s, 0 b/s ]
> >
> > queue root on alc0 bandwidth 600M default qlimit 50
> >
> > [ pkts:6902593 bytes: 10450369962 dropped pkts: 0 bytes:
> > 0 ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 80342.6 packets/s, 973.10Mb/s ]
> >
> > # pfctl -vsr
> >
> > pass out on alc0 all flags S/SA set ( queue root )
> >
> > [ Evaluations: 493 Packets: 14082601 Bytes: 13949048492
States: 1
> > ]
> >
> > [ Inserted: uid 0 pid 3493 State Creations: 1 ]
> >
> >
> > I've tried with 100M, 200M and 400M, all not shaping.
> >
> > I've also tried to setup a root queue with 200M and two child: a default
> > with 1M and the other, referred in the rule, with 100M, also not
working.
> >
> > I am playing with tcpbench and this is the only traffic I really care
about
> > on this machine. I restarted the tcpbench client on this machine every
time
> > I reloaded the testing rule and queue, and even deleted the related
states
> > (or states, in cases that I run tcpbench -b ), but nothing
> > leads me to the desired bandwidth shaping.
> >
> > I am experiencing the same behaviour in a virtual machine under KVM with
> > PCI Passthrough of an Intel NIC. These are the conf and results from the
> > virtual machine:
> >
> > # pfctl -vf /etc/pf.conf
> >
> >
> >
> > set skip on { lo }
> >
> > queue std on em0 bandwidth 100M default
> >
> > pass out on em0 all flags S/SA set ( queue std )
> >
> >
> > # pfctl -vvvsq
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > queue std on em0 bandwidth 100M default qlimit 50
> >
> > [ pkts: 1195513815 bytes: 87858084628 dropped pkts: 0 bytes:
> > 0 ]
> >
> > [ qlength: 0/ 50 ]
> >
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 0.0 packets/s, 0 b/s ]
> >
> > queue std on em0 bandwidth 100M default qlimit 50
> >
> > [ pkts: 1195734870 bytes: 88192747866 dropped pkts: 0 bytes:
> > 0 ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 44211.0 packets/s, 535.46Mb/s ]
> >
> >
> > [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0
> > ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 0.0 packets/s, 0 b/s ]
> >
> > queue std on em0 bandwidth 100M default qlimit 50
> >
> > [ pkts: 1195960995 bytes: 88535089028 dropped pkts: 0 bytes:
> > 0 ]
> >
> > [ qlength: 0/ 50 ]
> >
> > [ measured: 44718.0 packets/s, 541.60Mb/s ]
> >
> > # pfctl -vsr
> >
> > pass out on em0 all flags S/SA set ( queue std )
> >
> > [ Evaluations: 2 Packets: 1853414 Bytes: 1708817040
States: 2
> > ]
> >
> > [ Inserted: uid 0 pid 19622 State Creations: 2 ]
> >
> > The traffic passes through a Linux box where I have per ip bandwitdh
> > control (justifying tcpbench -b ), an in house bandwidth
controller
> > (poor man's 'net equalizer'). My intent was to not put a very high load
> > over this machine by getting close to my real pps and bps and so make my
> > capacity planing.
> >
> > What am I doing wrong with these queues?
> >
> > Thank you all,
> > Raimundo Santos
> >
> > Here is
[LibreSSL] unable to encrypt file
I'm trying to encrypt a file using openssl and a prompted password on OpenBSD. Unfortunately there is no prompt and all I get is a 'bad password read': $ openssl version LibreSSL 2.0 $ openssl des3 -in file bad password read Attempting the same on a different *non OpenBSD* system and a plain-vanilla openssl install: $ openssl versio OpenSSL 1.0.1i 6 Aug 2014 $ openssl des3 -in file enter des-ede3-cbc encryption password: Verifying - enter des-ede3-cbc encryption password: ... Is this expected behaviour of LibreSSL? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 5.6-beta (GENERIC.MP) #304: Fri Jul 25 12:02:01 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2120744960 (2022MB) avail mem = 2055561216 (1960MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries) bios0: vendor American Megatrends Inc. version "1.2a" date 02/21/12 bios0: Supermicro X7SPA-H acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI EINJ BERT ERST HEST acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.89 MHz 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.66 MHz 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P8) acpiprt4 at acpi0: bus 3 (P0P9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 Skipping LVDS initialization for Supermicro X7SPA-H No connectors reported connected with modes Cannot find any crtc or sizes - going 1024x768 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 19 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:04:70:74 ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi pci3 at ppb2 bus 3 em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:04:
lite-raft: High-Availability cluster script in posix shell
hello everybody, I'm writing a High-Availability failover cluster program in shell script based using the raft algorithm at the core. It's still not complete but I started to work toward portability rewriting code that rely on linux only program (like flock binary not present in the default OpenBSD installation). For now I will try to keep it working on Linux (Centos), OpenBSD and HP-UX (11.31 and maybe older). If someone is interested in taking a look at the code and play with it on OpenBSD I will be very happy to receive some feedback. You can download my program here: https://code.google.com/p/lite-raft/ If you know of any community of #! gurus that can be interested in this kind of project let me know!! regards Luigi
Re: I have several questions
On 12/08/14 18:27, Long Wind wrote: > I raise the question again. > During installation, I am asked: > > Directory does not contain SHA256.sig. Continue without verification? [no] > > I have to enter yes to let it proceed: > > Installing bsd > Installing bsd.rd > Installing base55.tgz > ... > > I have downloaded CD image for i386 and burned it and booted it > I think I shall not encounter such a question > Why SHA256.sig isn't on CD? > > Thanks to all those who reply (replied)!! > If someone was able to modify the ISO to tamper with the sets, they could also alter the keys included, and change the checksums and .sig file. In this case, you would be told everything was fine and it would continue installing. That is why you should verify the install ISO itself before booting/installing.
Re: how to debug iked failures?
On 08/12/2014 07:19 PM, Reyk Floeter wrote: > Another reason for AF 0 could be the use of the keyword "any" in your > iked.conf. I thought we fixed that before to inherit the AF from the > peer, but try to use "0.0.0.0/0" instead of "any" for IPv4 and > something like "::/0" for IPv6. > > Reyk > Yes, that was indeed the cause. Replacing every occurance of "any" with 0.0.0.0/0 finally allowed the flow to be set up! Thank you very much !!! But still, no joy ... :-[ iked now authenticates the ufqdn and sends it its assigned ip address. Then it sends TSi and TSr, but chooses its own internal address as TSi: Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 192.168.10.Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 192.168.10.30:4500 to 80.219.68.219:4500 msgid 1, 1980 bytes, NAT-T 30 end 192.168.10.30 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1980 bytes, NAT-T Again, is not the TSi the client's address? Why would iked send its own private address? Is the problem that I am trying to assign addresses from the same internal network that the VPN GW is in? The strongswan logs seem to match this: Aug 12 20:40:52 slimtoo charon: 10[IKE] IKE_SA xfertunnel[1] state change: CONNECTING => ESTABLISHED Aug 12 20:40:52 slimtoo charon: 10[IKE] scheduling reauthentication in 86110s Aug 12 20:40:52 slimtoo charon: 10[IKE] maximum IKE_SA lifetime 86290s Aug 12 20:40:52 slimtoo charon: 10[IKE] processing INTERNAL_IP4_ADDRESS attribute Aug 12 20:40:52 slimtoo charon: 10[KNL] 192.168.1.x is on interface wlan0 Aug 12 20:40:52 slimtoo charon: 10[IKE] installing new virtual IP 10.a.b.c Aug 12 20:40:52 slimtoo charon: 10[KNL] virtual IP 10.a.b.c installed on wlan0 Aug 12 20:40:52 slimtoo charon: 10[CFG] selecting proposal: Aug 12 20:40:52 slimtoo charon: 10[CFG] proposal matches Aug 12 20:40:52 slimtoo charon: 10[CFG] recei
Re: how to debug iked failures?
On Tue, Aug 12, 2014 at 06:57:50PM +0200, Markus Wernig wrote: > On 08/12/2014 05:39 PM, Markus Wernig wrote: > > > But really, I think this is the problem: > > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD > > SA spi 0xcb320247 > > Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 > > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load > > flow > > Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send > > ike auth > > > > It seems that the flow that comes from &sa->sa_flows in > > ikev2.c::ikev2_childsa_enable does not have its AF set. How could this > > happen? > > > > Could this be the reason? > > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload > TSi nextpayload TSr critical 0x00 length 24 > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 16 > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type IPV4_ADDR_RANGE > protoid 0 length 16 startport 0 endport 65535 > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload > TSr nextpayload NONE critical 0x00 length 8 > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 0 > Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type > protoid 0 length 0 startport 0 endport 65535 > > > Should not the TSi contain the IP of the Client? In the log above it > appears that it contains the IP of the VPN GW. And then TSr is of an > unknown type? Is strongswan sending something wrong here? > UNKNOWN:0 also means that the type Id is "0". So I would say it is unset/empty, not unknown. The TS length is also 0. strongswan is sending something strange, but maybe it is common in other implementations - I never saw it. Another reason for AF 0 could be the use of the keyword "any" in your iked.conf. I thought we fixed that before to inherit the AF from the peer, but try to use "0.0.0.0/0" instead of "any" for IPv4 and something like "::/0" for IPv6. Reyk
Re: how to debug iked failures?
On 08/12/2014 05:39 PM, Markus Wernig wrote: > But really, I think this is the problem: > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD > SA spi 0xcb320247 > Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load > flow > Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send > ike auth > > It seems that the flow that comes from &sa->sa_flows in > ikev2.c::ikev2_childsa_enable does not have its AF set. How could this > happen? > Could this be the reason? Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 16 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 0 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type protoid 0 length 0 startport 0 endport 65535 Should not the TSi contain the IP of the Client? In the log above it appears that it contains the IP of the VPN GW. And then TSr is of an unknown type? Is strongswan sending something wrong here? thx /markus
Re: how to debug iked failures?
On 08/12/2014 12:33 PM, Markus Wernig wrote: > sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 > address_src: A.B.C.D > address_dst: 10.x.y.z > spirange: min 0x0100 max 0x > sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 > sa: spi 0xfe52d794 auth none enc none > state mature replay 0 flags 0<> > address_src: A.B.C.D > address_dst: 10.x.y.z > sadb_update: satype esp vers 2 len 41 seq 20 pid 25389 > sa: spi 0xfe52d794 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 > address_src: A.B.C.D > address_dst: 10.x.y.z > key_auth: bits 160: ... > key_encrypt: bits 128: ... > identity_src: type ufqdn id 0: UFQDN/j...@doe.com > identity_dst: type fqdn id 0: FQDN/vpn.doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_update: satype esp vers 2 len 34 seq 20 pid 25389 > sa: spi 0xfe52d794 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 > address_src: A.B.C.D > address_dst: 10.x.y.z > identity_src: type ufqdn id 0: UFQDN/j...@doe.com > identity_dst: type fqdn id 0: FQDN/vpn.doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_add: satype esp vers 2 len 41 seq 21 pid 25389 > sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 > address_src: 10.x.y.z > address_dst: A.B.C.D > key_auth: bits 160: ... > key_encrypt: bits 128: ... > identity_src: type fqdn id 0: FQDN/vpn.doe.com > identity_dst: type ufqdn id 0: UFQDN/j...@doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_add: satype esp vers 2 len 34 seq 21 pid 25389 > sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 > address_src: 10.x.y.z > address_dst: A.B.C.D > identity_src: type fqdn id 0: FQDN/vpn.doe.com > identity_dst: type ufqdn id 0: UFQDN/j...@doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com But really, I think this is the problem: Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD SA spi 0xcb320247 Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load flow Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send ike auth It seems that the flow that comes from &sa->sa_flows in ikev2.c::ikev2_childsa_enable does not have its AF set. How could this happen?
Re: nginx in the default newsyslog.conf
> Related issue: If you are running httpd, any attempt to signal nginx > will be futile. > For httpd, use the following command instead: pkill -USR1 -u root -U root -x httpd (or just pkill -USR1 httpd) Reyk
Re: nginx in the default newsyslog.conf
On 2014-08-11, Jan Stary wrote: > /var/www/logs/access.log 644 4 * $W0 Z /var/run/nginx.pid SIGUSR1 > /var/www/logs/error.log644 7 250 * Z /var/run/nginx.pid SIGUSR1 > > The defult configuration of nginx, however, > makes nginx run chrooted in /var/www > which makes the PID file /var/www/run/nginx.pid Related issue: If you are running httpd, any attempt to signal nginx will be futile. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Terminate session on serial terminal (com0) when ssh disconnects
You can set TMOUT to read only so that it can't be changed by the user. export TMOUT=90 readonly TMOUT On Tue, Aug 12, 2014 at 2:37 AM, Clint Pachl wrote: > Here's my situation: I ssh into a remote server in my group. From that > server, I connect to an adjacent, local server in the group via the serial > terminal using tip(1) or cu(1). If the ssh connection is disconnected, the > login session to the second server's serial com0 will remain open/active. > > Is there a reliable, system-wide method or configuration to terminate the > serial session if the ssh connection dies? > > So far, all I have come up with is the shell's timeout variable (i.e., > TMOUT). However, this can be overridden by the user. > > I also tried the gettytab(5) timeout option "to", but that didn't work as > expected. It terminates and restarts the initial terminal login process, > not the user session. > > Thanks, > Clint
Re: how to debug iked failures?
On 08/12/2014 11:58 AM, Reyk Floeter wrote: > Operation not supported is from the kernel returning "EOPNOTSUPP". > > If any of the following sysctls are turned off and it is requested via > the PFKEYv2 socket, the kernel will return EOPNOTSUPP: > > net.inet.esp.enable=1 > net.inet.ah.enable=1 > net.inet.ipcomp.enable=0 > All three are set to 1. But strangely, now the "Operation not supported" message does not occur anymore. > You can also monitor the pfkey messages with "ipsectl -m" [add one or > more -v for packet dumps] to see what message returns EOPNOTSUPP. Here's the output - I don't see any obvious errors ... sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 address_src: A.B.C.D address_dst: 10.x.y.z spirange: min 0x0100 max 0x sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 sa: spi 0xfe52d794 auth none enc none state mature replay 0 flags 0<> address_src: A.B.C.D address_dst: 10.x.y.z sadb_update: satype esp vers 2 len 41 seq 20 pid 25389 sa: spi 0xfe52d794 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 address_src: A.B.C.D address_dst: 10.x.y.z key_auth: bits 160: ... key_encrypt: bits 128: ... identity_src: type ufqdn id 0: UFQDN/j...@doe.com identity_dst: type fqdn id 0: FQDN/vpn.doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_update: satype esp vers 2 len 34 seq 20 pid 25389 sa: spi 0xfe52d794 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 address_src: A.B.C.D address_dst: 10.x.y.z identity_src: type ufqdn id 0: UFQDN/j...@doe.com identity_dst: type fqdn id 0: FQDN/vpn.doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_add: satype esp vers 2 len 41 seq 21 pid 25389 sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 address_src: 10.x.y.z address_dst: A.B.C.D key_auth: bits 160: ... key_encrypt: bits 128: ... identity_src: type fqdn id 0: FQDN/vpn.doe.com identity_dst: type ufqdn id 0: UFQDN/j...@doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_add: satype esp vers 2 len 34 seq 21 pid 25389 sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 address_src: 10.x.y.z address_dst: A.B.C.D identity_src: type fqdn id 0: FQDN/vpn.doe.com identity_dst: type ufqdn id 0: UFQDN/j...@doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com I was wondering wether client sending EAP options would have anything to do with it: >> sending end entity cert >> establishing CHILD_SA xfertunnel >> generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr >> AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) >> N(NO_ADD_ADDR) N(EAP_ONLY) ] Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NOTIFY critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type MOBIKE_SUPPORTED Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NOTIFY critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type NO_ADDITIONAL_ADDRESSES Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NONE critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type EAP_ONLY_AUTHENTICATION thx /markus
Re: how to debug iked failures?
On Tue, Aug 12, 2014 at 11:39:11AM +0200, Markus Wernig wrote: > On 08/10/2014 03:09 PM, Reyk Floeter wrote: > > > Just try to increase the number of "v"s to get more info, for example, > > iked -dvv or iked -dvvv to get packet dumps. > > Thanks for the hint. That brought some progress. > I've now switched back to -current and changed the client setup (I had > been using the NetworkManager backend of the charon keying daemon, which > caused the crashes, also on -current). > > Now iked does not crash anymore - I will still do the recompiling and > backtracing, as this clearly should not happen. But I think it would > make sense to first get a working setup. > > That said, the connection does still not succeed. > After SA_INIT and IKE_AUTH everything seems fine, certificate gets > authenticated, but then iked says it can't send the ike_auth packet back. > > Aug 12 11:02:47 tunnel iked[26844]: sa_stateok: VALID flags 0x1f, > require 0x1f cert,certvalid,auth,authvalid,sa > ug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 22 > nextpayload CERT > Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 1520 > nextpayload AUTH > Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 264 > nextpayload CP > Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_getspi: message: Operation > not supported > ... > Strange ... what is not supported? Operation not supported is from the kernel returning "EOPNOTSUPP". If any of the following sysctls are turned off and it is requested via the PFKEYv2 socket, the kernel will return EOPNOTSUPP: net.inet.esp.enable=1 net.inet.ah.enable=1 net.inet.ipcomp.enable=0 You can also monitor the pfkey messages with "ipsectl -m" [add one or more -v for packet dumps] to see what message returns EOPNOTSUPP. Yes, it should print a log message in iked. Reyk > ... > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted > payload TSi nextpayload TSr critical 0x00 length 24 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 16 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type IPV4_ADDR_RANGE > protoid 0 length 16 startport 0 endport 65535 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: start 10.x.y.z end > 10.x.y.z > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted > payload TSr nextpayload NONE critical 0x00 length 8 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 0 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type > protoid 0 length 0 startport 0 endport 65535 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_msg_send: IKE_AUTH response > from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1996 bytes, NAT-T > Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: update spi 0xf82bfb58 > Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD > SA spi 0xf82bfb58 > Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: add spi 0xcdac6edf > Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD > SA spi 0xcdac6edf > Aug 12 11:02:47 tunnel iked[26844]: pfkey_flow: unsupported address family 0 > Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: failed to load > flow > Aug 12 11:02:47 tunnel iked[26844]: ikev2_dispatch_cert: failed to send > ike auth > > Does anybody see what's going wrong here? > > It does then send out a packet, but on the client side this triggers an > error: > > initiating IKE_SA xfertunnel[1] to E.F.G.H > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 192.168.1.x[500] to E.F.G.H[500] (1204 bytes) > received packet: from E.F.G.H[500] to 192.168.1.x[500] (457 bytes) > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ] > local host is behind NAT, sending keep alives > remote host is behind NAT > received cert request for > sending cert request for > authentication of 'j...@doe.com' (myself) with RSA signature successful > sending end entity cert > establishing CHILD_SA xfertunnel > generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr > AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) > N(NO_ADD_ADDR) N(EAP_ONLY) ] > sending packet: from 192.168.1.x[4500] to E.F.G.H[4500] (2236 bytes) > received packet: from E.F.G.H[4500] to 192.168.1.x[4500] (1996 bytes) > TS_RESPONDER verification failed > could not decrypt payloads > message verification failed > IKE_AUTH response with message ID 1 processing failed > > > Any more ideas? > > Thx /markus > --
Re: how to debug iked failures?
On 08/10/2014 03:09 PM, Reyk Floeter wrote: > Just try to increase the number of "v"s to get more info, for example, > iked -dvv or iked -dvvv to get packet dumps. Thanks for the hint. That brought some progress. I've now switched back to -current and changed the client setup (I had been using the NetworkManager backend of the charon keying daemon, which caused the crashes, also on -current). Now iked does not crash anymore - I will still do the recompiling and backtracing, as this clearly should not happen. But I think it would make sense to first get a working setup. That said, the connection does still not succeed. After SA_INIT and IKE_AUTH everything seems fine, certificate gets authenticated, but then iked says it can't send the ike_auth packet back. Aug 12 11:02:47 tunnel iked[26844]: sa_stateok: VALID flags 0x1f, require 0x1f cert,certvalid,auth,authvalid,sa ug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 22 nextpayload CERT Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 1520 nextpayload AUTH Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 264 nextpayload CP Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_getspi: message: Operation not supported ... Strange ... what is not supported? ... Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 16 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type protoid 0 length 0 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1996 bytes, NAT-T Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: update spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: add spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_flow: unsupported address family 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: failed to load flow Aug 12 11:02:47 tunnel iked[26844]: ikev2_dispatch_cert: failed to send ike auth Does anybody see what's going wrong here? It does then send out a packet, but on the client side this triggers an error: initiating IKE_SA xfertunnel[1] to E.F.G.H generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 192.168.1.x[500] to E.F.G.H[500] (1204 bytes) received packet: from E.F.G.H[500] to 192.168.1.x[500] (457 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ] local host is behind NAT, sending keep alives remote host is behind NAT received cert request for sending cert request for authentication of 'j...@doe.com' (myself) with RSA signature successful sending end entity cert establishing CHILD_SA xfertunnel generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) ] sending packet: from 192.168.1.x[4500] to E.F.G.H[4500] (2236 bytes) received packet: from E.F.G.H[4500] to 192.168.1.x[4500] (1996 bytes) TS_RESPONDER verification failed could not decrypt payloads message verification failed IKE_AUTH response with message ID 1 processing failed Any more ideas? Thx /markus
Re: pkg_mgr: some inconsistencies
Any updates on GTK based pkg_mgr? On Tue, Aug 12, 2014 at 1:22 PM, Alessandro DE LAURENZIS < just22@gmail.com> wrote: > Dear misc@ readers, > > I've just discovered and started playing with pkg_mgr (which is, IMHO, a > great tool - thanks to landry for his awesome contribution(s)). > > Testing it on OpenBSD 5.5-STABLE, I'm facing some incosistencies: > > 1- > some entries are reported as "installed" in the "All" category (and > they correctly appear in the "Installed" category), coherentrly with > the results from pkg_info, but are unmarked in the specific category; > for example: > > In "All": > ââ[X] vim-7.4.135p0-gtk2 vi clone, many > additional features ââ > ââ[ ] vim-7.4.135p0-gtk2 vi clone, many > additional features ââ > ââ[ ] vim-7.4.135p0-gtk2-perl-python-ruby vi clone, many > additional features ââ > > but in "Editors": > ââ[ ] vim-7.4.135p0-gtk2 vi clone, many > additional features ââ > ââ[ ] vim-7.4.135p0-gtk2-perl-python-ruby vi clone, many > additional features ââ > ââ[ ] vim-7.4.135p0-gtk2-perl-python3-ruby vi clone, many > additional features ââ > > 2- > some entries are simply duplicated; see e.g. 1st and 2nd vim lines in > "All" above, or, still in "All": > > ââ[ ] emacs-anthy-9100hp0 emacs files for anthy > ââ > ââ[ ] emacs-el-21.4p7 elisp sources for those > who want to read/modify them ââ > ââ[ ] emacs-el-21.4p7 elisp sources for those > who want to read/modify them ââ > ââ[ ] emacs-haskell-2.8.0 Emacs mode for editing > Haskell code ââ > > Maybe, related to 2-, duplicated lines appear when a package makes part > of more than one category? > > Or something weird in my system is happening? > > Thanks in advance for your time > > -- > Alessandro DE LAURENZIS > [mailto:just22@gmail.com] > LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: I have several questions
previously on this list Theo de Raadt contributed: You see the cd can fetch sets from mirrors and in fact all you need to upgrade is bsd.rd, a reboot from it and an internet connection, in which case verifying bsd.rd and the sets is needed. > Very the CD image media itself. You didn't do that? Then you booted it? If you really want you can add sha256.sig to the iso with isomaster from packages or choose http rather than cd. The bit you seem to have missed from Theo's last email aside from the above? is that booting the iso/bsd.rd without verifying it with signify (buy a cd or verify with checksums) means that while the sets may be valid the iso may not be and you could already be fscked from this or past CDs etc. (verifying could be compromised anyway). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
pkg_mgr: some inconsistencies
Dear misc@ readers, I've just discovered and started playing with pkg_mgr (which is, IMHO, a great tool - thanks to landry for his awesome contribution(s)). Testing it on OpenBSD 5.5-STABLE, I'm facing some incosistencies: 1- some entries are reported as "installed" in the "All" category (and they correctly appear in the "Installed" category), coherentrly with the results from pkg_info, but are unmarked in the specific category; for example: In "All": ││[X] vim-7.4.135p0-gtk2 vi clone, many additional features ││ ││[ ] vim-7.4.135p0-gtk2 vi clone, many additional features ││ ││[ ] vim-7.4.135p0-gtk2-perl-python-ruby vi clone, many additional features ││ but in "Editors": ││[ ] vim-7.4.135p0-gtk2 vi clone, many additional features ││ ││[ ] vim-7.4.135p0-gtk2-perl-python-ruby vi clone, many additional features ││ ││[ ] vim-7.4.135p0-gtk2-perl-python3-ruby vi clone, many additional features ││ 2- some entries are simply duplicated; see e.g. 1st and 2nd vim lines in "All" above, or, still in "All": ││[ ] emacs-anthy-9100hp0 emacs files for anthy ││ ││[ ] emacs-el-21.4p7 elisp sources for those who want to read/modify them ││ ││[ ] emacs-el-21.4p7 elisp sources for those who want to read/modify them ││ ││[ ] emacs-haskell-2.8.0 Emacs mode for editing Haskell code ││ Maybe, related to 2-, duplicated lines appear when a package makes part of more than one category? Or something weird in my system is happening? Thanks in advance for your time -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Terminate session on serial terminal (com0) when ssh disconnects
Here's my situation: I ssh into a remote server in my group. From that server, I connect to an adjacent, local server in the group via the serial terminal using tip(1) or cu(1). If the ssh connection is disconnected, the login session to the second server's serial com0 will remain open/active. Is there a reliable, system-wide method or configuration to terminate the serial session if the ssh connection dies? So far, all I have come up with is the shell's timeout variable (i.e., TMOUT). However, this can be overridden by the user. I also tried the gettytab(5) timeout option "to", but that didn't work as expected. It terminates and restarts the initial terminal login process, not the user session. Thanks, Clint
Re: pf queuing not limiting bandwidth
Hi Raimundo,
please use max directive:
queue root on alc0 bandwidth 600M, max 500M
--
Best regards,
Loïc BLOT, Engineering
UNIX Systems, Security and Network Engineer
http://www.unix-experience.fr
Le mardi 12 août 2014 à 02:11 -0300, Raimundo Santos a écrit :
> Hello misc!
>
> I am with a very non expected behaviour. With this simple pf.conf
>
> # pfctl -vnf /etc/pf.conf
>
> set skip on { lo }
>
> queue root on alc0 bandwidth 600M default
>
> pass out on alc0 all flags S/SA set ( queue root )
>
> I got this queue output when running tcpbench in client mode
>
> # pfctl -vvvsq
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> queue root on alc0 bandwidth 600M default qlimit 50
>
> [ pkts:6099167 bytes: 9233990662 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 0.0 packets/s, 0 b/s ]
>
> queue root on alc0 bandwidth 600M default qlimit 50
>
> [ pkts:6500911 bytes: 9842225822 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 80348.8 packets/s, 973.18Mb/s ]
>
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 0.0 packets/s, 0 b/s ]
>
> queue root on alc0 bandwidth 600M default qlimit 50
>
> [ pkts:6902593 bytes: 10450369962 dropped pkts: 0 bytes:
> 0 ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 80342.6 packets/s, 973.10Mb/s ]
>
> # pfctl -vsr
>
> pass out on alc0 all flags S/SA set ( queue root )
>
> [ Evaluations: 493 Packets: 14082601 Bytes: 13949048492 States: 1
> ]
>
> [ Inserted: uid 0 pid 3493 State Creations: 1 ]
>
>
> I've tried with 100M, 200M and 400M, all not shaping.
>
> I've also tried to setup a root queue with 200M and two child: a default
> with 1M and the other, referred in the rule, with 100M, also not working.
>
> I am playing with tcpbench and this is the only traffic I really care about
> on this machine. I restarted the tcpbench client on this machine every time
> I reloaded the testing rule and queue, and even deleted the related states
> (or states, in cases that I run tcpbench -b ), but nothing
> leads me to the desired bandwidth shaping.
>
> I am experiencing the same behaviour in a virtual machine under KVM with
> PCI Passthrough of an Intel NIC. These are the conf and results from the
> virtual machine:
>
> # pfctl -vf /etc/pf.conf
>
>
>
> set skip on { lo }
>
> queue std on em0 bandwidth 100M default
>
> pass out on em0 all flags S/SA set ( queue std )
>
>
> # pfctl -vvvsq
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> queue std on em0 bandwidth 100M default qlimit 50
>
> [ pkts: 1195513815 bytes: 87858084628 dropped pkts: 0 bytes:
> 0 ]
>
> [ qlength: 0/ 50 ]
>
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 0.0 packets/s, 0 b/s ]
>
> queue std on em0 bandwidth 100M default qlimit 50
>
> [ pkts: 1195734870 bytes: 88192747866 dropped pkts: 0 bytes:
> 0 ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 44211.0 packets/s, 535.46Mb/s ]
>
>
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0
> ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 0.0 packets/s, 0 b/s ]
>
> queue std on em0 bandwidth 100M default qlimit 50
>
> [ pkts: 1195960995 bytes: 88535089028 dropped pkts: 0 bytes:
> 0 ]
>
> [ qlength: 0/ 50 ]
>
> [ measured: 44718.0 packets/s, 541.60Mb/s ]
>
> # pfctl -vsr
>
> pass out on em0 all flags S/SA set ( queue std )
>
> [ Evaluations: 2 Packets: 1853414 Bytes: 1708817040 States: 2
> ]
>
> [ Inserted: uid 0 pid 19622 State Creations: 2 ]
>
> The traffic passes through a Linux box where I have per ip bandwitdh
> control (justifying tcpbench -b ), an in house bandwidth controller
> (poor man's 'net equalizer'). My intent was to not put a very high load
> over this machine by getting close to my real pps and bps and so make my
> capacity planing.
>
> What am I doing wrong with these queues?
>
> Thank you all,
> Raimundo Santos
>
> Here is my dmesgs, first from the physical machine and after from the
> virtual machine:
>
> OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8538095616 (8142MB)
> avail mem = 8302202880 (7917MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (53 entries)
> bios0: vendor American Megatrends Inc. version "0803" date 07/23/2012
> bios0: ASUSTeK Computer INC. M4A78LT-M-LE
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSD
