<div dir="ltr">Hi Nolan,<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Regards,</div><div>Sandesh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 4:56 AM, Noel Kuntze <span dir="ltr"><<a href="mailto:noel@familie-kuntze.de" target="_blank">noel@familie-kuntze.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04.04.2017 03:12, Sandesh Sawant wrote:<br>
> Hi,<br>
><br>
> 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?<br>
<br>
</span>You can.<br>
<span class=""><br>
> 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.<br>
<br>
</span>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.<br>
<br>
> 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 <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">http://0.0.0.0/0</a>>, 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?<br>
<br>
You only need to disable the policy check on the VTI. It's only done to improve performance (avoids a double policy check).<br>
"To avoid duplicate policy lookups it is also recommended to set sysctl -w net.ipv4.conf.<name>.disable_<wbr>policy=1."[1]<br>
<br>
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<br>
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.<br>
<br>
<br>
[1] <a href="https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#VTI-Devices-on-Linux" rel="noreferrer" target="_blank">https://wiki.strongswan.org/<wbr>projects/strongswan/wiki/<wbr>RouteBasedVPN#VTI-Devices-on-<wbr>Linux</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Mit freundlichen Grüßen/Kind Regards,<br>
Noel Kuntze<br>
<br>
GPG Key ID: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
<br>
</font></span></blockquote></div><br></div>