Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW" [SOLVED]
For the sake of discussion and to rule out misunderstanding, here's my complete and working ipsec configuration file: conn L2TP-PSK pfs=no auto=add ikev2=no ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024 esp=aes256-sha256,aes256-sha1,3des-sha1 authby=secret type=transport left=24.196.53.220 leftprotoport=17/1701 right=%any rightprotoport=17/%any dpddelay=30 dpdtimeout=120 dpdaction=clear I tried the suggested esp change: esp=aes256-sha2_512,aes256-sha1,aes256-sha2_256,3des-sha1 The connection loaded without error, but when I tested with both Windows and iPhone, the dread message returned: ...no connection has been authorized with policy PSK+IKEV1_ALLOW I don't have an Android device on hand to test right now, but it would be great to have a "one-size-fits-all" solution. (At least for common consumer devices.) Thanks to all, -Hugh Sparks ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW"
On Fri, 20 Sep 2019 at 17:05, Hugh Sparks wrote:
>
> I tried adding "ikev2=no" and got this error:
>
> Failed to add connection "L2TP-PSK": ike string error: IKE encryption
> algorithm 'aes_gcm256' is not supported by IKEv1
IKEv1 doesn't support AES GCM for IKE (only ESP). One way to get this error is:
- force IKEv1, and
- include ike=aes_gcm256 in the config file
but I didn't notice ike=... in the config? So I'm a little puzzled.
For reference, the code leading into the error is:
if (!LIN(POLICY_AUTH_NEVER, wm->policy) &&
(wm->ike != NULL || c->ike_version == IKEv2)) {
const struct proposal_policy proposal_policy = {
.
.ignore_parser_errors = (wm->ike == NULL),
};
struct proposal_parser *parser =
ike_proposal_parser(_policy);
c->ike_proposals.p =
proposals_from_str(parser, wm->ike);
if (c->ike_proposals.p == NULL) {
pexpect(parser->error[0]); /* something */
loglog(RC_FATAL, "Failed to add
connection \"%s\": ike string error: %s",
wm->name, parser->error);
Notice how it should ignore errors when there's no lke= line.
Andrew
> Perhaps closer...
>
> Thanks again.
>
>
> On 9/20/2019 3:39 PM, Paul Wouters wrote:
> > Add ikev2=no
> >
> > The default changed from v1 to v2
> >
> > Paul
> >
> > Sent from my iPhone
> >
> >> On Sep 20, 2019, at 15:39, Hugh Sparks wrote:
> >>
> >> New list member here.
> >>
> >> I have a server running Libreswan to allow iphone and Windows clients
> >> access to the office LAN. This has worked for many years.
> >> (I never needed to join this list.)
> >>
> >> Recently, I did three server upgrades in quick succession going from
> >> fedora 27 to fedora 30. Something along the way broke the
> >> VPN service.
> >>
> >> When either type of client tries to make a connection, I see this message
> >> in the server journal:
> >>
> >> pluto[16000]: packet from p.q.r.s:t: \
> >> initial Main Mode message received on a.b.c.d:500
> >> but no connection has been authorized with policy PSK+IKEV1_ALLOW
> >>
> >> Working:
> >>
> >> Fedora 27 with libreswan-3.27-1.fc27.x86_64
> >>
> >> Not working:
> >>
> >> Fedora 30 with libreswan-3.29-1.fc30.x86_64
> >>
> >> This command shows everything [OK]
> >>
> >> ipsec verify
> >>
> >> This command adds the connection with no errors reported:
> >>
> >> ipsec auto --add L2TP-PSK
> >>
> >> Some configuration files:
> >>
> >> /etc/ipsec.d/myvpn.conf:
> >>
> >> conn L2TP-PSK
> >> type=transport
> >> authby=secret
> >> pfs=no
> >> auto=add
> >> left=a.b.c.d
> >> right=%any
> >> leftprotoport=17/1701
> >> rightprotoport=17/%any
> >> dpddelay=15
> >> dpdtimeout=30
> >> dpdaction=clear
> >>
> >> ("a.b.c.d" is the public IP address of my server)
> >>
> >> /etc/ipsec.d/myvpn.secrets
> >>
> >> : PSK "some long key phrase"
> >>
> >> I can send more files if necessary, but it appears that the connection
> >> process never gets past "pluto"
> >>
> >> Clients tested are "Windows 10 version 1903" and "iOS 12.4.1"
> >>
> >> The client settings are for L2TP/IPSEC with PSK.
> >>
> >> I have downloaded and searched the mailing list archives.
> >> I found two threads, but none with any clear resolution.
> >>
> >> All suggestions appreciated.
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> --
> >>
> >> Mail: h...@csparks.com Office: 952-955-2800
> >> Mobile: 612-247-2714
> >>
> >> ___
> >> Swan mailing list
> >> Swan@lists.libreswan.org
> >> https://lists.libreswan.org/mailman/listinfo/swan
>
>
> --
>
> Mail: h...@csparks.com Office: 952-955-2800
> Mobile: 612-247-2714
>
> ___
> Swan mailing list
> Swan@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW" [SOLVED]
On Fri, 20 Sep 2019, Hugh Sparks wrote: Subject: Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW" [SOLVED] The Wizard Wooters got me close enough: I added these incantations: ikev2=no ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024\ esp=aes256-sha256,aes256-sha1,3des-sha1 Now Windows and iphone clients work perfectly. Note Android clients will fail, because of their sha2_256 bug. I would recommend: esp=aes256-sha2_512,aes256-sha1,aes256-sha2_256,3des-sha1 That causes us to prefer sha2_512 and sha1 over sha2_256, and should work will Windows. iphone and Android clients. I spent 10 hours on this before I gave up and asked a question. What a great group! Glad we could help! Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan-dev] building rpm target and using namespaces based testing
Hi, I just pushed a change to "make rpm" that auto builds an rpm. Depending on fedora or centos/rhel/foobar it will pick up the right spec file in packaging/XXX/YYY/libreswan.spec. Stock rpms should now be able to run namespace tests without modifications. This was based on Antony's kvm-target.mk work, which I left in the tree untouched for now, until Antony can confirm it is no longer needed for him. Then it can be removed along with packaging/fedora/libreswan-testing.spec.in There is some Makefile.inc.local handling in Antony's version that does not translate to rpmbuilding that hardcodes various features based on distro. But I don't think anything from there is still needed and was done mostly to ack the INITSYSTEM stuff? I can see it might be useful to select the "devel" build, maybe using "make rpm-devel" that will then run rpmbuild --define with_development=1 to get a version with full debug and electric fence. I did not port over the support for RPM_BUILD_CLEAN in "make rpm" because it breaks the subsequent build by deleting the source files (ikev*fax.bz2) when done. I'm thinking we might want to rename the "make install-testing-rpm-dep" into something easier to remember, as I don't think it is a good idea to run this as dependency for "make rpm" as it tries to install and update many rpms :) To run namespace tests on your local fedora/centos/rhel clone, it should work by doing: 1) install the libreswan rpm. You can install your distro's libreswan package (if >= 3.30) or create one from the git tree using: # if you installed in /usr/local, clean that up first # rm -rf /usr/local/libexec/ipsec /usr/local/sbin make install-testing-rpm-dep make rpm # install the resulting rpm, eg: sudo rpm -Uhv /home/paul/RPMS/x86_64/libreswan-3.28-0.rc827_gc9aa82b8a6_master.x86_64.rpm Now it should be possible to run a namespace based test (not all tests are supported yet!) cd testing/pluto/basic-pluto-01 ../../utils/nsrun --ns Thanks to Antony for his work on this! Paul ___ 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 c9aa82b8a66967ef5a2f3410b7b9e9011b8618f4 Author: Paul Wouters Date: Fri Sep 20 19:34:13 2019 -0400 building: update "make rpm" target to actually build the rpms It detects the OS for fedora and rhel derivates based on the kvm-targets.mk version. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW" [SOLVED]
The Wizard Wooters got me close enough: I added these incantations:
ikev2=no
ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024\
esp=aes256-sha256,aes256-sha1,3des-sha1
Now Windows and iphone clients work perfectly.
I spent 10 hours on this before I gave up and asked a question. What a great
group!
Thanks,
-Hugh Sparks
On 9/20/2019 4:05 PM, Hugh Sparks wrote:
I tried adding "ikev2=no" and got this error:
Failed to add connection "L2TP-PSK": ike string error: IKE
encryption algorithm 'aes_gcm256' is not supported by IKEv1
Perhaps closer...
Thanks again.
On 9/20/2019 3:39 PM, Paul Wouters wrote:
Add ikev2=no
The default changed from v1 to v2
Paul
Sent from my iPhone
On Sep 20, 2019, at 15:39, Hugh Sparks wrote:
New list member here.
I have a server running Libreswan to allow iphone and Windows
clients access to the office LAN. This has worked for many years.
(I never needed to join this list.)
Recently, I did three server upgrades in quick succession going from
fedora 27 to fedora 30. Something along the way broke the
VPN service.
When either type of client tries to make a connection, I see this
message in the server journal:
pluto[16000]: packet from p.q.r.s:t: \
initial Main Mode message received on a.b.c.d:500
but no connection has been authorized with policy
PSK+IKEV1_ALLOW
Working:
Fedora 27 with libreswan-3.27-1.fc27.x86_64
Not working:
Fedora 30 with libreswan-3.29-1.fc30.x86_64
This command shows everything [OK]
ipsec verify
This command adds the connection with no errors reported:
ipsec auto --add L2TP-PSK
Some configuration files:
/etc/ipsec.d/myvpn.conf:
conn L2TP-PSK
type=transport
authby=secret
pfs=no
auto=add
left=a.b.c.d
right=%any
leftprotoport=17/1701
rightprotoport=17/%any
dpddelay=15
dpdtimeout=30
dpdaction=clear
("a.b.c.d" is the public IP address of my server)
/etc/ipsec.d/myvpn.secrets
: PSK "some long key phrase"
I can send more files if necessary, but it appears that the
connection process never gets past "pluto"
Clients tested are "Windows 10 version 1903" and "iOS 12.4.1"
The client settings are for L2TP/IPSEC with PSK.
I have downloaded and searched the mailing list archives.
I found two threads, but none with any clear resolution.
All suggestions appreciated.
Thanks!
--
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
___
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 e544648e4279f1b973a01973b9e3b2e2e0acb039 Author: Paul Wouters Date: Fri Sep 20 17:21:01 2019 -0400 testing: update for removed firewall log files from console. These showed up for KVM testing but not for namespace testing. commit 3a63c1cc04379941ae414c713da23593d0e5158c Author: Paul Wouters Date: Fri Sep 20 17:20:25 2019 -0400 testing: sanitize kernel firewall hits away (does this really mean we should just not use LOGDROP but DROP ?) ___ 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 aa9ebfa04957af1f34ccfd40956c4036024be778 Author: Paul Wouters Date: Fri Sep 20 17:07:05 2019 -0400 setup: Detect namespace and start pluto directly without initsystem This is used for namespace testing commit 2025f55312c84749c57df2a9f6994176d563536f Author: Paul Wouters Date: Fri Sep 20 16:55:32 2019 -0400 building: fix make target from install--rpm-dep to install-rpm-dep ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW"
I tried adding "ikev2=no" and got this error:
Failed to add connection "L2TP-PSK": ike string error: IKE encryption
algorithm 'aes_gcm256' is not supported by IKEv1
Perhaps closer...
Thanks again.
On 9/20/2019 3:39 PM, Paul Wouters wrote:
Add ikev2=no
The default changed from v1 to v2
Paul
Sent from my iPhone
On Sep 20, 2019, at 15:39, Hugh Sparks wrote:
New list member here.
I have a server running Libreswan to allow iphone and Windows clients access to
the office LAN. This has worked for many years.
(I never needed to join this list.)
Recently, I did three server upgrades in quick succession going from fedora 27
to fedora 30. Something along the way broke the
VPN service.
When either type of client tries to make a connection, I see this message in
the server journal:
pluto[16000]: packet from p.q.r.s:t: \
initial Main Mode message received on a.b.c.d:500
but no connection has been authorized with policy PSK+IKEV1_ALLOW
Working:
Fedora 27 with libreswan-3.27-1.fc27.x86_64
Not working:
Fedora 30 with libreswan-3.29-1.fc30.x86_64
This command shows everything [OK]
ipsec verify
This command adds the connection with no errors reported:
ipsec auto --add L2TP-PSK
Some configuration files:
/etc/ipsec.d/myvpn.conf:
conn L2TP-PSK
type=transport
authby=secret
pfs=no
auto=add
left=a.b.c.d
right=%any
leftprotoport=17/1701
rightprotoport=17/%any
dpddelay=15
dpdtimeout=30
dpdaction=clear
("a.b.c.d" is the public IP address of my server)
/etc/ipsec.d/myvpn.secrets
: PSK "some long key phrase"
I can send more files if necessary, but it appears that the connection process never gets
past "pluto"
Clients tested are "Windows 10 version 1903" and "iOS 12.4.1"
The client settings are for L2TP/IPSEC with PSK.
I have downloaded and searched the mailing list archives.
I found two threads, but none with any clear resolution.
All suggestions appreciated.
Thanks!
--
Mail: h...@csparks.com Office: 952-955-2800 Mobile:
612-247-2714
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
--
Mail: h...@csparks.com Office: 952-955-2800
Mobile: 612-247-2714
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW"
Add ikev2=no
The default changed from v1 to v2
Paul
Sent from my iPhone
> On Sep 20, 2019, at 15:39, Hugh Sparks wrote:
>
> New list member here.
>
> I have a server running Libreswan to allow iphone and Windows clients access
> to the office LAN. This has worked for many years.
> (I never needed to join this list.)
>
> Recently, I did three server upgrades in quick succession going from fedora
> 27 to fedora 30. Something along the way broke the
> VPN service.
>
> When either type of client tries to make a connection, I see this message in
> the server journal:
>
>pluto[16000]: packet from p.q.r.s:t: \
>initial Main Mode message received on a.b.c.d:500
>but no connection has been authorized with policy PSK+IKEV1_ALLOW
>
> Working:
>
>Fedora 27 with libreswan-3.27-1.fc27.x86_64
>
> Not working:
>
>Fedora 30 with libreswan-3.29-1.fc30.x86_64
>
> This command shows everything [OK]
>
>ipsec verify
>
> This command adds the connection with no errors reported:
>
>ipsec auto --add L2TP-PSK
>
> Some configuration files:
>
> /etc/ipsec.d/myvpn.conf:
>
>conn L2TP-PSK
>type=transport
>authby=secret
>pfs=no
>auto=add
>left=a.b.c.d
>right=%any
>leftprotoport=17/1701
>rightprotoport=17/%any
>dpddelay=15
>dpdtimeout=30
>dpdaction=clear
>
>("a.b.c.d" is the public IP address of my server)
>
> /etc/ipsec.d/myvpn.secrets
>
>: PSK "some long key phrase"
>
> I can send more files if necessary, but it appears that the connection
> process never gets past "pluto"
>
> Clients tested are "Windows 10 version 1903" and "iOS 12.4.1"
>
> The client settings are for L2TP/IPSEC with PSK.
>
> I have downloaded and searched the mailing list archives.
> I found two threads, but none with any clear resolution.
>
> All suggestions appreciated.
>
>
> Thanks!
>
>
>
> --
>
> Mail: h...@csparks.com Office: 952-955-2800 Mobile:
> 612-247-2714
>
> ___
> Swan mailing list
> Swan@lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
[Swan] After upgrade, "No connection has been authorized with policy PSK+IKEV1_ALLOW"
New list member here.
I have a server running Libreswan to allow iphone and Windows clients access to
the office LAN. This has worked for many years.
(I never needed to join this list.)
Recently, I did three server upgrades in quick succession going from fedora 27
to fedora 30. Something along the way broke the
VPN service.
When either type of client tries to make a connection, I see this message in
the server journal:
pluto[16000]: packet from p.q.r.s:t: \
initial Main Mode message received on a.b.c.d:500
but no connection has been authorized with policy
PSK+IKEV1_ALLOW
Working:
Fedora 27 with libreswan-3.27-1.fc27.x86_64
Not working:
Fedora 30 with libreswan-3.29-1.fc30.x86_64
This command shows everything [OK]
ipsec verify
This command adds the connection with no errors reported:
ipsec auto --add L2TP-PSK
Some configuration files:
/etc/ipsec.d/myvpn.conf:
conn L2TP-PSK
type=transport
authby=secret
pfs=no
auto=add
left=a.b.c.d
right=%any
leftprotoport=17/1701
rightprotoport=17/%any
dpddelay=15
dpdtimeout=30
dpdaction=clear
("a.b.c.d" is the public IP address of my server)
/etc/ipsec.d/myvpn.secrets
: PSK "some long key phrase"
I can send more files if necessary, but it appears that the connection process never gets
past "pluto"
Clients tested are "Windows 10 version 1903" and "iOS 12.4.1"
The client settings are for L2TP/IPSEC with PSK.
I have downloaded and searched the mailing list archives.
I found two threads, but none with any clear resolution.
All suggestions appreciated.
Thanks!
--
Mail: h...@csparks.com Office: 952-955-2800
Mobile: 612-247-2714
___
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 e7471653d73eac2900f9348ea12ffdf734b4e7f1
Author: Andrew Cagney
Date: Tue Sep 17 10:59:01 2019 -0400
x508: in signature_check_gen() (nee {RSA,ECDSA}_signature_check_gen())
switch idtoa() to str_id()
As in:
- merge struct tac_state_{ECDSA,RSA} into struct tac_state, add pubkey_type
- merge take_a_crack_PRSA,ECDSA}() into take_a_crack(); use a jambuf to
accumulate tested IDs
- merge try_all_{ECDSA,RSA}_keys() into try_all_keys()
- merge {RSA,ECDSA}_signature_check_gen() into signature_check_gen()
- replace misc switches and hardwired strings with pubkey_type and
pubkey_keyid()
and then finally change idtoa() to str_id(), but now only once
___
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 ca3b5ccdfbb481e850609b71a03d31a5853814c3 Author: Andrew Cagney Date: Wed Sep 18 14:36:52 2019 -0400 x509: add pubkey_keyid(), pubkey_size() and pubkey_ckaid() These three fields really seem to belong in 'struct pubkey' proper. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan-dev] better log content
On Fri, 20 Sep 2019 at 08:27, Antony Antony wrote: > > Making log easier to track, and shorter prefixes, is great idea. However > removing connections prefix completely sounds a bit extreme to me! I think > it is better to make a configurable options for shorter prefixes when you > need it. We need the connection [instance] - its our anchor when tracing things (or at least should be). It's all the guff that comes afterwards. Most notably when OE for instance: "private-or-clear#192.1.2.0/24"[2] 10.0.10.1/32=== ...192.1.2.45 #3: While I'm sure it means something, from my pov it is meaningless. Two things about making this configurable: - it needs a sane default (this is why the gnome dogma I had drilled into me is that configuration options are a sign of compromise and poor design - design the default properly and options aren't required, and no one uses them) - information currently embedded in the prefix will need to be logged explicitly - just like for a shorter prefix, we can't rely on information being available as a side effect of the prefix Having said this, one simple configuration option would be to, when redacting ip-addresses, suppress all that guff (since it will be largely meaningless anyway); however, again, it will force us to log more stuff explicitly. > may be you saw some ugly long lines? share a few real lines you consider as > long? and how often these prefixes appear. > > I think one of our issue is tracking log lines when things fail. When > something fails we dump a lot of stuff. It is hard to make sense of it all, > possibly no prefix would make it worse in cases such as OE, mobike. The correct connection instance is needed as a prefix. > > I vaguely recollect a prefix width(real estate) argument when we introduced > microseconds prefix. May be something like log-prefix-format= > configurable option? Then one could configure a time format and shorter > connection prefixes when you like. > > Also in light of the connections switching issues we currently have I > suggest not to remove connection name prefixes completely. It could be also > useful to debug OE. Why I bring up time prefixing is in most cases with > multiple connections and multiple peers you also need time to make sense of > it all. So connection prefix is not the only long one taking premium space. > > Sep 19 16:36:12.148222: "east-any"[1] 192.1.3.209 #1: STATE_MAIN_R1: sent > MR1, expecting MI2 > > One idea to track IKE and child would be prefix child st with IKE state? > something like #2/1 (or #1320/1088). I can't imagine a one size fit all log > prefix for most debugging situations. I am considering OE, access vpn > certificate and %any, and, just net-to-net usecases. A real world busy log > with IKE scanners in the wild and truncated messages is very hard to track. I've wondered about that. More typically though, our problem is that IKE SA messages - for instance authentication - get logged against the child sa; and/or we log against the wrong instance. > On Tue, Sep 17, 2019 at 05:40:45PM -0400, Andrew Cagney wrote: > > Several things I've noticed while trying to use the log files to track > > down problems: > > > > - tracking a connection instance's IKE and CHILD SAs is painful > > I've an awk script to do this, but the mere existence of this script > > should act as a red flag :-). For instance, to match an IKE_SA with > > its first CHILD_SA the script: > > -> matches /#[0-9]*: Authenticated using RSA/ - the line contains > > both the "connection instance" + #IKE_SA; this is used to map > > "connection instance"->#IKE_SA > > -> matches /#[0-9]*: negotiated connection/ - the line contains > > "connection instance" + #CHILD_SA; combining this with above gets > > #IKE_SA<->#CHILD_SA > > yuck! Imagine a shop where - the sales assistant, not yet knowing your identity, puts all of your purchases on some other random customer's card - then when you prove identity, the charges against the random customer hopefully all get reversed and you get the bill /me thinks that the previous customer, with a bill full of of bogus charges and reversals, isn't going to be happy. To me that's what we're doing. > > - the connection prefix seems like far too much information, > > especially when it is constantly repeated and redacted; for instance > > in: > > ... "my-connection"[1234] #100: ... > > is just wasted real estate; would it be better to dump all the > > connection instance details once as a line > > > > - as a follow-on it would be nice if the connection instance prefix > > stopped changing between log lines > > because the prefix is generated dynamically it evolves as the > > connection information gets changed; again a log line once one all > > changes are done > > > > Andrew > > ___ > > Swan-dev mailing list > > Swan-dev@lists.libreswan.org > > https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] better log content
Making log easier to track, and shorter prefixes, is great idea. However removing connections prefix completely sounds a bit extreme to me! I think it is better to make a configurable options for shorter prefixes when you need it. may be you saw some ugly long lines? share a few real lines you consider as long? and how often these prefixes appear. I think one of our issue is tracking log lines when things fail. When something fails we dump a lot of stuff. It is hard to make sense of it all, possibly no prefix would make it worse in cases such as OE, mobike. I vaguely recollect a prefix width(real estate) argument when we introduced microseconds prefix. May be something like log-prefix-format= configurable option? Then one could configure a time format and shorter connection prefixes when you like. Also in light of the connections switching issues we currently have I suggest not to remove connection name prefixes completely. It could be also useful to debug OE. Why I bring up time prefixing is in most cases with multiple connections and multiple peers you also need time to make sense of it all. So connection prefix is not the only long one taking premium space. Sep 19 16:36:12.148222: "east-any"[1] 192.1.3.209 #1: STATE_MAIN_R1: sent MR1, expecting MI2 One idea to track IKE and child would be prefix child st with IKE state? something like #2/1 (or #1320/1088). I can't imagine a one size fit all log prefix for most debugging situations. I am considering OE, access vpn certificate and %any, and, just net-to-net usecases. A real world busy log with IKE scanners in the wild and truncated messages is very hard to track. On Tue, Sep 17, 2019 at 05:40:45PM -0400, Andrew Cagney wrote: > Several things I've noticed while trying to use the log files to track > down problems: > > - tracking a connection instance's IKE and CHILD SAs is painful > I've an awk script to do this, but the mere existence of this script > should act as a red flag :-). For instance, to match an IKE_SA with > its first CHILD_SA the script: > -> matches /#[0-9]*: Authenticated using RSA/ - the line contains > both the "connection instance" + #IKE_SA; this is used to map > "connection instance"->#IKE_SA > -> matches /#[0-9]*: negotiated connection/ - the line contains > "connection instance" + #CHILD_SA; combining this with above gets > #IKE_SA<->#CHILD_SA > yuck! > > - the connection prefix seems like far too much information, > especially when it is constantly repeated and redacted; for instance > in: > ... "my-connection"[1234] #100: ... > is just wasted real estate; would it be better to dump all the > connection instance details once as a line > > - as a follow-on it would be nice if the connection instance prefix > stopped changing between log lines > because the prefix is generated dynamically it evolves as the > connection information gets changed; again a log line once one all > changes are done > > Andrew > ___ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] hostpairs and instances, was Re: ikev2-10-2behind-nat and 80d68d57a57
On Thu, 19 Sep 2019 at 22:06, Paul Wouters wrote:
>
> On Thu, 19 Sep 2019, Andrew Cagney wrote:
>
> > seems to be a little too aggressive. For instance in
> > ikev2-10-2behind-nat on east I see:
>
> I disagree.
>
> > - north establishes #1,#2 creating instance "pool-eastnet-ikev2"[1]
> > with cert E=user-no...@testing.libreswan.org
> > - road starts establishing #3,#4 and grabs connection instance
> > "pool-eastnet-ikev2"[1]
> > - during authentication "pool-eastnet-ikev2"[1] is found unsuitable -
> > E=user-r...@testing.libreswan.org !=
> > E=user-no...@testing.libreswan.org I'm guessing
> >
> > the old code would then stumble on, eventually going back to the
> > original connection and re-refining it (the patch stops this):
>
> The core of the problem is that we use refine_host_connection() in
> IKEv2, even though that function is written for IKEv1. In IKEv1,
> you only have authentication material, so you cannot refine based
> on traffic selectors until after authentication is done and a new
> packet for quick mode appears.
>
> So the IKEv2 code, instead of talking IKE ID's plus Traffic Selectors
> into account for refining the connection, needs to continue whether or
> not there is an AUTH issue. This could be many kind of failures (wrong
> CA, wrong IKE ID, IKE ID not on certificate). Currently, I think if the
> certificate does not validate, it will fail without looking for other
> connections (with possibly other CA's that would make it succeed). If
> the certificate validates, it checks the IKE ID with the certificate IDs
> (SAN) but has to continue when failing. Then it hopefully switches once
> it hits the traffic selector code, and finds a better conn from a traffic
> selector point of view. But then when it switches to that conn, it has to
> retroactively check if the switched conn allows the same authentication
> properties. Eg the CERT could now have the right IKE ID on the SAN,
> but it could also be that this connection now has the wrong CA and the
> previous certificate validation is not valid for this conn.
>
> > "pool-eastnet-ikev2"[1] 192.1.2.254 #3: switched from
> > "pool-eastnet-ikev2"[1] 192.1.2.254 to "pool-eastnet-ikev2"
> > | rw_instantiate() instantiated "pool-eastnet-ikev2"[2] 192.1.2.254
> > for 192.1.2.254
> > "pool-eastnet-ikev2"[2] 192.1.2.254 #3: Authenticated using RSA
> >
> > (#include rant about how connection prefixes changing randomly and
> > meaninglessly)
>
> It does not. If the name changes, it means you switched connections, and
> that there be dragons.
This is exposing internal brokenness in the log file - is logging
against "pool-eastnet-ikev2"[1] which is bogus doomed and confusing.
Either not having the connection prefix, or having the connection root
would be more meaningful.
> > Presumably tweaking the connection would fix this?
> >
> > But here's my question. Why was road assigned the instance
> > "pool-eastnet-ikev2"[1] to start with? Would it be better to:
> > - in the responder, on first contact, assign a non-template connection
> > to the state
> > - during auth, when everything is known, switch to or refine the
> > connection instance as needed
>
> Yes, that is one of the proposals I've suggested in the past, but it has
> a problem too. If you don't have the real connection, you don't know
> what DH / KE is allowed, so you have to accept everything, and you
> cannot ever return INVALID_KE, because you accepted whatever they gave
> you in IKE_SA_INIT, and now in IKE_AUTH you realise that the current
> connection does not support the specific DH group.
Yes. But tink of these as separate problems to solve:
- we should select a connection "base" and then refine it, not select
an instance and then try digging out of a hole
- we need a way to handle overlapping connections with different
crypto suites; for instance proposing the intersection; or only
allowing when their suites are the same
> So there is some merit in trying to find the best one in IKE_SA_INIT,
> at least one with a matching DH / KE. But it's a poor guarantee for
> knowing you are on the right conn.
>
> Furthermore, I have a pending change that I had hoped to talk with Hugh
> about before commiting related to this:
I'm not planning on going near this code.
> diff --git a/programs/pluto/ikev2_ts.c b/programs/pluto/ikev2_ts.c
> index 3ae176e8a3..d8470f1072 100644
> --- a/programs/pluto/ikev2_ts.c
> +++ b/programs/pluto/ikev2_ts.c
> @@ -780,8 +780,8 @@ bool v2_process_ts_request(struct child_sa *child,
> if (hp == NULL)
> continue;
>
> - for (struct connection *d = hp->connections;
> -d != NULL; d = d->hp_next) {
> + struct connection *d;
> + for (d = connections; d != NULL; d = d->ac_next) {
> /* groups are templates instantiated as
> GROUPINSTANCE */
> if (d->policy & POLICY_GROUP) {
>
Re: [Swan-dev] extract MAC address from "ip -o link sow dev eth0" - awk
Hello Antony,
pá 20. 9. 2019 v 11:09 odesílatel Antony Antony napsal:
> programs/_updown.netkey/_updown.netkey.in
> - if [ -r /sys/class/net/${iface}/address ]; then
> - macaddr=$(cat /sys/class/net/${iface}/address)
> + if ip -o link show dev ${iface}; then
> + macaddr=$(ip -o link show dev ${iface} | awk '$2 !=
> "${iface}:" {print $(NF-4)}')
>
> I am not sure "NF-4" is good idea. The fear is a hardcoded position of the
> MAC address may not very portable to older versions "ip". Will it be always
> at a -4 in "ip -o" output. If not we need an awk magic line.
>
> Tuomo, would you write a better awk oneliner?
I'm not Tuomo, but are we limited to 'awk'? Can you go with e.g. sed?
(+ -- to match even for interfaces with longer MAC addresses, I've
seen it with some storage devices)
# sed -E 's/.*ether\ ([0-9a-f:]{17}+)\ brd.*$/\1/'
> Also this has two "ip -o" calls may be we can do in one?
I think you don't need to check for the "ip -o" return value, $macaddr
will be an empty string when the device does not exist.
Have fun,
Stepan
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] extract MAC address from "ip -o link sow dev eth0" - awk
There is an annoying issue when running inside docker/namespace. The proxy
arp function in _updown.netkey would fails. It has been bugging me for
years!
Now I tracked it down to two lines in _updown.netkey.in
Here my first attempt to replace it using "ip link " command.
programs/_updown.netkey/_updown.netkey.in
- if [ -r /sys/class/net/${iface}/address ]; then
- macaddr=$(cat /sys/class/net/${iface}/address)
+ if ip -o link show dev ${iface}; then
+ macaddr=$(ip -o link show dev ${iface} | awk '$2 != "${iface}:"
{print $(NF-4)}')
I am not sure "NF-4" is good idea. The fear is a hardcoded position of the
MAC address may not very portable to older versions "ip". Will it be always
at a -4 in "ip -o" output. If not we need an awk magic line.
Tuomo, would you write a better awk oneliner?
Also this has two "ip -o" calls may be we can do in one?
May be match something like "link/ether 96:01:66:8b:74:96 brd" and just
print the MAC e.g 96:01:66:8b:74:96
background:
inside namespace/docker "eth0" is a valid interface name.
However, it does not exist /sys/class/net/* because it is veth type. AFIK
for veth only one end appear in /sys/class/net/${iface}. Note Namespaces and
host seems to share /sys/class/*
Here is the output for reference.
ip -o link show dev eth0
6508: eth0@if6509: mtu 1500 qdisc noqueue
state UP mode DEFAULT group default qlen 1000\link/ether 96:01:66:8b:74:96
brd ff:ff:ff:ff:ff:ff link-netnsid 0
regards,
-antony
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
