Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

> On Mar 29, 2018, at 5:46 AM, Tobias Brunner  wrote:
> 
> Hi Rich,
> 
>> Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET]  
>> sending packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes)
>> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET]  
>> received packet: from 13.88.23.150[1031] to 172.17.128.86[500] (140 bytes)
> 
> Yeah, that's the problem.  Why is a packet first accepted on port 500
> and then returned from port 1031?  You wrote Azure has a "less-static
> NAT service".  But how does that makes sense?  You configure the NAT to
> forward port 500 to your VPN gateway and then it maps the response from
> that port to a new external port instead of using the existing static
> NAT mapping?

That’s exactly what’s happening, yes. There’s two different “nat settings" — 
one to _always_ forward 500/4500 through to the host for incoming packets 
(static “port forwarding” NAT) and a separate connection-tracking kind of NAT 
which handles the outgoing connections (and which _usually_ maps 500->500 and 
4500->4500 except that sometimes it remaps.)

Azure has, thankfully, abandoned this model in its newer offerings but alas, 
those aren’t the ones we’re using. 

(Not a VPN gateway, though, all transport mode, full mesh.)

> Since the remote port is now not 500 anymore strongSwan won't switch to
> remote port 4500:

> we wouldn't have been able to send a message to it as we only
> add a non-ESP marker if neither port is 500

Aha, those two things were my working theory so it’s good to have them 
confirmed.

>> Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> sending packet: from 
>> 10.0.0.59[500] to 54.186.244.242[500] (524 bytes)
>> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from 
>> 10.0.0.59[500] to 54.186.244.242[4500] (36 bytes) 
>> 
>> ^ I don't know why this packet went from 500 to 4500
> 
> Because it received it on that port.  But it's strange that this even
> works.  The initiator uses port 4500 and sends to port 1031, so it
> should add a non-ESP marker.  However, as responder the non-ESP marker
> is currently only stripped from the packet if neither port is 500.  Here
> the responder's local port is 500, so the marker is not removed and
> parsing the IKE header should fail.  Did you patch that?  If not, what
> version are you using?

I haven’t patched anything. We’re using 5.6.1 from Ubuntu unstable (backported 
to Trusty/Xenial). I don’t see any relevant patches in the Ubuntu package, but 
on the other hand, parsing the IKE header _does_ fail, so I think we’re getting 
expected behaviour.

> I pushed a patch to the port-float branch that might help.  And as a
> workaround you could just initiate the connection directly to port 4500
> (remote_port=4500), and from port 4500 (local_port=4500).  See [1].

I’ll give both of those a shot and report back. (It’s not clear to me from the 
NatTraversal page if this will work with IKEv1 but I’ll find out soon enough.)

Thanks!

  -Rich

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

Hi Tobias and list,

I was able to duplicate my issues around NAT remapping in Azure with StrongSwan 
at both ends, so now Racoon is completely out of the picture.

I captured some more detailed logs of the situation. In the logs below, 
stg-vault-zk04 is in AWS and has static NAT in front of it (i.e. 500->500, 
4500->4500); stg-vault-zk06 (second log) is in Azure, with a less-static NAT 
service in front of it (it passes 500 and 4500 in to 500 and 4500 on the host, 
but outgoing traffic on 500/4500 will sometimes be remapped to ports around 
1024).

The problem is that sometimes ESP traffic is sent to the IKE port (and possibly 
vice versa). I’ve ^marked a few places in the logs where things happen that I 
think are relevant.

One challenge is that we can’t force the remapping to happen, so we’re at the 
whim of Azure for trying to reproduce this.


Config on stg-vault-zk06: 

connections {
stg-vault-zk04_0 {
  include swanctl-ike.conf
  local_addrs = 10.0.0.59
  remote_addrs = 54.186.244.242
  children {
stg-vault-zk04_0 {
  include swanctl-ipsec.conf
}
  }
}
}

On stg-vault-zk04:

connections {
stg-vault-zk06_0 {
  include swanctl-ike.conf
  local_addrs = 172.17.128.86
  remote_addrs = 13.88.23.150
  children {
stg-vault-zk06_0 {
  include swanctl-ipsec.conf
}
  }
}
}

swanctl-ike.conf contains this on both:

version = 1
local { auth = psk }
remote { auth = psk }
proposals = aes128-sha256-modp3072
encap = yes
dpd_delay = 20
# This avoids interop issue between strongswan and racoon involving
# fragmented IKE messages immediately after racoon restart. Once our whole
# fleet is StrongSwan we may wish to return this to the default of "yes"
# (or not, since our IKE messages are typically small enough to not require
# fragmentation). See SRE-1203.
fragmentation = no
reauth_time = 23h
over_time = 1h
rand_time = 1h

swanctl-ipsec.conf contains this on both:

mode = transport
start_action = trap
esp_proposals = aes128-sha1-modp3072
life_time = 8h
rekey_time = 7h
rand_time = 1h

As for PSKs: I’m confident that the PSKs are configured correctly because these 
hosts communicate successfully when port remapping doesn’t get in the way.

After running “swanctl -i --child stg-vault-zk06” on stg-vault-zk04: 

Mar 27 15:47:35 stg-vault-zk04 charon: 15[CFG] vici initiate 'stg-vault-zk06_0'
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
ISAKMP_VENDOR task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
ISAKMP_CERT_PRE task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
MAIN_MODE task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
ISAKMP_CERT_POST task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
ISAKMP_NATD task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  queueing 
QUICK_MODE task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  
activating new tasks
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]    
activating ISAKMP_VENDOR task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]    
activating ISAKMP_CERT_PRE task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]    
activating MAIN_MODE task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]    
activating ISAKMP_CERT_POST task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]    
activating ISAKMP_NATD task
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  sending 
XAuth vendor ID
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  sending 
DPD vendor ID
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  sending 
NAT-T (RFC 3947) vendor ID
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  sending 
draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  
initiating Main Mode IKE_SA stg-vault-zk06_0[318] to 13.88.23.150
Mar 27 15:47:35 stg-vault-zk04 charon: 14[IKE]  IKE_SA 
stg-vault-zk06_0[318] state change: CREATED => CONNECTING
Mar 27 15:47:35 stg-vault-zk04 charon: 14[CFG]  
configured proposals: 
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
Mar 27 15:47:35 stg-vault-zk04 charon: 14[ENC]  
generating ID_PROT request 0 [ SA V V V V ]
Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET]  sending 
packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes)
Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET]  received 
packet: from 13.88.23.150[1031] to 172.17.128.86[500] (140 bytes)

^ first non-port-500 packet from zk04's perspective. this says to me that nat 
port 1031 is mapped to port 500 on stg-vault-zk06

Mar 27 15:47:35 stg-vault-zk04 charon: 07[ENC]  parsed 

Re: [strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

Hey Tobias,

Thanks for your quick response.

> On Mar 23, 2018, at 1:20 PM, Tobias Brunner  wrote:
> 
> Hi Rich,
> 
>> 1. IKE and ESP SAs are established normally with NAT-T, i.e. 500:4500.
>> 2. NAT remapping occurs within Azure, at which point StrongSwan sees IKE 
>> packets come from port 1027 instead of 500. (i.e. instead of 500:500 it’s 
>> 500:1027).
> 
> And what happens to port 4500?  Why would there even be further messages
> from port 500 for existing IKE_SAs?

Unfortunately Azure doesn’t let you inspect the NAT table so I can’t see what’s 
going on there, but we do have static inbound (pass-through) NAT for 500 and 
4500. 

The messages are indeed DPDs.

StrongSwan says:

Mar 23 18:42:15 aws-host charon-systemd: 14[NET]  received 
packet: from 104.x.x.x[1987] to 172.17.128.205[4500] (108 bytes)
Mar 23 18:42:15 aws-host charon-systemd: 14[ENC]  parsed 
INFORMATIONAL_V1 request 3041276986 [ HASH N(DPD) ]
Mar 23 18:42:15 aws-host charon-systemd: 14[ENC]  generating 
INFORMATIONAL_V1 request 1272875000 [ HASH N(DPD_ACK) ]
Mar 23 18:42:15 aws-host charon-systemd: 14[NET]  sending 
packet: from 172.17.128.205[4500] to 104.x.x.x[1987] (108 bytes)

Traffic from the Racoon host looks like:

18:42:15.587263 IP (tos 0x0, ttl 64, id 35423, offset 0, flags [DF], proto UDP 
(17), length 140)
10.0.0.5.500 > 34.x.x.x.4500: isakmp 0.15 msgid 08100501:
18:42:15.610564 IP (tos 0x0, ttl 37, id 15016, offset 0, flags [DF], proto UDP 
(17), length 140)
34.x.x.x.4500 > 10.0.0.5.500: isakmp 0.15 msgid 08100501:

I don’t understand why they’re originating at port 500 destined for 4500, I’d 
expect DPDs to be 4500-4500. And looking at an affected host, I now see two IKE 
SAs established, one of which is using the right ports for DPDs! I realize at 
this point that I’m troubleshooting Racoon on a StrongSwan mailing list, alas. 
I just want to get rid of Racoon! :-)

I suspect I’ve reached a dead end without being able to understand what Racoon 
is doing. Any insights you might have are appreciated.

> If a NAT is detected when the SA is established (even if the port is the
> same, the IP changes so a NAT should be detected) racoon should switch
> to port 4500 with the third Main Mode message and then keep sending
> packets from/to that port (there is no reason to send messages from port
> 500 later, unless a new SA is initiated).

I did find the initiation of the SA which is weird-looking on the racoon end — 
now I’m doubting that this NAT remapping happened while an SA was established, 
but it being a black box I’m not sure. 

Mar 22 19:41:33 azure-host racoon: INFO: IPsec-SA request for 34.x.x.x queued 
due to no phase1 found.
Mar 22 19:41:33 azure-host racoon: INFO: initiate new phase 1 negotiation: 
10.0.0.5[500]<=>34.x.x.x[500]
Mar 22 19:41:34 azure-host racoon: INFO: respond new phase 1 negotiation: 
10.0.0.5[500]<=>34.x.x.x[500]
Mar 22 19:41:34 azure-host racoon: [34.210.18.127] INFO: Selected NAT-T 
version: RFC 3947
Mar 22 19:41:34 azure-host racoon: [34.210.18.127] INFO: Hashing 34.x.x.x[500] 
with algo #4
Mar 22 19:41:34 azure-host racoon: [34.210.18.127] INFO: Hashing 34.x.x.x[500] 
with algo #4

Mar 22 19:41:34 azure-host racoon: INFO: NAT-T: ports changed to: 
34.x.x.x[4500]<->10.0.0.5[500]  <— this is weird

Mar 22 19:41:34 azure-host racoon: INFO: KA list add: 
10.0.0.5[500]->34.x.x.x[4500]
Mar 22 19:41:34 azure-host racoon: INFO: ISAKMP-SA established 
10.0.0.5[500]-34.x.x.x[4500] spi:2f4d3bcf1b59f765:c921f7666b0f8a09

(Do you find that highlighted line as weird as I do? I’d expect both ends to 
change to 4500, and that’s what other successful SAs look like from the Racoon 
side.)

The same from the Swan end — unfortunately we were running with pretty low 
logging there since with 100+ SAs per host, verbose NET or ENC logging gets big 
quickly.

Mar 22 19:41:34 aws-host charon-systemd: 05[KNL] creating acquire job for 
policy 172.17.128.205/32[tcp/51069] === 104.x.x.x/32[tcp/9092] with reqid {102}
Mar 22 19:41:34 aws-host charon-systemd: 06[IKE]  initiating 
Main Mode IKE_SA azure-host[11] to 104.x.x.x
Mar 22 19:41:34 aws-host charon-systemd: 10[IKE]  received XAuth 
vendor ID
Mar 22 19:41:34 aws-host charon-systemd: 10[IKE]  received NAT-T 
(RFC 3947) vendor ID
Mar 22 19:41:34 aws-host charon-systemd: 10[IKE]  received DPD 
vendor ID
Mar 22 19:41:34 aws-host charon-systemd: 10[IKE]  remote host is 
behind NAT
Mar 22 19:41:34 aws-host charon-systemd: 07[IKE]  IKE_SA 
azure-host[11] established between 
172.17.128.205[172.17.128.205]…104.x.x.x[10.0.0.5]
Mar 22 19:41:34 aws-host charon-systemd: 07[IKE]  scheduling 
reauthentication in 80303s
Mar 22 19:41:34 aws-host charon-systemd: 07[IKE]  maximum IKE_SA 
lifetime 83903s
Mar 22 19:41:34 aws-host charon-systemd: 12[IKE]  

[strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

Hello again!

I’m still working on getting Racoon and Strongswan talking to each other, and 
I’ve run into an issue with NAT remapping. The issue is primarily on the Racoon 
side, but I want to understand Strongswan behaviour to figure out how to move 
forward because Racoon is long unmaintained and I’m stuck with it for now.

I have a Racoon host in Azure behind SNAT, and a StrongSwan host in AWS (also 
behind SNAT).

Occasionally, Azure decides to reset all of its SNAT mappings. (AWS doesn’t do 
this, so you can ignore the AWS side.) After this happens, StrongSwan starts 
sending both ESP-in-UDP and IKE packets to the newly-mapped 

So step by step:

1. IKE and ESP SAs are established normally with NAT-T, i.e. 500:4500.
2. NAT remapping occurs within Azure, at which point StrongSwan sees IKE 
packets come from port 1027 instead of 500. (i.e. instead of 500:500 it’s 
500:1027).
3. StrongSwan observes that the source port for IKE has changed to 1027, and 
starts sending both IKE and ESP-in-UDP packets to azure:1027.
4. Racoon sees ESP-in-UDP packets arriving at port 500 and cannot process them.

Step 3 is the one I am least confident in, other than what I’ve seen in tcpdump.

(One challenge I have here is that the Azure SNAT remapping only happens every 
few DAYS, so it’s very difficult to reproduce.)

So my questions are:

First, am I correctly understanding the behaviour of StrongSwan when NAT 
remapping occurs? Is this expected StrongSwan behaviour?

And: If the Azure end was StrongSwan, and ESP-in-UDP packets started arriving 
at port 500, would StrongSwan process them as ESP? (Which is to say, “if I 
upgraded all of my Azure instances to StrongSwan first would this problem go 
away?”)

Thanks,
-Rich

[strongSwan] IKEv1 SA renewals and updated configuration

[Rich Lafferty]

Hi all,

Some background: In migrating our fleet from Racoon to Strongswan I discovered 
an interop bug where, with fragmentation enabled, Racoon sends fragmented IKEv1 
packets which strongSwan is unable to decrypt. I discovered that the issue goes 
away if IKE fragmentation is disabled, and since we’re using PSK I’m confident 
that our IKE packets will be small enough to safely disable it, so I added 
`fragmentation = no` to all of our (swanctl-based) IKE connections on the 
StrongSwan side.

On to my actual question…

I discovered that while _new_ IKE SAs correctly do not advertise fragmentation, 
_renewals_ of already-established IKE SAs continue to use the same settings 
that they were established with (i.e. fragmentation is advertised and enabled).

What I expected is that after a `swanctl --load-all`, the next IKE SA 
negotiation would use the new settings, so that the change could be rolled out 
gradually and invisibly as IKE SAs expire.

Could someone more familiar with this verify that this is expected behaviour? 
Is there any way to tell strongSwan to use new configuration the next time an 
IKE SA is due for renewal, rather than interrupting the existing SA? (Later, I 
hope to migrate to a better encryption suite and was hoping to roll it out the 
same way without hard restarts of SAs.)

Thanks,
-Rich

Re: [strongSwan] multiple remote_ts with ikev1 file format

[Rich Lafferty]

> On Feb 22, 2018, at 7:15 AM, Marco Berizzi  wrote:
> 
> I'm starting strongswan with the old 'ipsec start', and after I
> issue the command: 'swanctl -q' for loading the configuration
> files under /etc/swanctl/conf.d/*
> 
> Am I right? Or is there a smarter way to start strongswan without
> the old 'ipsec' script?

Distro-specific, but we’re running charon directly from upstart:

-- /etc/init/charon.conf -- 
description "StrongSwan IKE daemon"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/lib/ipsec/charon --use-syslog
--  

And we leverage the on-start charon option to have it load its config on start:

-- /etc/strongswan.d/charon-startup.conf -- 
charon {
start-scripts {
   load-config = swanctl --load-all
}
}
-- 

(We also don’t install the ‘ipsec’ command at all, to avoid people confusing 
old and new approaches; I’ve found swanctl gives me everything that I’d get out 
of ipsec other than starting and stopping charon.)

> Is there a way to not write in every section the parameters
> common to all the children sections (rekey_time, esp_proposals…)?

I wasn’t able to find a way to set defaults, but I’ve put my common parameters 
in /etc/swanctl/swanctl-ipsec.conf and then done
"include swanctl-ipsec.conf” in each child config. If someone else knows a 
better way, though, I’m all ears!

  -Rich

Re: [strongSwan] StrongSwan/Racoon interop issue: IDcr mismatch

[Rich Lafferty]

> On Jan 30, 2018, at 10:25 AM, Tobias Brunner  wrote:
> 
> Hi Rich,
> 
>> I’m not clear on next steps, though — are you saying that this is expected 
>> behaviour that can’t be worked around, or that the fix needs to be on the 
>> racoon side?
> 
> I think this is actually due to a bug in your strongSwan release.  Back
> then we sent back the wrong IP address in one of the two NAT-OA
> payloads, which is probably what trips racoon (it seems to compare the
> addresses in the ID payloads with those in the NAT-OA payloads, which
> succeeds for IDci but evidently fails for IDcr).  This issue was fixed
> with the patch at [1], which was included in 5.5.2.

Aha, thanks! I’ve confirmed that 5.5.2 fixes the issue. Now to figure out 
Ubuntu back ports…

Thanks for your help,

 -Rich

> Regards,
> Tobias
> 
> [1] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d8f0d9c2

Re: [strongSwan] StrongSwan/Racoon interop issue: IDcr mismatch

[Rich Lafferty]

> On Jan 30, 2018, at 5:34 AM, Tobias Brunner  wrote:
> 
> Hi Rich,
> 
>> The problem:
>> 
>> When Racoon is the initiator and the connections go through NAT, phase 2
>> negotiation fails with the following error on the Racoon side:
>> 
>>   ERROR: mismatched IDcr was returned.
> 
> With Transport Mode in NAT situations strongSwan will replace the
> received traffic selectors with the actually observed addresses.  It's
> definitely possible this causes a problem with racoon (but the same
> applies to IDci, which apparently is fine)

Hey Tobias,

Thanks for the quick response. I’m not clear on next steps, though — are you 
saying that this is expected behaviour that can’t be worked around, or that the 
fix needs to be on the racoon side? Or with more logs is this something that we 
could try to address on the strongswan side?

> By the way, I pushed a commit to the ikev1-qm-fragments branch that
> fixes the handling of fragments during Quick Mode (avoids the error
> messages and error notify seen below:

Appreciated, thanks.

  -Rich

[strongSwan] StrongSwan/Racoon interop issue: IDcr mismatch

[Rich Lafferty]

Hi,

I'm running StrongSwan 5.5.1 (Ubuntu package) interoperating with Racoon from 
ipsec-tools 0.8.2 and am encountering some phase 2 negotiation issues I'm not 
sure how to resolve. 

(I'm also not sure if the mailing list, or the bug tracker, is the right place
for this so please feel free to direct me to the bug tracker if necessary.)

Some background context: We're running a full IPsec mesh network, and some 
issues in Racoon (and its unmaintanedness) have led us to start replacing it 
with StrongSwan. We're configuring with swanctl, and all of our connections are 
PSK-based transport connections. Our configuration includes 1000+ connection 
entries, of which 300 or so are established at a given time (all 
start_action = trap). We configure strongswan with multiple connections per 
remote 
host, to account for combinations of internal and NAT'd IPs. (The remote hosts 
are at AWS and Azure, and might establish connections from either.) 

So between two hosts in the same region, we have both a direct (private IP
to private IP) and also one that's NAT'd at both end (public IP to public IP).

The problem:

When Racoon is the initiator and the connections go through NAT, phase 2
negotiation fails with the following error on the Racoon side:
  
   ERROR: mismatched IDcr was returned.

and on the StrongSwan side:

   received ATTRIBUTES_NOT_SUPPORTED error notify

I haven't been able to duplicate it in any other situation (eg. private IP,
StrongSwan being the initiator), but I can reproduce it every time with the
situation described above.

(I should add that I’m bringing it up here because StrongSwan has the
advantage of being maintained, and Racoon doesn’t.)

StrongSwan configuration (on stg-rlafferty-swan15): 

stg-rlafferty-base14_1 {
  version = 1
  local { auth = psk }
  remote { auth = psk }
  proposals = aes128-sha256-modp3072
  encap = yes
  dpd_delay = 20
  reauth_time = 23h
  over_time = 1h
  rand_time = 1h  

  local_addrs = 172.16.0.50
  remote_addrs = 13.57.196.229

  children {
stg-rlafferty-base14_1 {

  mode = transport
  start_action = trap
  esp_proposals = aes128-sha1-modp3072
  life_time = 8h
  rekey_time = 7h
  rand_time = 1h

}
  }
}


On the racoon host (stg-rlafferty-base14):

Setkey configuration:

spdadd 13.57.196.229 172.16.0.50 any -P out prio def + 0 ipsec 
esp/transport//require;
spdadd 172.16.0.50 13.57.196.229 any -P in prio def + 0 ipsec 
esp/transport//require;
spdadd 172.16.0.194 13.57.50.166 any -P out prio def + 0 ipsec 
esp/transport//require;
spdadd 13.57.50.166 172.16.0.194 any -P in prio def + 0 ipsec 
esp/transport//require;
spdadd 172.16.0.194 172.16.0.50 any -P out prio def + 0 ipsec 
esp/transport//require;
spdadd 172.16.0.50 172.16.0.194 any -P in prio def + 0 ipsec 
esp/transport//require;

Racoon configuration:

path pre_shared_key "/etc/racoon/psk.txt";

remote anonymous {
exchange_mode main;

proposal {
authentication_method pre_shared_key;
dh_group modp3072;
encryption_algorithm aes;
hash_algorithm sha256;
}
generate_policy off;
nat_traversal force;

lifetime time 24 hours;

dpd_delay 20;
}

sainfo anonymous {
pfs_group modp3072;
encryption_algorithm aes;
authentication_algorithm hmac_sha256,hmac_sha1;
compression_algorithm deflate;

lifetime time 8 hours;
}

Here's the logs on the strongswan side -- seems straightforward, we receive a
QUICK_MODE request (in fragments), send a response, and then receive an
ATTRIBUTES_NOT_SUPPORTED back. I'd love to have more detail here but I haven't
yet figured out which logging levels I need to turn up, this is with NET, IKE
and ENC all at 3.


Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[NET] 
 received packet: from 13.57.196.229[4500] to 
172.16.0.50[4500] (548 bytes)
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] 
 payload type FRAGMENT was not encrypted
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] 
 could not decrypt payloads
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[IKE] 
 integrity check failed
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] 
 generating INFORMATIONAL_V1 request 4261518401 [ 
HASH N(INVAL_HASH) ]
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[NET] 
 sending packet: from 172.16.0.50[4500] to 
13.57.196.229[4500] (92 bytes)
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[IKE] 
 QUICK_MODE request with message ID 0 processing 
failed
Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] 
 received fragment #1, waiting for complete IKE 
message
Jan 29 

[strongSwan] "Require" vs "use" levels in StrongSwan-generated policies

[Rich Lafferty]

Hello,

I currently have a racoon-based full IPsec mesh (i.e., all of our host-to-host 
traffic is encrypted using trap-based transport policies). Racoon is long in 
the tooth, and so I’m in the process of planning a migration to StrongSwan.

One thing I foresee in the near future is a need to stop using IPsec between 
some pairs of hosts in the mesh (specifically, within AWS VPCs).

In our current configuration, I manage the SPD database outside of Racoon, with 
policy entries like so:

spdadd 192.168.100.101 192.168.100.102 any -P out ipsec esp/transport//require;
spdadd 192.168.100.102 192.168.100.101 any -P in ipsec esp/transport//require;

(Which get installed with refid 0, which from Racoon’s point of view is just 
fine, as it doesn’t manage policies by refid).

If I wanted to migrate those hosts to no longer require IPsec, I would first 
update the policies one host at a time to be “esp/transport//use”, and 
subsequently I could remove the policies one host at a time.

From what I’ve been able to figure, StrongSwan-installed trap policies are 
always at the “require” level, which would mean that migrating a pair of hosts 
to no longer use an IPsec transport would require updating the configuration of 
both hosts at the same time.

So my question is: Is there a way to tell StrongSwan to generate its policies 
at “use” level rather than “require” level, so I can do this sort of staged 
deployment?

I am using StrongSwan 5.5.1 as distributed by Ubuntu, with a swanctl.conf-based 
configuration. A sample connection entry, in case it’s of use:

connections {
racoon-west {
version = 1
local { auth = psk }
remote { auth = psk }
proposals = aes128-sha256-modp3072
encap = yes

reauth_time=24h
over_time=0
rand_time=0

local_addrs = 192.168.100.101
remote_addrs = 192.168.100.102

children {
racoon-west {
mode = transport
start_action = trap
esp_proposals = aes128-sha256-modp3072
rekey_time = 8h
life_time = 7h
rand_time = 0
}
}
}
}

Thanks in advance for your help.

  -Rich