Project

General

Profile

Issue #2459

updown script deleted firewall rules at down-client in make-before-break responder side

Added by Simon Chan almost 3 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
libcharon
Affected version:
5.5.3
Resolution:

Description

I am trying to setup make-before-break on responder side.
Our firewall setting has a default drop rule in the FORWARD table.
We need the firewall rules created by _updown script to pass traffic.
For reference, the FORWARD table firewall rule look like this:

FORWARD -s right_TS -d left_TS -i eth0 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
FORWARD -s left_TS -d right_TS -o eth0 -m policy --dir out --pol ipsec --proto esp -j ACCEPT

If make-before-break is yes, _updown script is invoked with this sequence:

  • up-client
  • down-client

On the down-client invocation, the FORWARD table firewall rules are deleted and the tunnel stop passing end-to-end traffic.

Some entries in syslog for the make-before-break below.
First during "make"

charon: 09[MGR] checkout IKEv2 SA by message with SPIs 1ab6e55c76e0097c_i bcb9ad165d5c3d0f_r
charon: 09[MGR] IKE_SA (unnamed)[5] successfully checked out
charon: 09[NET] received packet: from right_IP4500 to left_IP4500 (288 bytes)
charon: 09[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
charon: 09[CFG] looking for peer configs matching left_IP[left_IP]...right_IP[CLIENTID]
. . .
charon: 09[MGR] checkout IKEv2 SA with SPIs 676283e842660a2a_i 32ac7779ddf11b49_r
charon: 09[MGR] IKE_SA peer-CLIENTID-tunnel-14 successfully checked out
charon: 09[MGR] checkin IKE_SA peer-CLIENTID-tunnel-14
charon: 09[MGR] checkin of IKE_SA successful
charon: 09[IKE] IKE_SA peer-CLIENTID-tunnel-15 established between left_IP[left_IP]...right_IP[CLIENTID]
charon: 09[IKE] IKE_SA peer-CLIENTID-tunnel-15 established between left_IP[left_IP]...right_IP[CLIENTID]
charon: 09[IKE] IKE_SA peer-CLIENTID-tunnel-15 state change: CONNECTING => ESTABLISHED
. . .

Looks like after "make" there are 2 different IKE_SA's, the renew'ed has SPI 1ab6e55c76e0097c_i, old has SPI 676283e842660a2a_i

Next during "break":
charon: 16[MGR] checkout IKEv2 SA by message with SPIs 676283e842660a2a_i 32ac7779ddf11b49_r
charon: 16[MGR] IKE_SA peer-CLIENTID-tunnel-14 successfully checked out
charon: 16[NET] received packet: from right_IP4500 to left_IP4500 (80 bytes)
charon: 16[ENC] parsed INFORMATIONAL request 63 [ D ]
charon: 16[IKE] received DELETE for IKE_SA peer-CLIENTID-tunnel-14
charon: 16[IKE] deleting IKE_SA peer-CLIENTID-tunnel-14 between left_IP[left_IP]...right_IP[CLIENTID]
charon: 16[IKE] deleting IKE_SA peer-CLIENTID-tunnel-14 between left_IP[left_IP]...right_IP[CLIENTID]
charon: 16[IKE] IKE_SA peer-CLIENTID-tunnel-14 state change: ESTABLISHED => DELETING
charon: 16[IKE] IKE_SA deleted
charon: 16[IKE] IKE_SA deleted
vpn: - CLIENTID right_TS right_IP -- left_IP left_TS
charon: 16[ENC] generating INFORMATIONAL response 63 [ ]
charon: 16[NET] sending packet: from left_IP4500 to right_IP4500 (80 bytes)
charon: 16[MGR] checkin and destroy IKE_SA peer-CLIENTID-tunnel-14
charon: 16[IKE] IKE_SA peer-CLIENTID-tunnel-14 state change: DELETING => DESTROYING
charon: 16[CHD] CHILD_SA peer-CLIENTID-tunnel-1{8} state change: INSTALLED => DESTROYING
charon: 16[KNL] deleting policy left_TS === right_TS out
charon: 16[KNL] policy still used by another CHILD_SA, not removed
. . .
NB: the log started with "vpn:" is from the logger line in down-client section in _updown.

Can Strongswan add a flag in the old IKE_SA to remember that this IKE_SA has a replacement?
Then updown listener can check this flag and set an env variable to tell _updown script that this down-client has a replacement. So do not delete the firewall rules.

Earlier I scanned the commits for make-before-break.
Found 799f4c5db942b6a1cc92e0f6cc0f01f591695309 dated Wed Mar 11 14:41:37 2015 +0100 with commit reason:
"ikev2: Don't set old IKE_SA to REKEYING state during make-before-break reauth".

I tried undoing that commit, i.e. put back the IKE_REKEYING state change in tribber_mbb_reauth()
Hope updown listener see the rekey flag and won't invoke _updown.
This change is okay for me because I am always the responder, never act as initiator.
But this change did not help the _updown problem.

Also available in: Atom PDF