[Swan-commit] Changes to ref refs/heads/master
New commits: commit f8fd9daaf72d21161ec6082a3d3b00947027aa95 Author: Andrew Cagney Date: Mon Sep 30 13:08:00 2019 -0400 dncheck: test x509 / rfc4514 code, fix bugs in jam_raw_dn(nss_compatible): - if the OID is unknown, emit N.M.O.P and not 0xXXX - if the OID is unknown, dump the value's BER as #HEX - escape '"', '+', ',', ';', '<', '>', or '\' using \CHAR - escape non-printable ascii using \XX - escape leading ' ' using \CHAR (same for '#' but ...) - work around NSS bug by dumping value with leading # as #BER - work around NSS bug by escaping '#' and '=' which means the text should always be ascii; also hack up atodn() so that it doesn't toally barf on the above; could do with tests with bad input. Also and note about ,, and // hacks to atodn() - came in via RHBZ#868987; see 9a2ce7936885775ba0f134f200469f34034429ca and b918a5176a09b558af50518f19f39e69e9b54c19. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-dev] comment on version.mk - make rpm
a minor comment. I noticed a commit to fix version number in "make rpm"
https://github.com/libreswan/libreswan/commit/b68c5a33261ea07defa119edee97e4a495588d6c
It is good improvement to "make rpm".
However, there is another way to set pluto --version,
IPSECVERSION=%{IPSECVERSION}
https://github.com/libreswan/libreswan/blob/master/packaging/fedora/libreswan-testing.spec#L18
setting IPSECVERSION is also used in Debian and OpenWRT packaging. May be it
is better to use this method instead of b68c5a.
Having two different ways to set pluto --version is likely to end up in
trouble. Copying version.mk is possibly dificult to do in Debian or openwrt.
Debian run the make in place and not in seperate directory like ~/rpmbuild/
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan] Frequent dropped connections follow-up
Hi, back in May I reported an issue involving two cable modems and
dropping the connections for no apparent reason. I believe Paul said
it was a deadlock issue that would be fixed in 3.28, but it continues
today with 3.29 on fedora30.
The issue is that two systems, both of which are connected to the
Internet via cable modems, frequently lose their connection and
usually require restarting one or both connections in order to
reconnect, although sometimes "ipsec auto --up "
works.
My previous report is here:
https://lists.libreswan.org/pipermail/swan/2019/003189.html
I'm really not sure what further information I should provide to help
troubleshoot this. This is the config from the "remote" system with a
dynamic IP provided by Optimum.
conn orion-wyckoff
ikev2=insist
authby=rsasig
auto=start
interfaces=%defaultroute
dpddelay=10
dpdtimeout=90
dpdaction=clear
rightsubnets={192.168.11.0/24,192.168.10.0/24}
rightid=@wyckoff-orion
right=wyckoff.example.com
rightrsasigkey=0sAwEAAd4...
leftid=@orion-wyckoff
left=orion.example.com
leftsubnets={192.168.1.0/24,192.168.6.0/24}
leftrsasigkey=0sAwEAAeSMFxvoJ...
Here is the config for the "local" system with a static IP provided by
Optimum. This system also has several other VPNs also using
libreswan-3.29 that don't generally have the same problem.
conn orion-wyckoff
ikev2=insist
authby=rsasig
auto=add
dpddelay=10
dpdtimeout=90
dpdaction=clear
rightid=@wyckoff-orion
rightsubnets={192.168.11.0/24,192.168.10.0/24}
right=wyckoff.example.com
rightrsasigkey=0sAwEAAd4EeK...
leftid=@orion-wyckoff
left=orion.example.com
leftsubnets={192.168.1.0/24,192.168.6.0/24}
leftrsasigkey=0sAwEAAeSMFxvoJaP5...
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] windows 10 Policy Match Error
Hi Again, Turns out that brand new laptop still does connect so long as I do not specify an ike/esp line. in the debug logs, it seems to choose this proposal: IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match] Not sure how that helps me get the other ones connected, but it is interesting, at least... In the debug logs, I think this is the line that indicates what windows is proposing that libreswan is rejecting: pluto[30250]: "rw-ikev2"[1] 50.117.137.129 #5: no local proposal matches remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;ESN=DISABLED 2:ESP:ENCR=3DES;INTEG=HMAC_SHA1_96;ESN=DISABLED so I put this in my conn: esp=aes256-sha1-modp1024 and the connection worked. so I go back to the wiki, which tells me to use this: esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1,aes_gcm256-null;modp1024 and I believe from reading the man page on the topic that this should also match the aes256-sha1-modp1024 proposal, however evidence clearly indicates it does not. I tried messing with the syntax of the wiki line a bit, but nothing I did worked, really not clear what I am missing. Did I find a problem that isn't supposed to be there? Or am I just stuck with only accepting the single esp proposal? How do I interpret this and translate it to On 2019-10-04 9:30 a.m., Computerisms Corporation wrote: Hi Nels and Paul, Apologies for the delayed reply, I was overly busy at the moment and duct taped the immediate issue with some iptables rules and port forwarding. But need something better and I am back to trying to solve this now. I tried setting ikev2 from yes to no, sadly did not change the situation. Oddly enough I put a brand new setup together about a week ago, with a brand new laptop, and it connected fine. Yesterday I configured a bunch of other laptops to connect to that same firewall, and now nothing connects to it. That causes me to wonder if a windows update that wasn't installed to begin with is there now on the brand new laptop. Regardless, I faced this problem with windows7 way back, and I managed to solve it that time with a post I found on the strong swan list. So my instinct is telling me I need to find the correct ike=/esp= lines to fix this problem. I did find a post from strong swan from Oct/Nov 2018: https://wiki.strongswan.org/issues/2808 But none of those cipher lines worked. Similarly there are a set of ciphers listed on the libreswan wiki under the no_proposal_chosen section, and those are not working either. I am thinking the next task is to go through the debug log and find out what proposals windows is expecting, and try to construct appropriate ike=/esp= lines. I found the parts of the man page that explain how to write the ciphers, but having a hard time translating the log entries into valid cipher descriptions for the conf file. Posting the debug log here in case any one is interested in having a look... ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan-commit] Changes to ref refs/heads/master
New commits: commit 6494d0ccbeec886eb05136e5e5d19969bf6abcc9 Author: Andrew Cagney Date: Fri Oct 4 14:07:48 2019 -0400 ip: restore .mask_cnt = 128 Merge botch in f8ef456c439c51e06ac4b81238bc2d6fa50e9785. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/master
New commits: commit 92bd2e94d01733568be946381926826d8424671a Author: Tuomo Soini Date: Fri Oct 4 19:44:53 2019 +0300 Revert "Makefile: fix "make rpm" target to work with VERSION_ADD_GIT_DIRTY=true" This reverts commit f29db848b6127a976063b5084a57cc4345a3c6c5. This didn't fix the actual problem which is that tarball is created with git archive which doesn't include local changes. So it is better break when tree is dirty. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/master
New commits: commit f29db848b6127a976063b5084a57cc4345a3c6c5 Author: Tuomo Soini Date: Fri Oct 4 17:17:47 2019 +0300 Makefile: fix "make rpm" target to work with VERSION_ADD_GIT_DIRTY=true ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan] Need Help
Hi, I am using Libreswan IPSec VPN in transport mode. (L2tpv3 over IPSec). We see a lag in one of our applications running between sites. Normally, it is 16 to 20 ms. however, *every 7:45* it shows some lag / delay in application upto 400ms. We tested the performance of this connection. The communication delay (from end device to end device). During these tests we recognized a significant delay about every 7h 45min of 190 ms to 700 ms . After checking router config and logs *we assumed the SA key exchange is responsible for the delay. *The SA lifetime was configured to 8h. After changing the lifetime to 1h the delay occurred about every 45 min. This could be the CPU or Libreswan could be optimized to avoid this issue ? Any help would highly be appreciated. Thanks. ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan-commit] Changes to ref refs/heads/master
New commits: commit 25880e53d1d63154ea9633464476e80cbdf3246d Author: Andrew Cagney Date: Thu Oct 3 21:38:08 2019 -0400 ip: add said_addresss() and more notes commit f8ef456c439c51e06ac4b81238bc2d6fa50e9785 Author: Andrew Cagney Date: Thu Oct 3 11:04:13 2019 -0400 ip_info: add .any_endpoint for [::]:0 or 0.0.0.0:0, test commit b4ec1a031c8dd24cf901311890253dea49bb441a Author: Andrew Cagney Date: Thu Oct 3 11:04:50 2019 -0400 ipcheck: move CHECK_ADDRESS() to ipcheck.h header so it can be shared ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
