Project

General

Profile

Issue #1142

Switching to peer config that is set to 'authby=never'

Added by Emeric Poupon almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.3.3
Resolution:
No change required

Description

Hello,

I have in my ipsec.conf a bypass policy:

conn "loopback_bypass" 
        type=passthrough
        leftsubnet=127.0.0.0/8
        rightsubnet=0.0.0.0/0
        auto=route
        authby=never

conn "site_1" 
...

In the logs I can see charon is trying to switch to this connection settings:

Sep 26 03:26:10 12[CFG] <site_1|1> selected peer config 'site_1' inacceptable: non-matching authentication done
Sep 26 03:26:10 12[CFG] <site_1|1> switching to peer config 'loopback_bypass'
Sep 26 03:26:10 12[CFG] <loopback_bypass|1> constraint check failed: RULE_CRL_VALIDATION is STALE, but requires at least GOOD
Sep 26 03:26:10 12[CFG] <loopback_bypass1> selected peer config 'loopback_bypass_ip4' inacceptable: non-matching authentication done
Sep 26 03:26:10 12[CFG] <loopback_bypass|1> no alternative config found
Sep 26 03:26:10 12[IKE] <loopback_bypass|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Sep 26 03:26:10 12[ENC] <loopback_bypass|1> added payload of type NOTIFY to message
Sep 26 03:26:10 12[ENC] <loopback_bypass|1> order payloads in message
Sep 26 03:26:10 12[ENC] <loopback_bypass|1> added payload of type NOTIFY to message
...

ipsec statusall :
...
loopback_bypass:  %any...%any  IKEv1/2
loopback_bypass:   local:  uses public key authentication
loopback_bypass:   remote: uses public key authentication
loopback_bypass:   child:  127.0.0.0/8=== 0.0.0.0/0PASS
...

That behavior is not legitimate and misleading.
Questions are:
- is there any side effect? Is it possible that this switch prevents another connection to be chosen in some scenario?
- is it possible to ignore these connections where enumerating candidates? It does not seem to be that easy, since starter has the 'never' keyword kwnowledge, but charon does not have it.

Best regards,

History

#1 Updated by Emeric Poupon almost 7 years ago

At least one case is annoying.

A remote GW tries to set up a tunnel using a PKI
No peer configuration matches on the local side.

In the log, we have very misleading errors like :
Oct 2 17:31:01 11[CFG] <1> candidate "loopback_bypass", match: 1/1/24 (me/other/ike)
...
Oct 2 17:31:01 11[CFG] <loopback_bypass|1> no IDr configured, fall back on IP address
...
Oct 2 17:31:01 11[IKE] <loopback_bypass|1> no private key found for 'MYREMOTEADDR'
...
Oct 2 17:31:01 11[SNS] <loopback_bypass|1> Peer rejected local authentication
...

#2 Updated by Noel Kuntze almost 7 years ago

is there any side effect? Is it possible that this switch prevents another connection to be chosen in some scenario?

Nope.

is it possible to ignore these connections where enumerating candidates? It does not seem to be that easy, since starter has the 'never' keyword kwnowledge, but charon does not have it.

Try setting left=127.0.0.1 and right=127.0.0.1. That should work, because the right and left side will not match.

You do not need that bypass policy, assuming you do not use 127.0.0.1/8 on the local network for routing. XFRM is disabled on the loopback interface. You can check that with sysctl net.ipv4.conf.lo.disable_xfrm.

#3 Updated by Tobias Brunner almost 7 years ago

  • Tracker changed from Bug to Issue
  • Status changed from New to Feedback

Yep, authby=never never had a meaning in charon. authby is a legacy option anyway (as charon supports multiple authentication rounds and asymmetric authentication in IKEv2). It also has no corresponding setting in VICI. So since it has no meaning the default applies, i.e. pubkey, which is definitely not useful for shunt connections. However, if you set left|right to appropriate values (as recommended by Noel) or define such configs after all the others in your config file this is usually not a problem.

Another issue with authby=never is that it might get confusing if we ever implement RFC 7619 where left|rightauth=null (or never|none) becomes a valid option.

But the configuration of shunt policies is admittedly a bit strange. In swanctl.conf they are assigned as children (with mode=drop|pass) to an IKE/peer config, which does not make that much sense. The same could also happen, though, when using ipsec.conf if connections are merged and shunt policies might get adopted by an existing peer config (e.g. if lots of options are inherited by shunt configs from conn %default). However, since we deal with complete configs in the stroke plugin, which get merged explicitly, it might be easier to handle shunt connections specially (e.g. to avoid enumerating them as valid candidates). In the vici plugin we would have to process (e.g. remove/move) the peer configs that only have shunt children assigned after parsing and loading the complete config. Might be easier to define them in a separate shunts section (with a reduced set of options). In particular because child configs with MODE_PASS/DROP are strangely never explicitly filtered, so they are actually considered when negotiating CHILD_SAs if they are assigned to a peer config.

#4 Updated by Emeric Poupon almost 7 years ago

Thanks for your answers!

I have tested what Noel suggested, and indeed, it seems to do the job.
Please note the behavior is not exactly the same as before.

From the remote host:

1- fallback on a shunt connection


# ipsec up "TEST" 
initiating IKE_SA TEST[2] to fd56::120
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
sending packet: from fd56::110[500] to fd56::120[500] (404 bytes)
received packet: from fd56::120[500] to fd56::110[500] (365 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(HASH_ALG) ]
received cert request for "C=AT, ST=TEST, L=TEST, O=TEST, OU=TEST, CN=IPSEC TEST" 
received cert request for "C=AM, ST=IPSEC TEST2, L=IPSEC TEST2, O=IPSEC TEST2, OU=IPSEC TEST2, CN=IPSEC TEST2" 
sending cert request for "C=AM, ST=IPSEC TEST2, L=IPSEC TEST2, O=IPSEC TEST2, OU=IPSEC TEST2, CN=IPSEC TEST2" 
sending cert request for "C=AT, ST=TEST, L=TEST, O=TEST, OU=TEST, CN=IPSEC TEST" 
authentication of 'C=AT, ST=TEST, L=TEST, O=TEST, OU=TEST, CN=TEST_110, E=FW_110@TEST.org' (myself) with RSA_EMSA_PKCS1_SHA256 successful
sending end entity cert "C=AT, ST=TEST, L=TEST, O=TEST, OU=TEST, CN=TEST_110, E=TEST_110@TEST.org" 
establishing CHILD_SA TEST
generating IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(EAP_ONLY) ]
sending packet: from fd56::110[500] to fd56::120[500] (1884 bytes)
received packet: from fd56::120[500] to fd56::110[500] (76 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
Peer rejected local authentication
establishing connection 'TEST' failed

2- no fallback


# ipsec up "TEST" 
initiating IKE_SA TEST[3] to fd56::120
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
sending packet: from fd56::110[500] to fd56::120[500] (404 bytes)
received packet: from fd56::120[500] to fd56::110[500] (36 bytes)
parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN notify error
The received IKE_SA proposals did not match: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:BLOWFISH_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
establishing connection 'TEST' failed

This example shows why I wanted to be really sure the shunt connections do not have any side effect.
However, the suggested solution seems to be fine for me.

#5 Updated by Tobias Brunner almost 7 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF