<div dir="ltr">Hello Noel<div><br></div><div>i did not understand the below point mentioned by you...can you please clarify some more?</div><div><br></div><div>>>>No. The routes are only added if the source IP needs to be changed from the one<br>>>>indicated by the main routing table for the packets to the remote network to be protected by IPsec.</div><div><br></div><div>Which source-ip? You mean the src-ipaddr of the ESP packet that is generated by this local-peergw that is sent to remote-peergw?</div><div><br></div><div>Suppose we have the ipsec tunnel topology as below:</div><div><br></div><div>Local-TS(<a href="http://192.168.1.0/24)------(192.168.1.1)[local-peergw]44.44.44.20-----(44.1)Router(55.1)-----55.55.55.20[Rem-Peergw](192.168.2.1)------(192.168.2.0/24)Remote-TS">192.168.1.0/24)------(192.168.1.1)[local-peergw]44.44.44.20-----(44.1)Router(55.1)-----55.55.55.20[Rem-Peergw](192.168.2.1)------(192.168.2.0/24)Remote-TS</a></div><div><br></div><div>and the ipsec-conf is as below</div><div><br></div><div>conn tor-emote-peergw</div><div>           left=44.44.44.20</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 26, 2020 at 3:34 AM Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Rajiv,<br>
<br>
> 1. What exactly are these "kernel traps installed? Can we view what traps are installed?<br>
<br>
They're just IPsec policies without a state.<br>
<br>
> 3. So are these routes in table-220 correlated and mapped to the kernel-traps?<br>
<br>
No. The routes are only added if the source IP needs to be changed from the one<br>
indicated by the main routing table for the packets to the remote network to be protected by IPsec.<br>
<br>
> Now in later Strongswan versions its been recommended to use "install_routes=NO" <br>
<br>
That's wrong. It's only recommended if you don't want or need to change the source IP when tunnels go up.<br>
<br>
> a) does charon rely ONLY on the "default route" in the main-routing table now?<br>
<br>
>From the IntroductionToStrongswan[1] article:<br>
<br>
> To avoid conflicts with these routes (especially if virtual IPs are used), the kernel-netlink plugin manually parses the<br>
> host's routing tables to determine a suitable source address when sending IKE packets. On hosts with a (very) high number<br>
> of routes this is quite inefficient. In that case, setting charon.plugins.kernel-netlink.fwmark in strongswan.conf is<br>
> recommended as it will allow using a more efficient source address lookup.<br>
<br>
Answers to your other questions can be drawn from the quote.<br>
<br>
Kind regards<br>
<br>
Noel<br>
<br>
[1] <a href="https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan#Routing" rel="noreferrer" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan#Routing</a><br>
<br>
Am 23.10.20 um 23:21 schrieb Rajiv Kulkarni:<br>
> <br>
> Hi<br>
> <br>
> Its mentioned that when we set "auto=route" in a connection entry/record for a ipsec tunnel, the "kernel traps are installed"<br>
> <br>
> In layman's terms and understanding:<br>
> 1. What exactly are these "kernel traps installed? Can we view what traps are installed?<br>
> 2. By default "install_routes" is YES, so the routes are added in table 220 which has a higher priority order above the main-routing table<br>
> 3. So are these routes in table-220 correlated and mapped to the kernel-traps?<br>
> <br>
> For e,g with table-220 (install_routes=yes the default option enabled), the following are the sample examples of the routes installed<br>
> <br>
> ================================================<br>
> For a full-tunnel (localsubnet<>any) spokegw to hubgw<br>
> -------------------------------------------------------<br>
> <br>
> root@OpenWrt:/etc# ip route show table 220<br>
> default via 2.2.2.1 dev eth0  proto static  src 192.168.2.253<br>
> <a href="http://192.168.2.0/24" rel="noreferrer" target="_blank">192.168.2.0/24</a> <<a href="http://192.168.2.0/24" rel="noreferrer" target="_blank">http://192.168.2.0/24</a>> dev eth2  scope link<br>
> root@OpenWrt:/etc#<br>
> <br>
> <br>
> <br>
> <br>
> For a site to site tunnel<br>
> -----------------------<br>
> root@openwrt# ip route show table 220<br>
> <a href="http://44.44.44.0/24" rel="noreferrer" target="_blank">44.44.44.0/24</a> <<a href="http://44.44.44.0/24" rel="noreferrer" target="_blank">http://44.44.44.0/24</a>> dev eth0  scope link<br>
> <a href="http://172.31.38.0/24" rel="noreferrer" target="_blank">172.31.38.0/24</a> <<a href="http://172.31.38.0/24" rel="noreferrer" target="_blank">http://172.31.38.0/24</a>> via 44.44.44.254 dev eth0  proto static  src 192.168.26.254<br>
> <br>
> <br>
> <br>
> <br>
> On a Remote-Access VPN Client (split-tunnel)<br>
> ---------------------------<br>
> root@linuxgw2:~/dump3# ip route show table 220<br>
> <a href="http://192.168.6.0/24" rel="noreferrer" target="_blank">192.168.6.0/24</a> <<a href="http://192.168.6.0/24" rel="noreferrer" target="_blank">http://192.168.6.0/24</a>> via 100.100.100.2 dev eth1 proto static src 10.1.104.100<br>
> root@linuxgw2:~/dump3#<br>
> <br>
> On a Remote-Access VPN Client (full-tunnel: local<>any)<br>
> ---------------------------<br>
> <br>
> root@OpenWrt:/etc# ip route show table 220<br>
> default via 95.1.1.1 dev pppoe-wan  proto static  src 10.1.5.10<br>
> <a href="http://192.168.10.0/24" rel="noreferrer" target="_blank">192.168.10.0/24</a> <<a href="http://192.168.10.0/24" rel="noreferrer" target="_blank">http://192.168.10.0/24</a>> dev eth2  scope link<br>
> root@OpenWrt:/etc#<br>
> <br>
> <br>
> <br>
> =======================================================<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Now in later Strongswan versions its been recommended to use "install_routes=NO" <br>
> <br>
> So again here too as a kind request, in layman's perspective/view and understanding<br>
> 1. What happens to the routes that used to be installed earlier in table 220?<br>
> <br>
> 2. What effect ,this "non-use of table 220" has on the "kernel-traps" installed....again in this scenario...what kind of kernel-traps are installed? Are they different from when table 220 was enabled...??? Can a user view these traps?<br>
> <br>
> 3. With the "install_routes=NO":<br>
> a) does charon rely ONLY on the "default route" in the main-routing table now?<br>
> <br>
> b) Does the config and use of IP-Policy-Routes (with use of IP-Rules and other routing tables defined by user) continue to work in this case and does charon also refer to the policy-routes if configured????<br>
> <br>
> we have these above doubts when we are thinking of moving to "install_routes=no" regime and just use the main-routing table and/or the custom IP-Policy-Routes/IP-Rules (for both IPv4 and IPv6 Tunnels ). Especially when we want to go in for some critical "IP4-Over-IPv6 IPSec Tunnels" scenarios (part of transition to IPv6 networks)<br>
> <br>
> <br>
> regards<br>
> Rajiv<br>
> <br>
> <br>
> <br>
<br>
</blockquote></div>