[Openswan Users] Initiate on demand (Was: RE: Debug level for xfrm policy changes)
Giovanni Carbone
G.Carbone at reitek.com
Sat Jun 22 10:13:21 UTC 2013
To put it shortly it doesn't work very well. :)
Netkey creates the xfrm policies only when the IPSEC SA are established so
there isn't a conflict there but nonetheless it causes many other problems
like the ones I've described below. Right now I've removed the backup conn
and I'm working just with the main one. I'm going to put the backup one on
another server and I'll manage to dynamically change the routing tables on
the next hop inside the private network on my side via the updown script.
Thanks for your interest, best regards,
Giovanni.
-----Original Message-----
From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of Bob Miller
Sent: Friday, June 21, 2013 8:49 PM
To: users at lists.openswan.org
Subject: Re: [Openswan Users] Initiate on demand (Was: RE: Debug level for xfrm policy changes)
I am really curious to know if this will actually work:
> 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…]
Given that these two conns are identical, I don't see how openswan can
tell them apart. especially if the other side has both the same conns
too, maybe one side is trying to use one conn while the other side is
trying to use the opposing conn; the settings are right but the conn is
wrong so they can't connect.
As I understand it, netkey will create everything (probably including
the xfrm policy) based on the routing and networking settings. So
having two conns that use the same route would (at least by my
expectation) confuse openswan and cause it to behave unexpectedly. I
haven't used ipsec interfaces for a very long time, but the only way I
would think two identical conns would work is if you assigned them
different ipsec interfaces....
But, all of that is speculation without carefully examining all of the
info in this thread. Hence my curiosity if this will actually work...
>
>
>
>
>
> 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
> 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>
> 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
> 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> 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
> 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.
>
>
> _______________________________________________
> 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
_______________________________________________
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.
More information about the Users
mailing list