Strongswan doesn't follow network IP changes

G

gambit99

I am able to get Strongswan 5.0.4 working on FreeBSD 9.1 and connected to an Android client. However, if the network changes from wireless to another wireless or cellular connection resulting in a client's IP address changing, the VPN does not stay established.

The Strongswan log on the FreeBSD gateway has an entry:
Code: 
   [KNL] unable to update SAD entry with SPI C74c5922: address changes are not supported
After that point, the log has entries such as:
Code: 
[KNL] received PF_Key message with unexpected sequence number, was 0 expected 57
Is there an option to set for Strongswan or the FreeBSD kernel that provides support for changing addresses from the client?
 
Unfortunately, the FreeBSD kernel compares both the source and destination address when looking up IPsec SAs when it handles an SADB_UPDATE. Therefore, the existing in- and outbound SAs cannot simply be updated with the new address. Deleting the existing SAs and adding them again with the new address wouldn't work either as the sequence numbers would be reset, causing packets from/to the client getting dropped.

And even though we could retrieve the current sequence number with SADB_GET, the kernel currently does not use the sequence number if it receives it in an SADB_ADD. I have not tried it, but it might be possible to fix this by patching key_setsaval() in sys/netipsec/key.c (after line 3105):

Code: 
if (mhp->ext[SADB_X_EXT_SA2] != NULL) {
	sav->replay->count = ((struct sadb_x_sa2 *)mhp->ext[SADB_X_EXT_SA2])->sadb_x_sa2_sequence;
}

Adding code that looks for SADB_EXT_LIFETIME_CURRENT and, if found, initializes sav->lft_c from it might also be a good idea to keep everything consistent.

With that in place strongSwan should be able to retrieve the existing SA, update the address, delete the SA, and then re-add it with the correct address and sequence number.
 
Thanks for the response, @ecdsa. Just a clarification: isn't the main purpose of the MOBIKE protocol to be able to survive changing client addresses? So presumably this would work in general but the limitation you noted above prevents MOBIKE from working on FreeBSD?
 
Last edited by a moderator:
gambit99 said:
Just a clarification: isn't the main purpose of the MOBIKE protocol to be able to survive changing client addresses? So presumably this would work in general but the limitation you noted above prevents MOBIKE from working on FreeBSD?
Click to expand...

Both statements are correct.

After you get this error

Code: 
[KNL] unable to update SAD entry with SPI C74c5922: address changes are not supported

does the gateway try to rekey the CHILD_SA? Could you perhaps post a larger excerpt of the gateway's log file when such an address change happens?
 
Here is the complete log from establishing the link on my wireless network through switching to the cellular network. It looks like at that point, it never recovers from mismatched ids and the DPD request fails.

Code: 
Jul  8 20:52:26 07[NET] received packet: from 192.168.4.103[60405] to 51.33.222.193[500] (648 bytes)
Jul  8 20:52:26 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Jul  8 20:52:26 07[IKE] 192.168.4.103 is initiating an IKE_SA
Jul  8 20:52:26 07[IKE] remote host is behind NAT
Jul  8 20:52:26 07[IKE] sending cert request for "C=US, ST=Florida, L=Melbourne, O=Home, CN=Claybaug CA"
Jul  8 20:52:26 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Jul  8 20:52:26 07[NET] sending packet: from 51.33.222.193[500] to 192.168.4.103[60405] (465 bytes)
Jul  8 20:52:26 10[NET] received packet: from 192.168.4.103[34764] to 51.33.222.193[4500] (1804 bytes)
Jul  8 20:52:26 10[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ AUTH CP(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
Jul  8 20:52:26 10[IKE] received cert request for "C=US, ST=Florida, L=Melbourne, O=Home, CN=Claybaug CA"
Jul  8 20:52:26 10[IKE] received end entity cert "C=US, ST=Florida, O=Home, CN=Claybaugh"
Jul  8 20:52:26 10[CFG] looking for peer configs matching 51.33.222.193[%any]...192.168.4.103[C=US, ST=Florida, O=Home, CN=Claybaugh]
Jul  8 20:52:26 10[CFG] selected peer config 'Android'
Jul  8 20:52:26 10[CFG]   using trusted ca certificate "C=US, ST=Florida, L=Melbourne, O=Home, CN=Claybaug CA"
Jul  8 20:52:26 10[CFG] checking certificate status of "C=US, ST=Florida, O=Home, CN=Claybaugh"
Jul  8 20:52:26 10[CFG] certificate status is not available
Jul  8 20:52:26 10[CFG]   reached self-signed root ca with a path length of 0
Jul  8 20:52:26 10[CFG]   using trusted certificate "C=US, ST=Florida, O=Home, CN=Claybaugh"
Jul  8 20:52:26 10[IKE] authentication of 'C=US, ST=Florida, O=Home, CN=Claybaugh' with RSA signature successful
Jul  8 20:52:26 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jul  8 20:52:26 10[IKE] peer supports MOBIKE
Jul  8 20:52:26 10[IKE] authentication of '51.33.222.193' (myself) with RSA signature successful
Jul  8 20:52:26 10[IKE] IKE_SA Android[15] established between 51.33.222.193[51.33.222.193]...192.168.4.103[C=US, ST=Florida, O=Home, CN=Claybaugh]
Jul  8 20:52:26 10[IKE] sending end entity cert "C=US, ST=Florida, O=Home, CN=Claybaugh"
Jul  8 20:52:26 10[IKE] peer requested virtual IP %any
Jul  8 20:52:26 10[CFG] reassigning offline lease to 'C=US, ST=Florida, O=Home, CN=Claybaugh'
Jul  8 20:52:26 10[IKE] assigning virtual IP 192.168.6.1 to peer 'C=US, ST=Florida, O=Home, CN=Claybaugh'
Jul  8 20:52:26 10[IKE] peer requested virtual IP %any6
Jul  8 20:52:26 10[IKE] no virtual IP found for %any6 requested by 'C=US, ST=Florida, O=Home, CN=Claybaugh'
Jul  8 20:52:26 10[IKE] CHILD_SA Android{11} established with SPIs c51c8619_i 6d1def35_o and TS 0.0.0.0/0 === 192.168.6.1/32 
Jul  8 20:52:26 10[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH CP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) ]
Jul  8 20:52:26 10[NET] sending packet: from 51.33.222.193[4500] to 192.168.4.103[34764] (1452 bytes)
[ switched from wireless to cellular network ]
Code: 
Jul  8 20:52:43 12[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (76 bytes)
Jul  8 20:52:43 12[ENC] parsed INFORMATIONAL request 2 [ ]
Jul  8 20:52:43 12[ENC] generating INFORMATIONAL response 2 [ ]
Jul  8 20:52:43 12[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (76 bytes)
Jul  8 20:52:43 14[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (172 bytes)
Jul  8 20:52:43 14[ENC] parsed INFORMATIONAL request 3 [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) N(NO_ADD_ADDR) ]
Jul  8 20:52:43 14[KNL] unable to update SAD entry with SPI c51c8619: address changes are not supported
Jul  8 20:52:43 14[IKE] establishing CHILD_SA Android{11}
Jul  8 20:52:43 14[ENC] generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Jul  8 20:52:43 14[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (348 bytes)
Jul  8 20:52:43 14[ENC] generating INFORMATIONAL response 3 [ N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) ]
Jul  8 20:52:43 14[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (156 bytes)
Jul  8 20:52:44 08[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (204 bytes)
Jul  8 20:52:44 08[ENC] parsed CREATE_CHILD_SA response 0 [ N(ESP_TFC_PAD_N) SA No TSi TSr ]
Jul  8 20:52:44 08[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jul  8 20:52:44 08[IKE] CHILD_SA Android{11} established with SPIs c2af0249_i eac5bf5b_o and TS 0.0.0.0/0 === 192.168.6.1/32 
Jul  8 20:52:44 08[IKE] closing CHILD_SA Android{11} with SPIs c51c8619_i (0 bytes) 6d1def35_o (0 bytes) and TS 0.0.0.0/0 === 192.168.6.1/32 
Jul  8 20:52:44 08[IKE] sending DELETE for ESP CHILD_SA with SPI c51c8619
Jul  8 20:52:44 08[ENC] generating INFORMATIONAL request 1 [ D ]
Jul  8 20:52:44 08[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (76 bytes)
Jul  8 20:52:44 13[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (76 bytes)
Jul  8 20:52:44 13[ENC] parsed INFORMATIONAL response 1 [ D ]
Jul  8 20:52:44 13[IKE] received DELETE for ESP CHILD_SA with SPI 6d1def35
Jul  8 20:52:44 13[IKE] CHILD_SA closed
Jul  8 20:52:44 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:52:44 15[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:52:50 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:52:50 07[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:52:56 12[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 1497
Jul  8 20:52:58 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:52:58 14[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:06 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:06 08[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:13 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:13 13[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:14 15[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 1499
Jul  8 20:53:14 15[IKE] sending DPD request
Jul  8 20:53:14 15[ENC] generating INFORMATIONAL request 2 [ ]
Jul  8 20:53:14 15[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (76 bytes)
Jul  8 20:53:14 11[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (76 bytes)
Jul  8 20:53:14 11[ENC] parsed INFORMATIONAL response 2 [ ]
Jul  8 20:53:20 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:20 07[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:28 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:28 10[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:41 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:41 12[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:53:44 14[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 1501
Jul  8 20:53:45 08[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 1503
Jul  8 20:53:45 08[IKE] sending DPD request
Jul  8 20:53:45 08[ENC] generating INFORMATIONAL request 3 [ ]
Jul  8 20:53:45 08[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (76 bytes)
Jul  8 20:53:45 13[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (76 bytes)
Jul  8 20:53:45 13[ENC] parsed INFORMATIONAL response 3 [ ]
Jul  8 20:53:49 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:53:49 11[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:54:04 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:54:04 06[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:54:10 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:54:10 07[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:54:15 10[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 1505
Jul  8 20:54:15 10[IKE] sending DPD request
Jul  8 20:54:15 10[ENC] generating INFORMATIONAL request 4 [ ]
Jul  8 20:54:15 10[NET] sending packet: from 51.33.222.193[4500] to 184.213.148.184[34764] (76 bytes)
Jul  8 20:54:15 12[NET] received packet: from 184.213.148.184[34764] to 51.33.222.193[4500] (76 bytes)
Jul  8 20:54:15 12[ENC] parsed INFORMATIONAL response 4 [ ]
Jul  8 20:54:25 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:54:25 08[CFG] trap not found, unable to acquire reqid 11
Jul  8 20:54:31 03[KNL] creating acquire job for policy 51.33.222.193/32[255] === 192.168.4.103/32[255] with reqid {11}
Jul  8 20:54:31 13[CFG] trap not found, unable to acquire reqid 11
 
Here is another log with keyingtries=3 in ipsec.conf. It looks like a rekey attempt is made but it still doesn't like the mismatched sequence numbers.

Code: 
Jul  8 21:11:26 04[NET] received packet: from 108.109.164.118[55019] to 51.77.135.197[4500] (76 bytes)
Jul  8 21:11:26 04[ENC] parsed INFORMATIONAL request 2 [ ]
Jul  8 21:11:26 04[ENC] generating INFORMATIONAL response 2 [ ]
Jul  8 21:11:26 04[NET] sending packet: from 51.77.135.197[4500] to 108.109.164.118[55019] (76 bytes)
Jul  8 21:11:26 06[NET] received packet: from 108.109.164.118[55019] to 51.77.135.197[4500] (172 bytes)
Jul  8 21:11:26 06[ENC] parsed INFORMATIONAL request 3 [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) N(NO_ADD_ADDR) ]
Jul  8 21:11:26 06[KNL] unable to update SAD entry with SPI c6817728: address changes are not supported
Jul  8 21:11:26 06[IKE] establishing CHILD_SA Android{2}
Jul  8 21:11:26 06[ENC] generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Jul  8 21:11:26 06[NET] sending packet: from 51.77.135.197[4500] to 108.109.164.118[55019] (348 bytes)
Jul  8 21:11:26 06[ENC] generating INFORMATIONAL response 3 [ N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) ]
Jul  8 21:11:26 06[NET] sending packet: from 51.77.135.197[4500] to 108.109.164.118[55019] (156 bytes)
Jul  8 21:11:26 10[NET] received packet: from 108.109.164.118[55019] to 51.77.135.197[4500] (204 bytes)
Jul  8 21:11:26 10[ENC] parsed CREATE_CHILD_SA response 0 [ N(ESP_TFC_PAD_N) SA No TSi TSr ]
Jul  8 21:11:26 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jul  8 21:11:26 10[IKE] CHILD_SA Android{2} established with SPIs ca428e1c_i 6b4b31d8_o and TS 0.0.0.0/0 === 192.168.6.1/32 
Jul  8 21:11:26 10[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 29
Jul  8 21:11:26 10[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 31
Jul  8 21:11:26 10[IKE] closing CHILD_SA Android{2} with SPIs c6817728_i (20960 bytes) 963ecdd8_o (14632 bytes) and TS 0.0.0.0/0 === 192.168.6.1/32 
Jul  8 21:11:26 10[IKE] sending DELETE for ESP CHILD_SA with SPI c6817728
Jul  8 21:11:26 10[ENC] generating INFORMATIONAL request 1 [ D ]
Jul  8 21:11:26 10[NET] sending packet: from 51.77.135.197[4500] to 108.109.164.118[55019] (76 bytes)
Jul  8 21:11:26 13[NET] received packet: from 108.109.164.118[55019] to 51.77.135.197[4500] (76 bytes)
Jul  8 21:11:26 13[ENC] parsed INFORMATIONAL response 1 [ D ]
Jul  8 21:11:26 13[IKE] received DELETE for ESP CHILD_SA with SPI 963ecdd8
Jul  8 21:11:26 13[IKE] CHILD_SA closed
Jul  8 21:11:27 03[KNL] creating acquire job for policy 51.77.135.197/32[255] === 192.168.4.103/32[255] with reqid {2}
Jul  8 21:11:27 07[CFG] trap not found, unable to acquire reqid 2
Jul  8 21:11:34 12[KNL] received PF_KEY message with unexpected sequence number, was 0 expected 37
Jul  8 21:11:34 03[KNL] creating acquire job for policy 51.77.135.197/32[255] === 192.168.4.103/32[255] with reqid {2}
Jul  8 21:11:34 04[CFG] trap not found, unable to acquire reqid 2
 
Thanks for the logs.

You don't have to worry too much about these messages:
Code: 
[KNL] received PF_KEY message with unexpected sequence number, was 0 expected xx
They are due to a discrepancy between how we and the FreeBSD kernel use these PF_KEY sequence numbers (in some cases it might be our fault - e.g. when handling SADB_ACQUIRE messages, in others I'm pretty sure the kernel should behave differently - e.g. when responding to SADB_X_SPDGET messages). Anyway, this does not seem to cause any serious problems (the message will actually be logged with level 2 in the next release).

In both log files the rekeying finished successfully on the IKEv2 level. What troubles me, though, is that the kernel apparently lost the association between the IPsec policies and the new IPsec SA. This forces the kernel to generate these acquire messages
Code: 
[KNL] creating acquire job for policy 51.77.135.197/32[255] === 192.168.4.103/32[255] with reqid {2}
Additionally, the [255] part indicates a conversion issue (IPSEC_PROTO_ANY(255) vs. our own use of 0 for the same purpose).

I did some tests and found that there is, in fact, a problem if the rekeying happens due to an address change. I pushed several fixes to the freebsd-fixes branch of our repository. Most commits fix things in code that was added after 5.0.4 was released, so not really relevant in your case. The commit that should fix the rekeying issue is acb54386.

I hope this helps until someone (I may give it a shot, if time allows) patches the kernel.
 
ecdsa said:
Unfortunately, the FreeBSD kernel compares both the source and destination address when looking up IPsec SAs when it handles an SADB_UPDATE. Therefore, the existing in- and outbound SAs cannot simply be updated with the new address. Deleting the existing SAs and adding them again with the new address wouldn't work either as the sequence numbers would be reset, causing packets from/to the client getting dropped.
Click to expand...

Hi,

by RFC2367 changing SA's addresses is not allowed for SADB_UPDATE. The only way to do this without delete/add, I think is adding new message type. Currently I'm doing some redesign of SADB in FreeBSD, so if you have some proposal for new features we can discuss this.

What you think about something like this:
Code: 
Send a SADB_X_UPDATE_ADDRESSES message from a user process to the kernel.
<base, SA(*), (SA2), address(SD), (NATT, address(nS), address(nD))>

The kernel returns the SADB_X_UPDATE_ADDRESSES message to all listening
processes.

<base, SA, (SA2), address(SD), (NATT, address(nS), address(nD))>

IKE sends SADB_X_UPDATE_ADDRESSES to the kernel with filled SPI and old SA' addresses. SA2 header and NAT-T headers may be present.
One of SADB_X_EXT_NEW_ADDRESS_SRC, SADB_X_EXT_NEW_ADDRESS_DST, or NATT headers must be specified. The kernel does lookup for needed SA, updates SA source or/and destination addresses or/and NATT configuration and return the result to all processes.
Or ESRCH/EINVAL error code returned.
So, what you think?
 
butcher said:
What you think about something like this:
Code: 
Send a SADB_X_UPDATE_ADDRESSES message from a user process to the kernel.
<base, SA(*), (SA2), address(SD), (NATT, address(nS), address(nD))>
Click to expand...

Looks similar to the interface we use in our kernel interface for updating SAs.

butcher said:
One of SADB_X_EXT_NEW_ADDRESS_SRC, SADB_X_EXT_NEW_ADDRESS_DST, or NATT headers must be specified. The kernel does lookup for needed SA, updates SA source or/and destination addresses or/and NATT configuration and return the result to all processes.
Click to expand...

Just to clarify, if no NAT-T extension is passed, the NAT-T configuration is removed from the SA, right? Because it's theoretically possible that a mobile client behind a NAT moves out of it to a public IP (and back again). So it should be possible to add/update/remove the NAT-T config of the SA.

But why not just allow passing these new extensions (SADB_X_EXT_NEW_ADDRESS_SRC|DST) with SADB_UPDATE? That might require less changes in kernel and userland code (at least in our case that'd be the case).
 
ecdsa said:
Looks similar to the interface we use in our kernel interface for updating SAs.
Just to clarify, if no NAT-T extension is passed, the NAT-T configuration is removed from the SA, right? Because it's theoretically possible that a mobile client behind a NAT moves out of it to a public IP (and back again). So it should be possible to add/update/remove the NAT-T config of the SA.
Click to expand...

Yes. Internally this will be new SA entry, and if NAT-T headers is not present in the message, NAT-T config will not be installed.

But why not just allow passing these new extensions (SADB_X_EXT_NEW_ADDRESS_SRC|DST) with SADB_UPDATE? That might require less changes in kernel and userland code (at least in our case that'd be the case).
Click to expand...

I did some cleanup in key_update(), so now it may behave differently in comparison to early implementation.
Now it closely follows to RFC, I hope. So, if SA is not in a LARVAL state, it is not allowed to update anything but lifetimes. I prefer to follow the RFC, but since NAT-T and SADB_X_EXT_NEW_ADDRESS_SRC|DST headers are not defined by RFC, probably we can add some deviations from RFC for them. I'll try to implement described features via SADB_UPDATE and I will report you later.
 
ecdsa said:
But why not just allow passing these new extensions (SADB_X_EXT_NEW_ADDRESS_SRC|DST) with SADB_UPDATE? That might require less changes in kernel and userland code (at least in our case that'd be the case).
Click to expand...

I implemented this with SADB_UPDATE. See this commit.
But it is untested yet. Also, now the work from projects/ipsec is merged into 12.0-CURRENT.
 
You must log in or register to reply here.
Back
Top