support update
0 C Philippines P National Capital Region T Taguig City Z 1633 O EDGEKIT Computer Systems I Tito Mari Francis H. Escano A Block 1 Lot 24 Upper Bicutan Taguig City 1633 Philippines M edgekit.computer.syst...@gmail.com U https://edgekitcomputersystems.blogspot.com # with trailing slash unless a specific resource B +63 927 258 7188 X n/a N We specialize in building simple, secure and functional solutions built on our Weapon of Choice technology stack, founded on OpenBSD and PostgreSQL. We provide OpenBSD and PostgreSQL consulting, implementation and administration.
ikev2 fails with mschap-v2
IKE is failing when I connect using a simple password defined in /etc/iked.conf. I'm connecting from a native Mac client...is mschap-v2 on MacOS broken or are my configs wrong? Thanks in advance. Working configuration and logs: /etc/iked.conf - works with psk ikev2 "ROAD_WARRIOR" esp \ from 0.0.0.0/0 to 10.1.255.0/24 \ peer any local vpn.company.com \ srcid vpn.company.com \ dstid mac-laptop \ psk "ASDFASDFASDFASDF" config address 10.1.255.0/24 \ config name-server 10.1.255.1 \ tag "$name-$id" spi=0x1d5c3d767b281592: recv IKE_SA_INIT req 0 peer 172.20.20.11:53784 local 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR' spi=0x1d5c3d767b281592: ikev2_sa_responder_dh: want dh ECP_256, KE has MODP_2048 spi=0x1d5c3d767b281592: ikev2_resp_recv: failed to negotiate IKE SA spi=0x1d5c3d767b281592: ikev2_add_error: INVALID_KE_PAYLOAD spi=0x1d5c3d767b281592: send IKE_SA_INIT res 0 peer 172.20.20.11:53784 local 192.168.110.50:500, 38 bytes spi=0x1d5c3d767b281592: recv IKE_SA_INIT req 0 peer 172.20.20.11:53784 local 192.168.110.50:500, 412 bytes, policy 'ROAD_WARRIOR' spi=0x1d5c3d767b281592: send IKE_SA_INIT res 0 peer 172.20.20.11:53784 local 192.168.110.50:500, 240 bytes spi=0x1d5c3d767b281592: recv IKE_AUTH req 1 peer 172.20.20.11:56756 local 192.168.110.50:4500, 560 bytes, policy 'ROAD_WARRIOR' spi=0x1d5c3d767b281592: assigned address 10.1.255.179 to FQDN/mac-laptop spi=0x1d5c3d767b281592: send IKE_AUTH res 1 peer 172.20.20.11:56756 local 192.168.110.50:4500, 272 bytes, NAT-T spi=0x1d5c3d767b281592: ikev2_childsa_enable: loaded SPIs: 0xa60629d5, 0x016966b2 (enc aes-256 auth hmac-sha2-256) spi=0x1d5c3d767b281592: ikev2_childsa_enable: loaded flows: ESP-0.0.0.0/0=10.1.255.0/24(0) spi=0x1d5c3d767b281592: established peer 172.20.20.11:56756[FQDN/mac-laptop] local 192.168.110.50:4500[FQDN/vpn.company.com] assigned 10.1.255.179 policy 'ROAD_WARRIOR' as responder (enc aes-256 auth hmac-sha2-256 group ecp256 prf hmac-sha2-256) /etc/iked.conf - fails with username/password ## user "testuser" "testpassword" ikev2 "ROAD_WARRIOR" esp \ from 0.0.0.0/0 to 10.1.255.0/24 \ peer any local vpn.company.com \ srcid vpn.company.com \ dstid mac-laptop \ eap "mschap-v2" \ config address 10.1.255.0/24 \ config name-server 10.1.255.1 \ tag "$name-$id" starting the daemon.. # iked -d -v ikev2 "ROAD_WARRIOR" passive tunnel esp inet from 0.0.0.0/0 to 10.1.255.0/24 local 192.168.110.50 peer any ikesa enc aes-128-gcm enc aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid vpn.company.com dstid mac-laptop lifetime 10800 bytes 4294967296 eap "MSCHAP_V2" config address 10.1.255.0 config name-server 10.1.255.1 tag "$name-$id" user "testuser" "testpassword" [..] spi=0x5a37ce60a7490c70: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR' spi=0x5a37ce60a7490c70: ikev2_sa_responder_dh: want dh ECP_256, KE has MODP_2048 spi=0x5a37ce60a7490c70: ikev2_resp_recv: failed to negotiate IKE SA spi=0x5a37ce60a7490c70: ikev2_add_error: INVALID_KE_PAYLOAD spi=0x5a37ce60a7490c70: send IKE_SA_INIT res 0 peer 172.20.20.11:64235 local 192.168.110.50:500, 38 bytes spi=0x5a37ce60a7490c70: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 192.168.110.50:500, 412 bytes, policy 'ROAD_WARRIOR' spi=0x5a37ce60a7490c70: send IKE_SA_INIT res 0 peer 172.20.20.11:64235 local 192.168.110.50:500, 265 bytes spi=0x5a37ce60a7490c70: recv IKE_AUTH req 1 peer 172.20.20.11:58037 local 192.168.110.50:4500, 512 bytes, policy 'ROAD_WARRIOR' spi=0x5a37ce60a7490c70: ikev2_pld_eap: REQUEST id 0 length 5 EAP-IDENTITY spi=0x5a37ce60a7490c70: send IKE_AUTH res 1 peer 172.20.20.11:58037 local 192.168.110.50:4500, 1472 bytes, NAT-T spi=0x92b7ead070f25c61: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR' spi=0x92b7ead070f25c61: ikev2_sa_responder_dh: want dh ECP_256, KE has MODP_2048 spi=0x92b7ead070f25c61: ikev2_resp_recv: failed to negotiate IKE SA spi=0x92b7ead070f25c61: ikev2_add_error: INVALID_KE_PAYLOAD spi=0x92b7ead070f25c61: send IKE_SA_INIT res 0 peer 172.20.20.11:64235 local
Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
On Fri, Feb 18, 2022 at 15:06 Stuart Henderson wrote...
> On Fri, Feb 18, 2022 at 11:43 AM I wrote:
>> ike passive esp transport proto udp from $public_ip to any \
>> main auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
>> quick auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
>> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
>>
>> ike passive esp transport proto udp from $public_ip to any \
>> main auth "hmac-md5" enc "3des" group "modp1024" \
>> quick auth "hmac-md5" enc "3des" group "modp1024" \
>> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
> With isakmpd and ipsec.conf you can't have two proposals for the default
> ("to any") peer with different PFS groups, you will have to choose one
> or the other. As-is the second will overwrite the first config block.
> (Use ipsecctl -v to see the commands sent by ipsecctl to isakmpd;
> it generates what are basically isakmpd.conf style config blocks and
> sends them over the control socket).
It still fails even with one block, but this is good to know. Thanks.
> You will save yourself a lot of trouble if you can move the newer machines
> to IKEv2 .. (It would not be possible to run both isakmpd and iked on a
> single OpenBSD machine though). Or alternatively wireguard or openvpn
> (which _can_ coexist with IKEv1) though IKEv2 generally has a simpler
> client config.
I'm not opposed to this and I've tried, but even now it still gives me
proposal errors from both iOS and MacOS
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #4 ENCR=AES_CBC-128
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #4 PRF=HMAC_SHA1
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #4 INTEGR=HMAC_SHA1_96
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #4 DH=MODP_1024
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #5 ENCR=3DES
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #5 PRF=HMAC_SHA1
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #5 INTEGR=HMAC_SHA1_96
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_log_proposal: IKE #5 DH=MODP_1024
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65:
ikev2_add_error: NO_PROPOSAL_CHOSEN
Feb 18 15:51:04 server iked[86219]: spi=0xdc6e75a2891b8e65: send
IKE_SA_INIT res 0 peer 100.64.10.10:57904 local 203.0.113.1:500, 36
bytes
Re: pf queuing/bandwidth control question
On 2022-02-18, Matthias Pressfreund wrote: > On 2022-02-17 18:56, Stuart Henderson wrote: >> On 2022-02-17, Matthias Pressfreund wrote: >>> On a server with 3 LAN interfaces (re0/1/2): >>> * re0 connected to the ISP >>> * re1 connected to the internal network >>> * re2 so far unused >>> >>> I was setting up pf queues for bandwidth control as follows: >>> * one queue on re0 for outgoing traffic >>> * another queue on re1 for incoming traffic >>> >>> Now, I would like to connect a wireless LAN router to re2 offering a >>> guest network. As far as I understood, a pf queue has to be bound to >>> exactly one network interface. So I'm wondering if there is another way >>> to include incoming traffic on re2 into the very same bandwidth control >>> currently realized by the queue on re1. >> >> A queue is bound to one interface, but, you can have multiple queues >> with the same name. "queue foo on em0", "queue foo on em1". >> >> An assignment in PF e.g. "queue foo" will then use whichever is the >> relevant "foo on $iface" when packets are transmitted which match >> the PF state created by that rule. >> > > Just for curiosity... What happens if after binding "queue foo on em0", there > is a rule like "pass out on em1 set queue foo"? Will a packet passed out here > (on em1) go into the bandwidth control bound on queue foo even though bound > to em0? The queue is attached to a firewall state and all packets matching that state will pick it up. So if you have a named queue present on em0 but not em1, and match with "pass out on em1 set queue foo", packets transmitted on em1 will not be queued, but packets matching that state (return packets via em0) _will_ be queued. I suggest making some rules that will match a speed test of some sort (tcpbench is easy and in base on openbsd) and play around to get a feel for what works. Probably helpful to watch "pfctl -vvsq" and/or "systat queues". -- Please keep replies on the mailing list.
Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
On 2022-02-18, fix...@gmail.com wrote:
> On Fri, Feb 18, 2022 at 11:43 AM I wrote:
>> I recently started seeing some ipsec clients fail on newer versions of
>> MacOS and iOS. After MacOS 12.1, connecting to my head end now fails
>> with NO_PROPOSAL_CHOSEN using mod1024 in my ipsec.conf. I've also
>> tried, with no success:
>>
>> main auth "hmac-sha2" enc "aes" group modp1024
>> quick auth "hmac-sha2" enc "aes" group modp1024
>
> Doing further research shows things are just not working out.
>
> I added two different configs that should match in /etc/ipsec.conf
>
> ike passive esp transport proto udp from $public_ip to any \
> main auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
> quick auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
>
> ike passive esp transport proto udp from $public_ip to any \
> main auth "hmac-md5" enc "3des" group "modp1024" \
> quick auth "hmac-md5" enc "3des" group "modp1024" \
> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
With isakmpd and ipsec.conf you can't have two proposals for the default
("to any") peer with different PFS groups, you will have to choose one
or the other. As-is the second will overwrite the first config block.
(Use ipsecctl -v to see the commands sent by ipsecctl to isakmpd;
it generates what are basically isakmpd.conf style config blocks and
sends them over the control socket).
There is a chance that by writing your own isakmpd.conf you might be
able to have two main mode (phase 1) proposals with differing groups,
but for quick mode it's a protocol limitation and it's only possible to
send one - and I don't think isakmpd can let you choose what to send in
phase 2 depending on what was used for phase 1. It will still be painful
though.
You will save yourself a lot of trouble if you can move the newer machines
to IKEv2 .. (It would not be possible to run both isakmpd and iked on a
single OpenBSD machine though). Or alternatively wireguard or openvpn
(which _can_ coexist with IKEv1) though IKEv2 generally has a simpler
client config.
> Running a packet capture on the server shows that both of these
> proposals are being sent by the client and should match in isakmpd.
> Alas, they do not.
>
> Here's the pcap -- again, thanks in advance for any assistance.
>
> server# tcpdump -nvvs 16000 -i em0 src host 100.64.10.10 and port 500
> 13:14:50.662540 64:9e:f3:XX:XX:XX 52:54:00:XX:XX:XX 0800 830:
> 100.64.10.10.63823 > 203.0.113.1.500: [udp
> sum ok] isakmp v1.0 exchange ID_PROT
> cookie: 197d16ba79870fd2-> msgid: len: 788
> payload: SA len: 516 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 504 proposal: 1 proto: ISAKMP
> spisz: 0 xforms: 14
> payload: TRANSFORM len: 36
> transform: 1 ID: ISAKMP
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> attribute ENCRYPTION_ALGORITHM = AES_CBC
> attribute KEY_LENGTH = 256
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute HASH_ALGORITHM = SHA2_256
> attribute GROUP_DESCRIPTION = MODP_2048
> [..]
>payload: TRANSFORM len: 32
> transform: 14 ID: ISAKMP
> attribute LIFE_TYPE = SECONDS
>attribute LIFE_DURATION = 3600
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute HASH_ALGORITHM = MD5
> attribute GROUP_DESCRIPTION = MODP_1024
> [..]
> 13:14:50.667404 52:54:00:XX:XX:XX 64:9e:f3:XX:XX:XX 0800 82:
> 203.0.113.1.500 > 100.64.10.10.63823: [bad udp cksum 1608! -> 2224]
> isakmp v1.0 exchange INFO
> cookie: 3cbfd92c4ea7626d-> msgid: len: 40
> payload: NOTIFICATION len: 12
> notification: NO PROPOSAL CHOSEN (ttl 64, id 48652, len 68)
> [..]
>
>
--
Please keep replies on the mailing list.
Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
Matthew Ernisse writes... > How are you setting the proposals on the MacOS end? Your first instance I > think you figured out that you had not specified PSK and so you had a mismatch > there. In the second case you didn't supply the iked(8) debugging information > so I'm not sure what is happening. I am also not sure why you have two > stanzas > in ipsec.conf(5) (much less why you are allowing md5/3des). You should > probably run iked(8) with debugging cranked up and see what it says, I've > found > it to always tell me why it is unhappy. I didn't have a mismatch in my PSKs (the full config was further down in my first message), nor am I running iked. This is just simple l2tp and everything is handled by isakmpd. The two stanzas are to test a match on different proposals, but nothing on the server seems to match proposals chosen by the client. > I have tunnels between OpenBSD 7.0, iOS/iPadOS 15.3.1, and MacOS 10.15.7. I'm envious at this point! Thanks.
Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
On Fri, Feb 18, 2022 at 01:30:27PM -0600, fix...@gmail.com said: > Date: Fri, 18 Feb 2022 13:30:27 -0600 > From: fix...@gmail.com > To: misc@openbsd.org > Subject: Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from > recent MacOS/iOS clients > > On Fri, Feb 18, 2022 at 11:43 AM I wrote: > > I recently started seeing some ipsec clients fail on newer versions of > > MacOS and iOS. After MacOS 12.1, connecting to my head end now fails > > with NO_PROPOSAL_CHOSEN using mod1024 in my ipsec.conf. I've also How are you setting the proposals on the MacOS end? Your first instance I think you figured out that you had not specified PSK and so you had a mismatch there. In the second case you didn't supply the iked(8) debugging information so I'm not sure what is happening. I am also not sure why you have two stanzas in ipsec.conf(5) (much less why you are allowing md5/3des). You should probably run iked(8) with debugging cranked up and see what it says, I've found it to always tell me why it is unhappy. I have tunnels between OpenBSD 7.0, iOS/iPadOS 15.3.1, and MacOS 10.15.7. --Matt -- Matthew Ernisse m...@going-flying.com https://www.going-flying.com/
Re: IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
On Fri, Feb 18, 2022 at 11:43 AM I wrote: > I recently started seeing some ipsec clients fail on newer versions of > MacOS and iOS. After MacOS 12.1, connecting to my head end now fails > with NO_PROPOSAL_CHOSEN using mod1024 in my ipsec.conf. I've also > tried, with no success: > > main auth "hmac-sha2" enc "aes" group modp1024 > quick auth "hmac-sha2" enc "aes" group modp1024 Doing further research shows things are just not working out. I added two different configs that should match in /etc/ipsec.conf ike passive esp transport proto udp from $public_ip to any \ main auth "hmac-sha2-256" enc "aes-256" group "modp2048" \ quick auth "hmac-sha2-256" enc "aes-256" group "modp2048" \ psk "THIS_IS_MY_IPSEC_PASSPHRASE" ike passive esp transport proto udp from $public_ip to any \ main auth "hmac-md5" enc "3des" group "modp1024" \ quick auth "hmac-md5" enc "3des" group "modp1024" \ psk "THIS_IS_MY_IPSEC_PASSPHRASE" Running a packet capture on the server shows that both of these proposals are being sent by the client and should match in isakmpd. Alas, they do not. Here's the pcap -- again, thanks in advance for any assistance. server# tcpdump -nvvs 16000 -i em0 src host 100.64.10.10 and port 500 13:14:50.662540 64:9e:f3:XX:XX:XX 52:54:00:XX:XX:XX 0800 830: 100.64.10.10.63823 > 203.0.113.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 197d16ba79870fd2-> msgid: len: 788 payload: SA len: 516 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 504 proposal: 1 proto: ISAKMP spisz: 0 xforms: 14 payload: TRANSFORM len: 36 transform: 1 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute ENCRYPTION_ALGORITHM = AES_CBC attribute KEY_LENGTH = 256 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute HASH_ALGORITHM = SHA2_256 attribute GROUP_DESCRIPTION = MODP_2048 [..] payload: TRANSFORM len: 32 transform: 14 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute AUTHENTICATION_METHOD = PRE_SHARED attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 [..] 13:14:50.667404 52:54:00:XX:XX:XX 64:9e:f3:XX:XX:XX 0800 82: 203.0.113.1.500 > 100.64.10.10.63823: [bad udp cksum 1608! -> 2224] isakmp v1.0 exchange INFO cookie: 3cbfd92c4ea7626d-> msgid: len: 40 payload: NOTIFICATION len: 12 notification: NO PROPOSAL CHOSEN (ttl 64, id 48652, len 68) [..]
IPSec fails with NO_PROPOSAL_CHOSEN when connecting from recent MacOS/iOS clients
I recently started seeing some ipsec clients fail on newer versions of MacOS and iOS. After MacOS 12.1, connecting to my head end now fails with NO_PROPOSAL_CHOSEN using mod1024 in my ipsec.conf. I've also tried, with no success: main auth "hmac-sha2" enc "aes" group modp1024 quick auth "hmac-sha2" enc "aes" group modp1024 Has anyone gotten ipsec working between recent versions of Apple devices? If so, could you share your proposals and/or configs? Below are my configs -- thanks in advance for any help. macbook-client:~$ uname -a Darwin neptune.example.org 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64 server# uname -a OpenBSD lax 7.0 GENERIC#5 amd64 # tail -f /var/log/messages Feb 18 11:11:31 server isakmpd[10385]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Feb 18 11:11:31 server last message repeated 11 times Feb 18 11:11:31 server isakmpd[10385]: attribute_unacceptable:AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Feb 18 11:11:31 server isakmpd[10385]: attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Feb 18 11:11:31 server isakmpd[10385]: message_negotiate_sa: no compatible proposal found Feb 18 11:11:31 server isakmpd[10385]: dropped message from 100.64.10.10 port 63434 due to notification type NO_PROPOSAL_CHOSEN # cat /etc/ipsec.conf public_ip = "203.0.113.1" ike passive esp tunnel proto udp from $public_ip to any \ main group "modp1024" quick group "modp1024" \ psk "THIS_IS_MY_IPSEC_PASSPHRASE" # ipssecctl -vnf /etc/ipsec.conf public_ip = "203.0.113.1" C set [Phase 1]:Default=peer-default force C set [peer-default]:Phase=1 force C set [peer-default]:Authentication=THIS_IS_MY_IPSEC_PASSPHRASE force C set [peer-default]:Configuration=phase1-peer-default force C set [phase1-peer-default]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-default]:Transforms=phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024 force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:HASH_ALGORITHM=SHA force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:KEY_LENGTH=128,128:256 force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force C set [phase1-transform-peer-default-PRE_SHARED-SHA-AES128-MODP_1024]:Life=LIFE_MAIN_MODE force C set [from-203.0.113.1=17-to-0.0.0.0/0=17]:Phase=2 force C set [from-203.0.113.1=17-to-0.0.0.0/0=17]:ISAKMP-peer=peer-default force C set [from-203.0.113.1=17-to-0.0.0.0/0=17]:Configuration=phase2-from-203.0.113.1=17-to-0.0.0.0/0=17 force C set [from-203.0.113.1=17-to-0.0.0.0/0=17]:Local-ID=from-203.0.113.1=17 force C set [from-203.0.113.1=17-to-0.0.0.0/0=17]:Remote-ID=to-0.0.0.0/0=17 force C set [phase2-from-203.0.113.1=17-to-0.0.0.0/0=17]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from-203.0.113.1=17-to-0.0.0.0/0=17]:Suites=phase2-suite-from-203.0.113.1=17-to-0.0.0.0/0=17 force C set [phase2-suite-from-203.0.113.1=17-to-0.0.0.0/0=17]:Protocols=phase2-protocol-from-203.0.113.1=17-to-0.0.0.0/0=17 force C set [phase2-protocol-from-203.0.113.1=17-to-0.0.0.0/0=17]:PROTOCOL_ID=IPSEC_ESP force C set [phase2-protocol-from-203.0.113.1=17-to-0.0.0.0/0=17]:Transforms=phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:TRANSFORM_ID=AES force C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:KEY_LENGTH=128,128:256 force C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:ENCAPSULATION_MODE=TUNNEL force C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 f C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:GROUP_DESCRIPTION=MODP_1024 force C set [phase2-transform-from-203.0.113.1=17-to-0.0.0.0/0=17-AES128-SHA2_256-MODP_1024-TUNNEL]:Life=LIFE_QUICK_MODE force C set [from-203.0.113.1=17]:ID-type=IPV4_ADDR force C set [from-203.0.113.1=17]:Address=203.0.113.1 force C set [to-0.0.0.0/0=17]:ID-type=IPV4_ADDR_SUBNET force C set [to-0.0.0.0/0=17]:Network=0.0.0.0 force C set [to-0.0.0.0/0=17]:Netmask=0.0.0.0 force C set [from-203.0.113.1=17]:Protocol=17 force C set [to-0.0.0.0/0=17]:Protocol=17 force C add [Phase 2]:Passive-Connections=from-203.0.113.1=17-to-0.0.0.0/0=17
Re: acpi0: sleep states S0 S3 S5, was: S0 S3 S4 S5
Try the next snap. I believe a diff slipped in temporarily. -dv > On Feb 18, 2022, at 11:38, Marcus MERIGHI wrote: > > Hello! > > I'm not sure this should go to bugs@. > > On three machines that I upgraded to the latest snapshot > yesterday, "S4" vanished: > > -acpi0: sleep states S0 S3 S4 S5 > +acpi0: sleep states S0 S3 S5 > > These are all amd64. > > Dmesgs below, seperated by "-". > > Marcus > > - Shuttle Inc. DS57U > > OpenBSD 7.0-current (GENERIC.MP) #361: Thu Feb 17 01:50:24 MST 2022 >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16031678464 (15289MB) > avail mem = 15528607744 (14809MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec2f0 (82 entries) > bios0: vendor American Megatrends Inc. version "1.06" date 03/04/2015 > bios0: Shuttle Inc. DS57U > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! > SLIC SSDT SSDT SSDT DMAR > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > PXSX(S4) RP05(S4) PXSX(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) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.65 MHz, 06-3d-04 > 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,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.23 MHz, 06-3d-04 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins > acpimadt0: bogus nmi for apid 0 > acpimadt0: bogus nmi for apid 2 > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (PEG2) > acpiprt4 at acpi0: bus 1 (RP01) > acpiprt5 at acpi0: bus -1 (RP02) > acpiprt6 at acpi0: bus 2 (RP03) > acpiprt7 at acpi0: bus 3 (RP04) > acpiprt8 at acpi0: bus -1 (RP05) > acpiprt9 at acpi0: bus -1 (RP06) > acpiprt10 at acpi0: bus -1 (RP07) > acpiprt11 at acpi0: bus -1 (RP08) > acpiec0 at acpi0: not present > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 3: ns16550a, 16 byte fifo > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 4: ns16550a, 16 byte fifo > acpicmos0 at acpi0 > acpibtn0 at acpi0: SLPB > acpibtn1 at acpi0: PWRB > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > acpicpu0 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpipwrres0 at acpi0: PG00, resource for PEG0 > acpipwrres1 at acpi0: PG01, resource for PEG1 > acpipwrres2 at acpi0: PG02, resource for PEG2 > acpipwrres3 at acpi0: FN00, resource for FAN0 > acpipwrres4 at acpi0: FN01, resource for FAN1 > acpipwrres5 at acpi0: FN02, resource for FAN2 > acpipwrres6 at acpi0: FN03, resource for FAN3 > acpipwrres7 at acpi0: FN04, resource for FAN4 > acpitz0 at acpi0: critical temperature is 105 degC > acpitz1 at acpi0: critical temperature is 105 degC > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > cpu0: using VERW MDS workaround (except on vmm entry) > cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2201, 2200, 2100, 2000, 1800, > 1700, 1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09 > inteldrm0 at pci0 dev 2 function 0 "Intel HD
Re: pf queuing/bandwidth control question
On 2022-02-17 18:56, Stuart Henderson wrote: > On 2022-02-17, Matthias Pressfreund wrote: >> On a server with 3 LAN interfaces (re0/1/2): >> * re0 connected to the ISP >> * re1 connected to the internal network >> * re2 so far unused >> >> I was setting up pf queues for bandwidth control as follows: >> * one queue on re0 for outgoing traffic >> * another queue on re1 for incoming traffic >> >> Now, I would like to connect a wireless LAN router to re2 offering a >> guest network. As far as I understood, a pf queue has to be bound to >> exactly one network interface. So I'm wondering if there is another way >> to include incoming traffic on re2 into the very same bandwidth control >> currently realized by the queue on re1. > > A queue is bound to one interface, but, you can have multiple queues > with the same name. "queue foo on em0", "queue foo on em1". > > An assignment in PF e.g. "queue foo" will then use whichever is the > relevant "foo on $iface" when packets are transmitted which match > the PF state created by that rule. > Just for curiosity... What happens if after binding "queue foo on em0", there is a rule like "pass out on em1 set queue foo"? Will a packet passed out here (on em1) go into the bandwidth control bound on queue foo even though bound to em0?
Re: rspamd and empty "mail from" header
18.02.2022 14:26, Claus Assmann пишет: On Fri, Feb 18, 2022, kasak wrote: But, is this correct behavior of "mail from" header? Maybe the header What is a ``"mail from" header''? Do you mean the mail header From: or are you referring to the SMTP MAIL command MAIL From: should have "<>" in it? You can check the fine RFCs (e.g., 5322 for headers, 5321 for SMTP) -- AFAICT an empty address is not valid for the "From:" header and certainly not for the MAIL command. I am referring to smtp "mail from" command. As I see in rfc5321: A MAIL command with a null reverse-path appears as follows: MAIL FROM:<> And Vsevolod, developer of rspamd, mentioned that mails coming to rspamd from opensmtpd appear to have no "<>" Honestly, I'm far from developing and I can't understand where the brackets gone. I just want to help solve problem that maybe some other users can face.
Re: rspamd and empty "mail from" header
On 2022-02-18, kasak wrote: > Hello misc! I have mailed this message at m...@opensmtpd.org at first, > but nobody answered, maybe someone help here? > > I have a question about opensmtpd and rspamd. > I'm using opensmtp and rspamd as a relay server with spam checking. > The spam check is done with help of opensmtpd-filter-rspamd. > The os is OpenBSD 7.0 > > I have noticed, that all DSN messages coming to or from internal mail > server, are marked as spam, because rspamd adds BROKEN HEADERS for > this messages. > First of all, I tried to research this issue but with no luck, i've > created this issue on rspamd github repo > https://github.com/rspamd/rspamd/issues/3983 > And we found that messages with "broken headers" have empty "mail > from" header, where rspamd expect it as "<>" > > The patch to workaround this was added to rspamd side. > But, is this correct behavior of "mail from" header? Maybe the header > should have "<>" in it? If I understand correctly this relates to the protocol used when feeding the message to rspamd, i.e. the part which is handled only by opensmtpd-filter-rspamd and rspamd, rather than something in SMTP. https://rspamd.com/doc/architecture/protocol.html#http-headers just says "Defines SMTP mail from command data" and isn't clear whether the angle brackets should be included. So I would say that it's under-specified in rspamd docs. In that case I would think "correct behaviour" is whatever rspamd expects.. -- Please keep replies on the mailing list.
Re: rspamd and empty "mail from" header
On Fri, Feb 18, 2022, kasak wrote: > But, is this correct behavior of "mail from" header? Maybe the header What is a ``"mail from" header''? Do you mean the mail header From: or are you referring to the SMTP MAIL command MAIL From: > should have "<>" in it? You can check the fine RFCs (e.g., 5322 for headers, 5321 for SMTP) -- AFAICT an empty address is not valid for the "From:" header and certainly not for the MAIL command. -- Address is valid for this mailing list only, please do not reply to it directly, but to the list.
rspamd and empty "mail from" header
Hello misc! I have mailed this message at m...@opensmtpd.org at first, but nobody answered, maybe someone help here? I have a question about opensmtpd and rspamd. I'm using opensmtp and rspamd as a relay server with spam checking. The spam check is done with help of opensmtpd-filter-rspamd. The os is OpenBSD 7.0 I have noticed, that all DSN messages coming to or from internal mail server, are marked as spam, because rspamd adds BROKEN HEADERS for this messages. First of all, I tried to research this issue but with no luck, i've created this issue on rspamd github repo https://github.com/rspamd/rspamd/issues/3983 And we found that messages with "broken headers" have empty "mail from" header, where rspamd expect it as "<>" The patch to workaround this was added to rspamd side. But, is this correct behavior of "mail from" header? Maybe the header should have "<>" in it?
