Re: [Swan] host-to-host config fails with Can't find the certificate or private key
Hi, I realized I only sent this to you directly last time. I'm still having trouble and hoped someone could help. > The config file you posted used leftckaid= and you said you copied it to both > sides which wouldn’t work. Can you confir you are trying only with > leftrsasigkey and rightrsasigkey ? If that still fails send me output using > plutodebug=all and fresh certutil / showhostkey output Yes, I used leftrsasigkey and rightrsasigkey, not the ckaid settings. Both failed, but now I at least understand why the ckaid settings failed, after your explanation. I've attached the logs from the last few minutes after "ipsec start; ipsec auto --add mytunnel; ipsec auto --up mytunnel" on both sides. I've also attached the "ipsec status" output from both sides. I've also attached the current ipsec.conf used on both sides. Thanks! 000 using kernel interface: netkey 000 interface br0/br0 ::ec4:7aff:fea9:18de@500 000 interface lo/lo ::1@500 000 interface lo/lo 127.0.0.1@4500 000 interface lo/lo 127.0.0.1@500 000 interface eth1/eth1 192.168.1.1@4500 000 interface eth1/eth1 192.168.1.1@500 000 interface eth1:2/eth1:2 192.168.6.1@4500 000 interface eth1:2/eth1:2 192.168.6.1@500 000 interface eth1:0/eth1:0 192.168.1.2@4500 000 interface eth1:0/eth1:0 192.168.1.2@500 000 interface eth1:1/eth1:1 192.168.1.100@4500 000 interface eth1:1/eth1:1 192.168.1.100@500 000 interface eth1:3/eth1:3 192.168.1.101@4500 000 interface eth1:3/eth1:3 192.168.1.101@500 000 interface br0/br0 68.195.193.42@4500 000 interface br0/br0 68.195.193.42@500 000 interface br0:0/br0:0 68.195.193.44@4500 000 interface br0:0/br0:0 68.195.193.44@500 000 interface virbr0/virbr0 192.168.122.1@4500 000 interface virbr0/virbr0 192.168.122.1@500 000 000 000 fips mode=disabled; 000 SElinux=disabled 000 seccomp=disabled 000 000 config setup options: 000 000 configdir=/etc, configfile=/etc/ipsec.conf, secrets=/etc/ipsec.secrets, ipsecdir=/etc/ipsec.d 000 nssdir=/etc/ipsec.d, dumpdir=/run/pluto, statsbin=unset 000 dnssec-rootkey-file=/var/lib/unbound/root.key, dnssec-trusted= 000 sbindir=/usr/sbin, libexecdir=/usr/libexec/ipsec 000 pluto_version=3.25, pluto_vendorid=OE-Libreswan-3.25 000 nhelpers=-1, uniqueids=yes, dnssec-enable=yes, perpeerlog=no, logappend=yes, logip=yes, shuntlifetime=900s, xfrmlifetime=300s 000 ddos-cookies-threshold=5, ddos-max-halfopen=25000, ddos-mode=auto 000 ikeport=500, ikebuf=0, msg_errqueue=yes, strictcrlpolicy=no, crlcheckinterval=0, listen=, nflog-all=0 000 ocsp-enable=no, ocsp-strict=no, ocsp-timeout=2, ocsp-uri= 000 ocsp-trust-name= 000 ocsp-cache-size=1000, ocsp-cache-min-age=3600, ocsp-cache-max-age=86400, ocsp-method=get 000 secctx-attr-type=32001 000 debug: raw+parsing+emitting+control+lifecycle+kernel+dns+oppo+controlmore+pfkey+nattraversal+x509+dpd+xauth+retransmits+oppoinfo 000 000 nat-traversal=yes, keep-alive=20, nat-ikeport=4500 000 virtual-private (%priv): 000 000 ESP algorithms supported: 000 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192 000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=128, keysizemax=128 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=23, name=ESP_NULL_AUTH_AES_GMAC, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256 000 algorithm AH/ESP auth: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128 000 algorithm AH/ESP auth: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160 000 algorithm AH/ESP auth: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256 000 algorithm AH/ESP auth: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384 000 algorithm AH/ESP auth: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512 000 algorithm AH/ESP auth: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160 000 algorithm AH/ESP auth: id=9,
[Swan-commit] Changes to ref refs/heads/master
New commits: commit b39089eb325226909075f89056ef1ab53fb7c53a Author: Andrew Cagney Date: Thu Oct 4 22:32:34 2018 -0400 ikev1: drop ESP=NULL from default AH and AH+COMP proposals commit b26647403d11e42aa43f402dc15e84650aa00422 Author: Andrew Cagney Date: Thu Oct 4 19:01:27 2018 -0400 ikev1: only accept an ESP/AH proposal when ENCRYPT/AUTHENTICATE policy bit set ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal
On Thu, 4 Oct 2018, Andrew Cagney wrote:
It turns out that, when phase2=ah (i.e., POLICY_AUTHENTICATE), IKEv1's
defaults, since before the start of time have been:
static struct db_prop_conj ah_props[] = {
{ AD(ah_pc) },
#ifdef SUPPORT_ESP_NULL
{ AD(espnull_pc) }
#endif
};
I see it goes back to before 2.0.0 (but after freeswan-2.0.6)
I guess it is cute to propose both so it could work in a migration can of
way to phase out AH for ESP-NULL, but I guess we're long past that point.
Should the second line be dropped?
Yes.
Paul
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal
It turns out that, when phase2=ah (i.e., POLICY_AUTHENTICATE), IKEv1's
defaults, since before the start of time have been:
static struct db_prop_conj ah_props[] = {
{ AD(ah_pc) },
#ifdef SUPPORT_ESP_NULL
{ AD(espnull_pc) }
#endif
};
I.e., in addition to AH, emit an ESP proposal with no encryption.
It's just that it never worked.
Should the second line be dropped?
Andrew
On Thu, 4 Oct 2018 at 18:02, Andrew Cagney wrote:
>
> > In the current code NEXT in the first payload is patched up so the
> > second proposal is be visible. Am trying east:phase2=esp
>
> Yea, that went a little too well :-(
>
> I'm testing the attached to mitigate this new problem, hopefully it
> goes ok and can push.
> I think getting rid of the extra payload is something to sort out later.
>
> Andrew
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal
> In the current code NEXT in the first payload is patched up so the > second proposal is be visible. Am trying east:phase2=esp Yea, that went a little too well :-( I'm testing the attached to mitigate this new problem, hopefully it goes ok and can push. I think getting rid of the extra payload is something to sort out later. Andrew diffs Description: Binary data ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] simple setup
On Thu, 4 Oct 2018, D. Hugh Redelmeier wrote: I keep seeing people, in various venues, saying that wireshark is wonderful. wireguard :) Paul claims that Libreswan configuring is just as simple if the problem is reduced to the scope of wireshark. Paul (or anyone else): can you create simple instructions for setting up a VPN that has feature-parity with Wireshark? https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2 Paul ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] pluto: IKEv2: create functions for boilerplate for starting and ending SK/SKF payloads; Was: [Swan-commit] Changes to ref refs/heads/master
On Fri, 28 Sep 2018 at 19:02, D. Hugh Redelmeier wrote:
> Current oddity: the payload size is padded before fragmentation and
> after. I imagine that only after is correct.
Kind of. It does the following:
- the SK payload length without integrity and padding is saved
const unsigned int len = pbs_offset(_pbs_cipher);
- everything is closed which adds padding and space for integrity and
leaves the outermost REPLY_STREAM PBS containing the final packet size
- the final packet size is then used to decide if fragmentation is needed
if (should_fragment_ike_msg(cst, pbs_offset(_stream), TRUE)) {
- when fragmenting, since LEN is used, the original SK padding is ignored
setchunk(payload, e_pbs_cipher.start, len);
so while padding the unencrypted packet may not be needed, it sure
makes the math of computing the message size easier. I'll likely
assimilate len and add some notes.
BTW, and when fragmenting, this payload gets lost:
if (IMPAIR(ADD_UNKNOWN_PAYLOAD_TO_AUTH)) {
if (!ship_v2UNKNOWN(, "AUTH request")) {
return STF_INTERNAL_ERROR;
}
}
The fragmentation code (reasonably) assumes that everything is inside
of the SK payload.
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] simple setup
On Thu, Oct 04, 2018 at 02:13:47PM -0400, D. Hugh Redelmeier wrote: > I keep seeing people, in various venues, saying that wireshark is > wonderful. > > Paul claims that Libreswan configuring is just as simple if the problem is > reduced to the scope of wireshark. > > Paul (or anyone else): can you create simple instructions for setting up a > VPN that has feature-parity with Wireshark? > > For bounus points: add supplemental instructions for the most compelling > features that a Wireshark user might want but cannot have. > > I'd like a Wiki page or something like it to point people at when they > start talking about Wireshark. Did you mean WireGuard? WireShark is a packet capture tool after all. :) -- Len Sorensen ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] simple setup
I keep seeing people, in various venues, saying that wireshark is wonderful. Paul claims that Libreswan configuring is just as simple if the problem is reduced to the scope of wireshark. Paul (or anyone else): can you create simple instructions for setting up a VPN that has feature-parity with Wireshark? For bounus points: add supplemental instructions for the most compelling features that a Wireshark user might want but cannot have. I'd like a Wiki page or something like it to point people at when they start talking about Wireshark. ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal
For instance, http://testing.libreswan.org/results/testing/v3.22-1007-g86105a8-master/ah-pluto-01/ (its seemingly being doing it for a while): west.conf has: conn westnet-eastnet-ah also=west-east-base also=westnet also=eastnet phase2=ah but in west's logs I see: | ikev1_out_sa pcn: 0 has 1 valid proposals | ikev1_out_sa pcn: 0 pn: 0<1 valid_count: 1 trans_cnt: 1 | emit ISAKMP Proposal Payload: |next payload type: ISAKMP_NEXT_NONE (0x0) |proposal number: 0 (0x0) |protocol ID: PROTO_IPSEC_AH (0x2) |SPI size: 4 (0x4) |number of transforms: 1 (0x1) ... | emitting length of ISAKMP Transform Payload (AH): 28 | emitting length of ISAKMP Proposal Payload: 40 | ikev1_out_sa pcn: 1 has 1 valid proposals | ikev1_out_sa pcn: 1 pn: 0<1 valid_count: 1 trans_cnt: 1 | emit ISAKMP Proposal Payload: |next payload type: ISAKMP_NEXT_NONE (0x0) |proposal number: 1 (0x1) |protocol ID: PROTO_IPSEC_ESP (0x3) |SPI size: 4 (0x4) |number of transforms: 1 (0x1) ... on east, it grabs the first proposal: | parse ISAKMP Proposal Payload: |next payload type: ISAKMP_NEXT_NONE (0x0) |length: 40 (0x28) |proposal number: 0 (0x0) |protocol ID: PROTO_IPSEC_AH (0x2) |SPI size: 4 (0x4) |number of transforms: 1 (0x1) ... | AH IPsec Transform verified unconditionally; no alg_info to check against (it shouldn't see the second proposal because NEXT==0 in the first proposal) In the current code NEXT in the first payload is patched up so the second proposal is be visible. Am trying east:phase2=esp (Found this while testing a local patch that only verifies the (IKEv2 term) Last Substructure field - after all both IKEv1 and IKEv2 have had this working since forever and, unlike the Next Payload chain, computing this ahead of time is "easy") ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-commit] Changes to ref refs/heads/master
New commits: commit 5f814a456c12a2c3d7a62159a537db2ae91c61e4 Merge: 42df32e a31cbd6 Author: Paul Wouters Date: Thu Oct 4 10:21:38 2018 -0400 Merge branch 'master' of vault.libreswan.fi:/srv/src/libreswan commit 42df32ef1aa886f523aa00f41b6c94335e35622e Merge: 210ebc6 7a84136 Author: Paul Wouters Date: Tue Oct 2 14:27:14 2018 -0400 Merge branch 'master' of vault.libreswan.fi:/srv/src/libreswan commit 210ebc6c69e4031fbce49d65c9f409d7e909f1e4 Author: Paul Wouters Date: Tue Oct 2 14:01:50 2018 -0400 testing: avoid race condition in delete-sa-05 ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
