[strongSwan] rightsubnet overlap

Fri Aug 25 12:09:44 CEST 2017

Hi John,

Basics first:

Obviously the negotiated TS (traffic selector) of a tunnel (a term used to describe a couple of SAs and SPs that belong together)
decides if a packet is subject to processing - or not.

In your use case and your configuration, you pull and get "virtual" (that's just a fancy term. You can just say "IP" instead) IPs
(one per tunnel). Charon by default narrows the local part of the TS to the received "virtual" IP. This is also what every sanely configured IPsec
responder expects (it is also the only way the local part of the TS can be intrinsically securely configured).
So your local part of the TS is the received IP (obviously specific and corresponding per address family!)
Charon installs routes with source hints into table 220 to make sure that traffic to the remote subnet uses the correct source address so the traffic
selector matches. As the source hint, it tries to use the received virtual IP (again, specific per family). If there is no virtual IP, it looks for other local
IP addresses. The source hint is the "src <IP>" part of a route (a source hint is optional). 

So obviously, because you have two tunnels with different source IPs, the policies do not conflict and you can actually establish those two tunnels.
But that obviously does not work if you don't have any virtual IPs (e.g. in a site-to-site or host-to-site scenario).

My solution is the clean one - try to mark and accept the packet first for the prioritized tunnel, then for the fallback tunnel. But again, I do not know
if this actually works, because it depends on if the SPs are removed when the tunnel fails.

Kind regards

Noel

On 24.08.2017 21:43, John Brown wrote:
> Hi Noel,
> I did not understand your answer, sorry.
> 
> But i did some experiments in the afternoon and I think I think I was
> able to achieve what I want. I'm going to check this more deeply next
> days.
> I did only one thing to get this to work:
> - disable charon to install the routes (install_routes=no in
> strongswan.conf) and add the routes manualy in the bash shell after
> the tunnel was established (i am going to automate this by updown
> script)
> There is one route for one tunnel and each route has the same network
> prefix but metric is different. It looks that this works as expected.
> There is no problem in adding kernel policy as far as each tunnel use
> different virtual ip.
> 
> I'm worried that when using updown script for that I will not be able
> to get the source interface which is needed to create the route (ip
> route add 10.10.0.0/16 table 220 metric 10 dev eth0 src 172.1.1.1) but
> hopefully I will come up with some solution.
> 
> Is this your idea or you were providing different solution?
> Best regards,
> John
> 
> 
> 
> 
> 2017-08-24 17:23 GMT+02:00, Noel Kuntze
> <noel.kuntze+strongswan-users-ml at thermi.consulting>:
>> Routes can and will not work. They only work, if for anything, if they
>> recommend a local source address for the route. Maybe you can do something
>> with manualy priorities in swanctl.conf
>> to make sure the priorities are different and one tunnel is preferred over
>> another. That will only work, if the SPs of the failed tunnel are removed
>> when it fails. Other than that, you can use marks
>> and then check in the next rule if there's a matching policy and accept the
>> packet, if there is. Marking packets is non-terminating, so you can do that
>> for how many tunnels you want. Again, it will only
>> work if the SPs of a failed tunnel are removed when it fails.
>>
>> On 24.08.2017 14:07, Dusan Ilic wrote:
>>> With iptables you can set marks on traffic and that way decide which
>>> tunnel to use. Automatic switch will not be supported, unless you write a
>>> script that checka the health of the current actively tunnel and then
>>> change mark.
>>>
>>> Probably traditional routes can work better.
>>>
>>> ---- John Brown skrev ----
>>>
>>> Hi Dusan,
>>> The solution you propose is also promising, thank you! But I do not get
>>> one thing. How can I use iptables to decide which tunnel should be used to
>>> send the traffic? Would your solution provide automatic switchover in case
>>> of preffered tunnel is going down and maybe up again (for example, many
>>> failure scenarios are possible)?
>>>
>>> Best regards,
>>> John
>>>
>>>
>>> 2017-08-24 13:24 GMT+02:00 Dusan Ilic <dusan at comhem.se
>>> <mailto:dusan at comhem.se>>:
>>>
>>>     Hi John,
>>>
>>>     You dont need route based for this, you can setup two tunnels with
>>> same rightsubnet and use different marks. By applying these marks with
>>> iptables you choose which tunnel to send the traffic to.
>>>
>>>     Vti (and maybe libipsec) is however cleaner solution, cause the vti
>>> puts the mark on all packets routed out that interface, so standard
>>> routing logic can be used instead. Not sure about libipsec though, i think
>>> you will have to use iptables marking then too.
>>>
>>>     ---- John Brown skrev ----
>>>
>>>
>>>     Thank you very much for an advice. It looks interesting but also adds
>>> significant complexity to the solution. Did you find route based VPN
>>> working for rightsubnet overlap scenario?
>>>
>>>     I'm going to try this probably but with libipsec rather that vti
>>> devices (kernel too old for vti). As far as I understand the solution
>>> you've proposed I can add priorities to the tunnels by adding a metrics to
>>> routes (and prefer conn1 over conn2). Am I correct?
>>>
>>>     Best regards,
>>>     John
>>>
>>>     2017-08-24 11:34 GMT+02:00 Vincent Bernat <bernat at luffy.cx
>>> <mailto:bernat at luffy.cx>>:
>>>
>>>          ❦ 24 août 2017 11:27 +0200 <tel:+0200>, John Brown
>>> <jb20141125 at gmail.com <mailto:jb20141125 at gmail.com>> :
>>>
>>>         > I'm searching the net but cannot find reliable answer for
>>> problem:
>>>         >
>>>         > Is this possible in strongswan to have two connections with the
>>> same
>>>         > rightsubnet entry and prefer one connection over another?
>>>         >
>>>         > For example:
>>>         >
>>>         > ...
>>>         >
>>>         > conn1
>>>         >     ...
>>>         >     rightsubnet=10.10.0.0/16 <http://10.10.0.0/16>
>>>         >
>>>         > conn2
>>>         >     ...
>>>         >     rightsubnet=10.10.0.0/16 <http://10.10.0.0/16>
>>>         >
>>>         >
>>>         > and in ideal scenario both conns are up but conn1 is used for
>>> tx/rx
>>>         > encrypted traffic when possible, conn2 only in case of lack of
>>> conn1.
>>>
>>>         One solution is to use routes to divert traffic to one of the
>>> tunnel or
>>>         the other:
>>>
>>> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
>>> <https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN>
>>>         --
>>>         Use self-identifying input.  Allow defaults.  Echo both on
>>> output.
>>>                     - The Elements of Programming Style (Kernighan &
>>> Plauger)
>>>
>>>
>>>
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170825/27f771db/attachment.sig>