[Openswan Users] Initiate on demand (Was: RE: Debug level for xfrm policy changes)

Fri Jun 21 09:30:30 UTC 2013

This is going to be a long post… :)

The VPN that get the issue about the xfrm block policies is configured in order to obtain a “sort of” high-availability setup.
On the openswan side I’ve got two conn (see below); it’s the remote device on the other end of the tunnel that switch back and forth from MAIN to BACKUP. I’m not sure this is the right way to do this but so far I wasn’t able to come up with something better.

conn MAIN
            leftsubnets={10.112.8.128/27 10.112.4.0/26}
            rightsubnets={192.168.255.0/24}
            left=my_public_IP
            right=remote_public_IP
            auto=start
            […other stuff about phase1 and phase2 parameters…]

conn BACKUP
            leftsubnets={10.112.8.128/27 10.112.4.0/26}
            rightsubnets={192.168.255.0/24}
            left=my_public_IP
            right=remote_public_IP
            auto=add
            […same p1, p2 parameters as MAIN conn…]

Every time the remote device switches from MAIN to BACKUP I do get one or more log entry like this:

"MAIN/1x1" #2516: route to peer's client conflicts with "BACKUP/1x1" xx.xx.xx.xx; releasing old connection to free the route
initiate on demand from 10.112.8.129:27172 to 192.168.255.125:7340 proto=17 state: fos_start because: acquire

Of course I do get the same kind of log entries what it goes back from BACKUP to MAIN. The remote device has a strange behaviour because when the phase 1 is about to expire it does a rekey on the BACKUP conn, phase 2 included, and just after a few seconds it goes back on the MAIN one.

Besides that behaviour as soon as the “switch” from MAIN to BACKUP is done I do get a xfrm policy like this one that stays there even after it goes back to MAIN.

src 10.112.8.129/32 dst 192.168.255.125/32 proto udp sport 27172 dport 7340
        dir out action block priority 2080

After a while (some hours) I do get a new policy, while the one above is still there, like the following one which is missing the “tmpl” part (which causes all the udp traffic between those two hosts to not go through the vpn tunnel).

src 10.112.8.129/32 dst 192.168.255.125/32 proto udp
        dir out priority 2080

This is the output from ip xfrm monitor when I do get the second policy, I’ve to add that this “Expired” and “Updated” entries are repeated continuously until I do a manual delete via ip xfrm delete

Expired src 10.112.8.129/32 dst 192.168.255.125/32 proto udp sport 27172 dport 7340
   dir out action block priority 2080
   hard 0
Updated src 10.112.8.129/32 dst 192.168.255.125/32 proto udp
   dir out priority 2080

Best regards,

Giovanni.

From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of Giovanni Carbone
Sent: Thursday, June 20, 2013 7:07 PM
To: users at openswan.org
Subject: Re: [Openswan Users] Debug level for xfrm policy changes

I see, is there by any chance a configuration workaround for it so that those block policies are not created at all?

Best regards,

Giovanni.

From: Leto [mailto:letoams at gmail.com]
Sent: Thursday, June 20, 2013 6:49 PM
To: Giovanni Carbone
Cc: users at openswan.org<mailto:users at openswan.org>
Subject: Re: [Openswan Users] Debug level for xfrm policy changes

the fix proposed in that bug entry caused other issues. I'm still working on a proper fix.

sent from a tiny device

On 2013-06-20, at 11:23, Giovanni Carbone <G.Carbone at reitek.com<mailto:G.Carbone at reitek.com>> wrote:
Thanks but all I’ve got is just a lot of lines like the following one:

Unknown message: 00000096 0x0000001e 0x00000000

Am I doing something wrong?

Besides that I think I’ve got the same issue described here (although I’m not able to replicate it at will): https://www.openswan.org/issues/1334
I’m using openswan 2.6.38 on a centos 5.9 x86_64.

Best regards,

Giovanni.

From: Leto [mailto:letoams at gmail.com]
Sent: Thursday, June 20, 2013 4:06 PM
To: Giovanni Carbone
Cc: users at openswan.org<mailto:users at openswan.org>
Subject: Re: [Openswan Users] Debug level for xfrm policy changes

ip xfrm monitor

sent from a tiny device

On 2013-06-20, at 7:38, Giovanni Carbone <G.Carbone at reitek.com<mailto:G.Carbone at reitek.com>> wrote:
Hello all,

Is there a way to trace the xfrm policy changes made by pluto?
I’m trying to use the --debug-pfkey switch (or plutodebug=”pfkey” in the ipsec.conf) but I don’t seem to get anything out of it.

Best regards,

Giovanni.

Any use, distribution, copying or disclosure by any other person than the intended recipient of this electronic mail transmission is prohibited as a criminal offence.
Pursuant to Legislative Decree n. 196/2003, you are hereby informed that this message and its attachments contain confidential information intended only for the use of the addressee.
If you receive this transmission in error, please inform the sender immediately and delete the material. Thank You.

The information contained in the e-mail can’t be considered authorized by Reitek SpA in front of the addressee or third parties. Reitek SpA has no responsibility in case of dissemination, duplication or damage of this communication.
_______________________________________________
Users at lists.openswan.org<mailto:Users at lists.openswan.org>
https://lists.openswan.org/mailman/listinfo/users
Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
Building and Integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

Informativa Privacy - Ai sensi del D. Lgs n. 196/2003 (Codice Privacy) precisiamo che le informazioni contenute in questo messaggio sono riservate e a uso esclusivo del destinatario. Ogni uso, copia o distribuzione non autorizzata è proibita e passibile di sanzioni ai termini di legge. Reitek non è responsabile di eventuali copie o distribuzioni non autorizzate. Se questo messaggio è stato ricevuto per errore, preghiamo gentilmente di eliminarlo e di informare il mittente. Grazie.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130621/ea23c273/attachment-0001.html>