Re: Grouping windows in CWM
On Fri, May 21, 2021 at 07:00:13PM -0600, Jonathan Drews wrote: > Hi Folks: > > I am looking for a tutorial on grouping xterms in CWM. I Never mind. I found a good tutorial: Getting started with cwm https://undeadly.org/cgi?action=article=20090502141551 I just have to figure out some other minor details. > the sticky function (CM-s) and it's use in creating virtual desktops. > > I am running OpenBSD 6.9 GENERIC.MP#0 amd64 > > Kind regards, > Jonathan > > >
Grouping windows in CWM
Hi Folks: I am looking for a tutorial on grouping xterms in CWM. I undestand how to group one set of xterms using CM-g and CM-a. How do I do it if I have two sets of xterms? How would I designate a group "A" and group "B". I looked at the man page for cwm and read the section in Michael Lucas' "absolute OpenBSD' but I am still not sure how to do this. Also I am not understanding the use of the sticky function (CM-s) and it's use in creating virtual desktops. I am running OpenBSD 6.9 GENERIC.MP#0 amd64 Kind regards, Jonathan
Bugs running 6.9-CURRENT on MacBook Pro Touchbar 2017
Hi, I went back on testing OpenBSD on my MacBookPro14,3. I just installed 6.9-CURRENT and here's a list of non-working stuff. - keyboard and touchpad don't work. I have to use a USB keyboard/mouse. internal keyboard does work in the boot loader. but stops working after the kernel is loaded. - Xorg works but only in wsfb mode. - when I install the amdgpu-firmware, the console and Xorg gets black. And I have to force shutdown using the power button. - the wireless card can scan the SSID around me. but I can't connect to mine. it references the SSID in ifconfig but the status is "no network". - sleep, using zzz, drops the system to the debugger. If you have ideas, I'll be glad to test patches on it. Regards, Jo OpenBSD 6.9-current (RAMDISK_CD) #28: Fri May 21 13:27:21 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 17055719424 (16265MB) avail mem = 16534794240 (15768MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7aedf000 (37 entries) bios0: vendor Apple Inc. version "429.100.7.0.0" date 02/26/2021 bios0: Apple Inc. MacBookPro14,3 acpi0 at bios0: ACPI 5.0 acpi0: tables DSDT FACP UEFI ECDT HPET APIC MCFG SBST SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR VFCT acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz, 3792.96 MHz, 06-9e-09 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus 4 (PEG1) acpiprt3 at acpi0: bus 122 (PEG2) acpiprt4 at acpi0: bus 3 (RP01) acpiprt5 at acpi0: bus 2 (RP17) acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 acpicmos0 at acpi0 "APP0001" at acpi0 not configured "APP0003" at acpi0 not configured "ACPI0001" at acpi0 not configured "ACPI0002" at acpi0 not configured "APP000B" at acpi0 not configured "APP000D" at acpi0 not configured "BCM2E7C" at acpi0 not configured "APP" at acpi0 not configured "ACPI0003" at acpi0 not configured "PNP0C0D" at acpi0 not configured "PNP0C0C" at acpi0 not configured "APP0002" at acpi0 not configured "PNP0C0E" at acpi0 not configured acpicpu at acpi0 not configured cpu0: using VERW MDS workaround pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v6/7 Host" rev 0x05 ppb0 at pci0 dev 1 function 0 "Intel Core 6G PCIE" rev 0x05: msi pci1 at ppb0 bus 1 "ATI Polaris 11" rev 0xc7 at pci1 dev 0 function 0 not configured "ATI Radeon Pro Audio" rev 0x00 at pci1 dev 0 function 1 not configured ppb1 at pci0 dev 1 function 1 "Intel Core 6G PCIE" rev 0x05: msi pci2 at ppb1 bus 4 ppb2 at pci2 dev 0 function 0 vendor "Intel", unknown product 0x1578 rev 0x02 pci3 at ppb2 bus 5 ppb3 at pci3 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci4 at ppb3 bus 6 "Intel JHL6540 Thunderbolt" rev 0x02 at pci4 dev 0 function 0 not configured ppb4 at pci3 dev 1 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci5 at ppb4 bus 8 ppb5 at pci3 dev 2 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci6 at ppb5 bus 7 xhci0 at pci6 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi, xHCI 1.10 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 ppb6 at pci3 dev 4 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci7 at ppb6 bus 65 ppb7 at pci0 dev 1 function 2 "Intel Core 6G PCIE" rev 0x05: msi pci8 at ppb7 bus 122 ppb8 at pci8 dev 0 function 0 vendor "Intel", unknown product 0x1578 rev 0x02 pci9 at ppb8 bus 123 ppb9 at pci9 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci10 at ppb9 bus 124 "Intel JHL6540 Thunderbolt" rev 0x02 at pci10 dev 0 function 0 not configured ppb10 at pci9 dev 1 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci11 at ppb10 bus 126 ppb11 at pci9 dev 2 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi pci12 at ppb11 bus 125 xhci1 at pci12 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02:
Re: Relayd TLS inspection and SNI
Perhaps I will try squid or HaProxy. I was unaware I could filter by User_Agent in squid. It may be appropriate to update the relevant documentation if the support is not possible: *** relayd.conf.8.orig Fri May 21 13:19:06 2021 --- relayd.conf.8 Fri May 21 13:23:09 2021 *** *** 500,506 filter TLS connections as a man-in-the-middle. This combined mode is also called "TLS inspection". The configuration requires additional X.509 certificate settings; see the ca key description ! in the PROTOCOLS section for more details. When configured for "TLS inspection" mode, relayd(8) will listen for incoming connections which have been diverted to the local socket by PF. --- 500,510 filter TLS connections as a man-in-the-middle. This combined mode is also called "TLS inspection". The configuration requires additional X.509 certificate settings; see the ca key description ! in the PROTOCOLS section for more details. Note that this feature ! currently does not support Server Name Identification (SNI) making ! it inappropriate for use as a general Internet TLS Inspection ! gateway. ! When configured for "TLS inspection" mode, relayd(8) will listen for incoming connections which have been diverted to the local socket by PF. TLS Inspection (Man in the Middle) may be ancient, and certificate pinning may make it less useful some places, but there is still enough demand that many Internet security gateway vendors support it, even with TLS1.3.*, which I understand was one of the things which slowed its standardization. Work has been done to deprecate TLS1.0 and TLS1.1 for some time. I'm guessing it will be at least a few years before TLS1.2 is deprecated or obsoleted (not used by clients), not months. ** For my purpose, I can probably work around pinning issues and TLS1.3 certificate encryption by bypassing relayd based on IP as opposed to certificate content, or perhaps by restricting to TLS1.2. I don't think relayd TLS Intercept can make decisions based on the certificate anyway, at least I didn't notice reference in the documentation. * https://www.zscaler.com/blogs/product-insights/tls-13-busting-myths-and-debunking-fear-uncertainty-doubt * https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/decryption/decryption-concepts/tlsv13-ssl-decryption-support.html ** https://datatracker.ietf.org/doc/rfc8996/ ** https://www.ssllabs.com/ssl-pulse/ as of today, 46.4% of surveyed sites support TLSv1.0 and 54.1% of surveyed sites support TLSv1.2 as their best protocol. Thanks! > Sent: Friday, May 21, 2021 at 3:08 AM > From: "Stuart Henderson" > To: misc@openbsd.org > Subject: Re: Relayd TLS inspection and SNI > On 2021-05-18, BS Daemon wrote: >> I like using the base OpenBSD utilities, and was >> wondering if I'm doing something wrong, if relayd could be made to >> support SNI for man-in-the-middle, or if there is an alternative >> tool for doing this which would work. > > I can't help with relayd, but this does work with squid (and you can > filter on user-agent in ACLs). From: Martin [https://marc.info/?a=15813524301=1=2] Date: 2021-05-21 7:26:16[https://marc.info/?l=openbsd-misc=1=202105=2] > Hi, > > MITM is an ancient attack technique and it is not a good idea because it > breaks \ > original cert chain. So client (application) will see that cert is different > on its \ > end. Most people and apps reject connection to a resource with fake cert > which you're \ > going to send to them. > But you can use Squid for MITM as Stuart recommended, from my side > HaProxy/Nginx can \ > help you too to do this. For SNI Snort/Suricata can be useful but for TLS up > to v1.2 \ > only. > > Sniffing the traffic that way is a bad idea, most of services uses TLSv1.3 > with \ > encrypted SNI. So your work will disappear in months. > > Martin
Re: Relayd TLS inspection and SNI
On 2021-05-21, Martin wrote: > Hi, > > MITM is an ancient attack technique and it is not a good idea because it > breaks original cert chain. So client (application) will see that cert is > different on its end. Most people and apps reject connection to a resource > with fake cert which you're going to send to them. This is about providing monitored/filtered internet access to systems that are particularly configured to use it. The way this works is that you install the MITM-signing certificate on the machines accessing the web via that proxy. Typically in that case browsers automatically disable certificate pinning if the cert is signed by a locally administered CA. > But you can use Squid for MITM as Stuart recommended, from my side > HaProxy/Nginx can help you too to do this. For SNI Snort/Suricata can be > useful but for TLS up to v1.2 only. > > Sniffing the traffic that way is a bad idea, most of services uses > TLSv1.3 with encrypted SNI. So your work will disappear in months. There aren't many services which require TLSv1.3 with encrypted SNI yet, so the interception proxy can restrict to TLS 1.2 to bypass this.
Usage of .note.openbsd.ident
It seems this ELF note was used for the now dead compat_linux feature. Aside from compat systems in other operating systems that may wish to identify OpenBSD binaries does this note have any other active uses?
Re: IKEv2: CHILD_SA is not created
Ok, thanks for the clarification! On Fri, May 21, 2021 at 12:30 PM csszep wrote: > Hi! > > Not only Cisco ASA. Checkpoint, Fortinet, Juniper only support single set > of subnets per CHILD_SA too. > > https://wiki.strongswan.org/projects/strongswan/wiki/Checkpoint > https://wiki.strongswan.org/projects/strongswan/wiki/Fortinet > https://wiki.strongswan.org/projects/strongswan/wiki/Juniper > https://wiki.strongswan.org/projects/strongswan/wiki/CiscoInteroperability > > Unfortunately the workaround does not always work. IKED established multiple > IKE SA to the same peer if set up separate connection per subnet. > > For example Strongswan drop multiple IKE SA from the same peer if > uniqueid=yes (default setup): > > *Uniqueness* of an IKE_SA, used to drop multiple connections with one peer. > > Of course, for Strongswan, this is not a problem because it handles multiple > SAs per CHILD SA, but other implementation this can be a problem. > > > > > > > Денис Давыдов ezt írta (időpont: 2021. máj. 21., P, > 10:02): > >> It turns out that the Cisco ASA has a bug CSCue42170 with open status that >> prevents multiple traffic selectors from being supported in one child SA >> in >> IKEv2. >> >> For more information: >> >> https://bst.cloudapps.cisco.com/bugsearch/bug/CSCue42170/?reffering_site=dumpcr >> >> Known affected releases: 8.6(1), 9.1(7.13), 9.4(3.6) >> >> On Wed, May 12, 2021 at 7:44 PM Денис Давыдов wrote: >> >> > Finally solved! Tried TS one after another. To put it mildly, I'm >> > surprised. it turns out that the equipment on the remote side is >> configured >> > in such a way that for each TS I had to set up a separate connection. >> This >> > configuration working fine now: >> > >> > ikev2 crypto-primary active esp \ >> > from 10.21.139.8/30 to 2.2.2.2 \ >> > peer 7.7.7.7 \ >> > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> > modp2048 \ >> > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> > ikelifetime 86400 lifetime 28800 \ >> > psk "*" >> > >> > ikev2 crypto-primary active esp \ >> > from 10.21.139.8/30 to 3.3.3.3 \ >> > peer 7.7.7.7 \ >> > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> > modp2048 \ >> > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> > ikelifetime 86400 lifetime 28800 \ >> > psk "*" >> > >> > Tobias, thanks for your time and attention to my problem. >> > >> > On Wed, May 12, 2021 at 3:36 PM Денис Давыдов >> wrote: >> > >> >> Tobias, >> >> >> >> I replaced the OpenBSD with the same configuration: >> >> -> % uname -r -p >> >> 6.9 amd64 >> >> >> >> Now, with this configuration: >> >> >> >> ikev2 crypto-primary active esp \ >> >> from any to any \ >> >> peer 7.7.7.7 \ >> >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> >> modp2048 \ >> >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> >> ikelifetime 86400 lifetime 28800 \ >> >> psk "*" >> >> >> >> I got NO_PROPOSAL_CHOSEN: https://pastebin.com/Puhx41DZ >> >> >> >> And with the original configuration, which was agreed with the >> provider: >> >> >> >> ikev2 crypto-primary active esp \ >> >> from 10.21.139.8/30 to 2.2.2.2 \ >> >> from 10.21.139.8/30 to 3.3.3.3 \ >> >> peer 7.7.7.7 \ >> >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> >> modp2048 \ >> >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> >> ikelifetime 86400 lifetime 28800 \ >> >> psk "*" >> >> >> >> I still got TS_UNACCEPTABLE: https://pastebin.com/nw0usUJi >> >> >> >> I don't know where to dig anymore. The remote side is not responding >> yet. >> >> I contacted another provider who shared their configuration from the >> same >> >> Cisco model ASA 5585 (IKEv2 works with that hardware without >> problems). The >> >> only difference is that they have no these two options (although, I am >> not >> >> an expert in Cisco IKEv2 configuration either): >> >> >> >> crypto map outside_map 2470 set connection-type answer-only >> >> crypto map outside_map 2470 set reverse-route >> >> >> >> I understand that everyone is already tired of this topic. I will be in >> >> close contact with this provider. If I can connect to their equipment, >> I'll >> >> write what the problem was. Most likely the problem is in their >> >> configuration, rather than the problem in iked itself. I am sorry for >> the >> >> time wasted. >> >> >> >> Oh! One more question: Can iked work with the same TS but different >> peers >> >> at the same time? Am I correct in understanding that this is not >> possible? >> >> The remote side just offers the same settings for two public IP >> addresses >> >> from their side (they have two different crypto peers). So far, I just >> >> commented out the configuration with the second peer. >> >> >> >> >> >> On Wed, May 12, 2021 at 12:33 PM Tobias Heider < >> tobias.hei...@stusta.de> >> >>
Re: pf: antispoof with dynamic IP address?
On Fri, May 21, 2021 at 05:32:32AM +, Mogens Jensen wrote: > The antispoof directive will expand to two block rules with IP address > of the interface, so I would think that with a dynamic IP, the interface > should be surrounded in parentheses like this: > > antispoof for (wi0) quoting pf.conf(5): "The antispoof directive expands to a set of filter rules which will block all traffic with a source IP from the network(s) directly connected to the specified interface(s) from entering the system through any other interface." This means essentially that the sample rules would fail to be effective only if the interface you antispoof for has switched networks. I think that is a relatively rare event for running firewalls and not doing a ruleset reload. > === > The simplest mechanism to block everything by default and only pass > packets that match explicit rules is specify a first filter rule of: > > block all > === > > Is it not even simpler to just specify the filter rule as block without > all, they seem to expand identical? You're right, they expand to the exact same thing: [Fri May 21 10:19:50] peter@zelda:~$ cat blockonly block [Fri May 21 10:19:57] peter@zelda:~$ cat blockall block all [Fri May 21 10:20:01] peter@zelda:~$ doas pfctl -vnf blockall block drop all [Fri May 21 10:20:11] peter@zelda:~$ doas pfctl -vnf blockonly block drop all (also see eg http://home.nuug.no/~peter/pf/newest/simplest-secure.html) Cheers, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Relayd TLS inspection and SNI
Hi, MITM is an ancient attack technique and it is not a good idea because it breaks original cert chain. So client (application) will see that cert is different on its end. Most people and apps reject connection to a resource with fake cert which you're going to send to them. But you can use Squid for MITM as Stuart recommended, from my side HaProxy/Nginx can help you too to do this. For SNI Snort/Suricata can be useful but for TLS up to v1.2 only. Sniffing the traffic that way is a bad idea, most of services uses TLSv1.3 with encrypted SNI. So your work will disappear in months. Martin ‐‐‐ Original Message ‐‐‐ On Friday, May 21, 2021 7:08 AM, Stuart Henderson wrote: > On 2021-05-18, BS Daemon b...@post.com wrote: > > >I like using the base OpenBSD utilities, and was > > > > > > wondering if I'm doing something wrong, if relayd could be made to > > support SNI for man-in-the-middle, or if there is an alternative > > tool for doing this which would work. > > I can't help with relayd, but this does work with squid (and you can > filter on user-agent in ACLs).
pf: antispoof with dynamic IP address?
The antispoof directive will expand to two block rules with IP address
of the interface, so I would think that with a dynamic IP, the interface
should be surrounded in parentheses like this:
antispoof for (wi0)
But this seems to be wrong, as I have not read any guide or FAQ that
does this, e.g. the "Building a router" guide found at
https://www.openbsd.org/faq/pf/example1.html#pf
In the gateway configuration, egress group is surrounded with
parentheses in multiple places, but not with antispoof:
antispoof quick for { egress $wired $wifi }
Why should this not be
antispoof quick for { (egress) $wired $wifi }
or
antispoof quick for { (egress:0) $wired $wifi }
Another thing I was wondering about while reading the manpage for
pf.conf:
===
The simplest mechanism to block everything by default and only pass
packets that match explicit rules is specify a first filter rule of:
block all
===
Is it not even simpler to just specify the filter rule as block without
all, they seem to expand identical?
Thanks.
Mogens Jensen
Re: IKEv2: CHILD_SA is not created
Hi! Not only Cisco ASA. Checkpoint, Fortinet, Juniper only support single set of subnets per CHILD_SA too. https://wiki.strongswan.org/projects/strongswan/wiki/Checkpoint https://wiki.strongswan.org/projects/strongswan/wiki/Fortinet https://wiki.strongswan.org/projects/strongswan/wiki/Juniper https://wiki.strongswan.org/projects/strongswan/wiki/CiscoInteroperability Unfortunately the workaround does not always work. IKED established multiple IKE SA to the same peer if set up separate connection per subnet. For example Strongswan drop multiple IKE SA from the same peer if uniqueid=yes (default setup): *Uniqueness* of an IKE_SA, used to drop multiple connections with one peer. Of course, for Strongswan, this is not a problem because it handles multiple SAs per CHILD SA, but other implementation this can be a problem. Денис Давыдов ezt írta (időpont: 2021. máj. 21., P, 10:02): > It turns out that the Cisco ASA has a bug CSCue42170 with open status that > prevents multiple traffic selectors from being supported in one child SA in > IKEv2. > > For more information: > > https://bst.cloudapps.cisco.com/bugsearch/bug/CSCue42170/?reffering_site=dumpcr > > Known affected releases: 8.6(1), 9.1(7.13), 9.4(3.6) > > On Wed, May 12, 2021 at 7:44 PM Денис Давыдов wrote: > > > Finally solved! Tried TS one after another. To put it mildly, I'm > > surprised. it turns out that the equipment on the remote side is > configured > > in such a way that for each TS I had to set up a separate connection. > This > > configuration working fine now: > > > > ikev2 crypto-primary active esp \ > > from 10.21.139.8/30 to 2.2.2.2 \ > > peer 7.7.7.7 \ > > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > > modp2048 \ > > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > > ikelifetime 86400 lifetime 28800 \ > > psk "*" > > > > ikev2 crypto-primary active esp \ > > from 10.21.139.8/30 to 3.3.3.3 \ > > peer 7.7.7.7 \ > > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > > modp2048 \ > > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > > ikelifetime 86400 lifetime 28800 \ > > psk "*" > > > > Tobias, thanks for your time and attention to my problem. > > > > On Wed, May 12, 2021 at 3:36 PM Денис Давыдов wrote: > > > >> Tobias, > >> > >> I replaced the OpenBSD with the same configuration: > >> -> % uname -r -p > >> 6.9 amd64 > >> > >> Now, with this configuration: > >> > >> ikev2 crypto-primary active esp \ > >> from any to any \ > >> peer 7.7.7.7 \ > >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > >> modp2048 \ > >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > >> ikelifetime 86400 lifetime 28800 \ > >> psk "*" > >> > >> I got NO_PROPOSAL_CHOSEN: https://pastebin.com/Puhx41DZ > >> > >> And with the original configuration, which was agreed with the provider: > >> > >> ikev2 crypto-primary active esp \ > >> from 10.21.139.8/30 to 2.2.2.2 \ > >> from 10.21.139.8/30 to 3.3.3.3 \ > >> peer 7.7.7.7 \ > >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > >> modp2048 \ > >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > >> ikelifetime 86400 lifetime 28800 \ > >> psk "*" > >> > >> I still got TS_UNACCEPTABLE: https://pastebin.com/nw0usUJi > >> > >> I don't know where to dig anymore. The remote side is not responding > yet. > >> I contacted another provider who shared their configuration from the > same > >> Cisco model ASA 5585 (IKEv2 works with that hardware without problems). > The > >> only difference is that they have no these two options (although, I am > not > >> an expert in Cisco IKEv2 configuration either): > >> > >> crypto map outside_map 2470 set connection-type answer-only > >> crypto map outside_map 2470 set reverse-route > >> > >> I understand that everyone is already tired of this topic. I will be in > >> close contact with this provider. If I can connect to their equipment, > I'll > >> write what the problem was. Most likely the problem is in their > >> configuration, rather than the problem in iked itself. I am sorry for > the > >> time wasted. > >> > >> Oh! One more question: Can iked work with the same TS but different > peers > >> at the same time? Am I correct in understanding that this is not > possible? > >> The remote side just offers the same settings for two public IP > addresses > >> from their side (they have two different crypto peers). So far, I just > >> commented out the configuration with the second peer. > >> > >> > >> On Wed, May 12, 2021 at 12:33 PM Tobias Heider > > >> wrote: > >> > >>> On Wed, May 12, 2021 at 12:06:21PM +0300, Денис Давыдов wrote: > >>> > I tried to specify an explicit parameter -T to disable NAT-Traversal > >>> > auto-detection and use `local' parameter. Also according to your > advice > >>> > tried a configuration like
Re: IKEv2: CHILD_SA is not created
It turns out that the Cisco ASA has a bug CSCue42170 with open status that prevents multiple traffic selectors from being supported in one child SA in IKEv2. For more information: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCue42170/?reffering_site=dumpcr Known affected releases: 8.6(1), 9.1(7.13), 9.4(3.6) On Wed, May 12, 2021 at 7:44 PM Денис Давыдов wrote: > Finally solved! Tried TS one after another. To put it mildly, I'm > surprised. it turns out that the equipment on the remote side is configured > in such a way that for each TS I had to set up a separate connection. This > configuration working fine now: > > ikev2 crypto-primary active esp \ > from 10.21.139.8/30 to 2.2.2.2 \ > peer 7.7.7.7 \ > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > modp2048 \ > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > ikelifetime 86400 lifetime 28800 \ > psk "*" > > ikev2 crypto-primary active esp \ > from 10.21.139.8/30 to 3.3.3.3 \ > peer 7.7.7.7 \ > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group > modp2048 \ > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ > ikelifetime 86400 lifetime 28800 \ > psk "*" > > Tobias, thanks for your time and attention to my problem. > > On Wed, May 12, 2021 at 3:36 PM Денис Давыдов wrote: > >> Tobias, >> >> I replaced the OpenBSD with the same configuration: >> -> % uname -r -p >> 6.9 amd64 >> >> Now, with this configuration: >> >> ikev2 crypto-primary active esp \ >> from any to any \ >> peer 7.7.7.7 \ >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> modp2048 \ >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> ikelifetime 86400 lifetime 28800 \ >> psk "*" >> >> I got NO_PROPOSAL_CHOSEN: https://pastebin.com/Puhx41DZ >> >> And with the original configuration, which was agreed with the provider: >> >> ikev2 crypto-primary active esp \ >> from 10.21.139.8/30 to 2.2.2.2 \ >> from 10.21.139.8/30 to 3.3.3.3 \ >> peer 7.7.7.7 \ >> ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >> modp2048 \ >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> ikelifetime 86400 lifetime 28800 \ >> psk "*" >> >> I still got TS_UNACCEPTABLE: https://pastebin.com/nw0usUJi >> >> I don't know where to dig anymore. The remote side is not responding yet. >> I contacted another provider who shared their configuration from the same >> Cisco model ASA 5585 (IKEv2 works with that hardware without problems). The >> only difference is that they have no these two options (although, I am not >> an expert in Cisco IKEv2 configuration either): >> >> crypto map outside_map 2470 set connection-type answer-only >> crypto map outside_map 2470 set reverse-route >> >> I understand that everyone is already tired of this topic. I will be in >> close contact with this provider. If I can connect to their equipment, I'll >> write what the problem was. Most likely the problem is in their >> configuration, rather than the problem in iked itself. I am sorry for the >> time wasted. >> >> Oh! One more question: Can iked work with the same TS but different peers >> at the same time? Am I correct in understanding that this is not possible? >> The remote side just offers the same settings for two public IP addresses >> from their side (they have two different crypto peers). So far, I just >> commented out the configuration with the second peer. >> >> >> On Wed, May 12, 2021 at 12:33 PM Tobias Heider >> wrote: >> >>> On Wed, May 12, 2021 at 12:06:21PM +0300, Денис Давыдов wrote: >>> > I tried to specify an explicit parameter -T to disable NAT-Traversal >>> > auto-detection and use `local' parameter. Also according to your advice >>> > tried a configuration like this: >>> > >>> > ikev2 crypto-primary active esp \ >>> > from any to any \ >>> > local 1.1.1.1 peer 7.7.7.7 \ >>> > ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group >>> modp2048 >>> > \ >>> > childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >>> > ikelifetime 86400 lifetime 28800 \ >>> > psk "secret" >>> > >>> > And I got: >>> > >>> > May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_payloads: decrypted >>> > payload TSi nextpayload TSr critical 0x00 length 8 >>> > May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_tss: count 1 length 0 >>> > May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_ts: malformed >>> > payload: too short for header (0 < 8) >>> > May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_pld: malformed >>> > payload: shorter than minimum header size (0 < 4) >>> >>> This looks like you're running < 6.9 where any doesn't work for traffic >>> selectors. Either try using 0.0.0.0/0 instead or even better update >>> to the latest version. >>> >>> > >>> > Full log: https://pastebin.com/MLC4VXSs >>> > >>> > P.S. Tried removing the
Re: Relayd TLS inspection and SNI
On 2021-05-18, BS Daemon wrote: >I like using the base OpenBSD utilities, and was > wondering if I'm doing something wrong, if relayd could be made to > support SNI for man-in-the-middle, or if there is an alternative > tool for doing this which would work. I can't help with relayd, but this does work with squid (and you can filter on user-agent in ACLs).
