[strongSwan] Coexistence of route-based and policy-based VPN

[Sandesh Sawant]

Hi Nolan,

Thanks for confirmation. I could get a route-based tunnel to co-exist with
a policy-based tunnel as long as the peer endpoints of the two were
different. When I created 2 tunnels with the same end points - one
route-based and the other policy-based, then I noticed that both tunnels
were established, however within a few seconds one of them went down (its
SAs & SPs were removed from XFRM). I am wondering if it's because of some
misconfiguration on my end or whether it's not supported by design. I'll
share the configs if you say that it should work.

Also, can someone confirm if Linux VTI supports multicast? And if yes, does
one need to modify something in VTI interface configuration. I'd appreciate
if someone can a sample configuration for OSPF over VTI (e.g. using quagga
ospfd).

Regards,
Sandesh

On Tue, Apr 4, 2017 at 4:56 AM, Noel Kuntze <noel at familie-kuntze.de> wrote:

> On 04.04.2017 03:12, Sandesh Sawant wrote:
> > Hi,
> >
> > I am familiar with configuring policy-based VPN using strongSwan, and I
> have recently set up route-based VPN using strongSwan. I am wondering
> whether one can simultaneously setup and use route-based and policy-based
> connections in the same gateway. Can someone confirm the same?
>
> You can.
>
> > As per my understanding policy-based VPN requires strongSwan to install
> routes in table 220. Whereas in route-based VPN route installation by
> Charon must be disabled. Therefore for both types of connections to
> co-exist, I guess there needs to be a way to configure whether route
> installation is done or not on a per-connection basis in ipsec.conf instead
> of having a global configuration in charon.conf.
>
> If the main routing table's routes are already correct for any possible
> combination of CHILD_SAs and their possibly negotiated TS, you don't need
> any routes in table 220.
>
> > Also, I am wondering why one has to disable XFRM & Policy on the uplink
> (local endpoint) interface in case of route-based VPN. Is is because we
> don't want ESP packets going from VTI to uplink interface in the egress
> path to be subject to IPSec processing again? I doubt i that is the reason
> because my understanding is that it is the "mark" which dictates if IPSec
> processing is applicable to an interface or not. IMO even though the local
> & remote selectors used in route-based connection are 0.0.0.0/0 <
> http://0.0.0.0/0>, IPSec processing will be skipped at the uplink since
> there is no match w.r.t. SA mark. Can someone please explain the
> significance of the requirement for disabling XFRM & policy on uplink
> interface?
>
> You only need to disable the policy check on the VTI. It's only done to
> improve performance (avoids a double policy check).
> "To avoid duplicate policy lookups it is also recommended to set sysctl -w
> net.ipv4.conf.<name>.disable_policy=1."[1]
>
> The SPs have the mark set anyway, so unless you set that exact same mark
> (or the mask of the mark of the SPs includes the set mark on a packet), the
> packet isn't subject to the policy. I think disabling XFRM on any
> interface has no relevance in getting policy and route based VPNs to work.
>
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/
> RouteBasedVPN#VTI-Devices-on-Linux
>
> --
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170410/57ed5eed/attachment.html>