Stale Block policy in Charon and Kernel SPD. about strongswan HOT 10 CLOSED

It's not a bug. Host-X needs to send INIT_CONTACT notify so the other peer knows this is the same peer and it can delete the old IKE_SA, and you need to have "uniqueids=yes" (ipsec.conf)/"connections..unique=yes" (swanctl.conf) configured so the daemon heeds the INIT_CONTACT notifies. "yes" is the default.

from strongswan.

Agreed, also parameters are as you pointed out. And duplicate listener is also enabled.
Please not that the Security-GW has terminated the tunnel due to DPD timeout too.
We believe it is some race condition.
Can you please help me understand other them NAT change detection where are will Strongswan would install a block/drop policy in SPD.

from strongswan.

Please provide at the very least your complete configurations and debug logs as shown in #196 (bottom part is expandable and shows the right file logger configuration snippets for debug logging).

from strongswan.

Hi Thermi,

We us ViCi to configure the tunnel on both Host and Security-GW, and this issue is seen where the log levels are almost silent, and the issue is only see rarely like 3 times max as of i remember in the span of couple of years.
We have done a lot of testing w.r.t duplicate tunnel detection and this works fine and clears the old tunnel when new tunnel with same inital_contact is received.
We are trying to only understand in what race-condition or corner case, this issue can be seen, like I said before the drop/block policy I see getting added when StrongSwan get NAT change trigger for kernel.
I can still send you the config logs if you really need it, from few months back when the system was last rebooted.
As this is live system am unable to enable debug level logs too, if we can understand how we can reproduce we can try to reproduce this in lap setup to come up with some fixes.

When this issue was seen last time, with failing to reproduce this issue, I commented "del_policies_outbound" call for deleting the DROP policy in child_sa.c update method.

from strongswan.

Hi,

I can't tell what the exact issue is without logs.
Looks like the only way is to replicate a production system with traffic in the lab.

Kind regards
Noel

from strongswan.

Hi Noel,

This issue is not dependent on the amount of traffic, i believe some issue with NAT change on initiator and retran-timeout on Secuirty-GW.
Can you let least help me point any other case you can think of where StrongSwan can install a POLICY_DROP?

Thanks & Regards,
Vinay Goutham

from strongswan.

A drop policy is a policy with the specific "block" mode set. (can be seen in ip -s x p in the line directly below the TS)
E.g.:

# ip -s -d x p                                                                                                                          
src 1.1.1.1/32 dst 1.1.1.1/32 uid 0
        dir out action block index 2657 priority 567231 ptype main share any flag  (0x00000000)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 0(sec), hard 0(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          0(bytes), 0(packets)
          add 2021-03-26 21:31:23 use -

That's a trap policy without a matching state yet:

src 192.168.178.26/32 dst 185.112.147.121/32 uid 0
        dir out action allow index 2745 priority 367232 ptype main share any flag  (0x00000000)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 0(sec), hard 0(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          0(bytes), 0(packets)
          add 2021-03-26 21:34:44 use -
        tmpl src 192.168.178.26 dst 185.112.147.121
                proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel
                level required share any 
                enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff

The same policies repeat for dir fwd and dir in (as with dir out).

The problem you probably have is just a policy without a state. strongSwan negotiates the policies though when it gets notified by the kernel through an acquire.
Without logs, I can't help you much further. strongSwan cooperates with logrotate just fine (very broad hint).

from strongswan.

Are you sure it's a drop policy? (Please provide more logs and status output e.g. from ip xfrm.) If you didn't configure one, then they are only installed during address updates (i.e. after roaming to a new IP address while updating the SAs and policies). Do you use custom policy priorities? (There was a bug related to that and these drop policies that was fixed with 5.8.0.)

from strongswan.

Hi Tobias,

The logs rolled over, and what I have is there above, and for ip xfrm policy the team rebooted the system before taking that output. Can you point me to the patch with the fix your taking about, I will check if that make sense. I also believe this is due to NATT change, and some other collusion.

from strongswan.

This is the patch for the priority/CHILD_SA update issue: 8e31d65 But this is only relevant if you actually configured custom priorities for CHILD_SAs.

from strongswan.