Hello Noel Please forgive me...the mail got sent with incomplete info....the below is what i wanted to ask
i did not understand the below point mentioned by you...can you please clarify some more >>>No. The routes are only added if the source IP needs to be changed from the one >>>indicated by the main routing table for the packets to the remote network to be protected by IPsec. 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? Suppose we have the ipsec tunnel topology as below Local-PC( 192.168.1.2)------(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.2)Remote- <http://192.168.1.0/24)------(192.168.1.1)%5Blocal-peergw%5D44.44.44.20-----(44.1)Router(55.1)-----55.55.55.20%5BRem-Peergw%5D(192.168.2.1)------(192.168.2.0/24)Remote-TS> PC - the default-route on Local-Peergw is as below default via 44.44.44.1 dev eth0 - and the ipsec-conf is as below on the local-peergw conn tor-remote-peerggw left=44.44.44.20 right=55.55.55.20 leftsubnet=192.168.1.0/24 rightsubnet=192.168.2.0/24 auto=route localauth=psk remoteauth=psk - And i see that in table 220 the following is installed on the "LOCAL-PEERGW. This is installed by default (when auto=route option is used in the ipsec.conf connection entry for this tunnel) root# ip route show table 220 192.168.6.0/24 via 44.44.44.1 dev eth0 proto static src 192.168.1.1 - So when i send a ping from the Local-PC to Remote-PC, the tunnel does come up and i recieve the ping-responses So i did not understand which source-ipaddr got changed here? And how is the behavior or procedure different when i disable table 220 (install_routes=no)? thank you for your help in understanding strongswan regards Rajiv > > > No. The routes are only added if the source IP needs to be changed from >> the one >> indicated by the main routing table for the packets to the remote network >> to be protected by IPsec. >> >> > Now in later Strongswan versions its been recommended to use >> "install_routes=NO" >> >> That's wrong. It's only recommended if you don't want or need to change >> the source IP when tunnels go up. >> >> > a) does charon rely ONLY on the "default route" in the main-routing >> table now? >> >> From the IntroductionToStrongswan[1] article: >> >> > To avoid conflicts with these routes (especially if virtual IPs are >> used), the kernel-netlink plugin manually parses the >> > host's routing tables to determine a suitable source address when >> sending IKE packets. On hosts with a (very) high number >> > of routes this is quite inefficient. In that case, setting >> charon.plugins.kernel-netlink.fwmark in strongswan.conf is >> > recommended as it will allow using a more efficient source address >> lookup. >> >> Answers to your other questions can be drawn from the quote. >> >> Kind regards >> >> Noel >> >> [1] >> https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan#Routing >> >> Am 23.10.20 um 23:21 schrieb Rajiv Kulkarni: >> > >> > Hi >> > >> > Its mentioned that when we set "auto=route" in a connection >> entry/record for a ipsec tunnel, the "kernel traps are installed" >> > >> > In layman's terms and understanding: >> > 1. What exactly are these "kernel traps installed? Can we view what >> traps are installed? >> > 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 >> > 3. So are these routes in table-220 correlated and mapped to the >> kernel-traps? >> > >> > For e,g with table-220 (install_routes=yes the default option enabled), >> the following are the sample examples of the routes installed >> > >> > ================================================ >> > For a full-tunnel (localsubnet<>any) spokegw to hubgw >> > ------------------------------------------------------- >> > >> > root@OpenWrt:/etc# ip route show table 220 >> > default via 2.2.2.1 dev eth0 proto static src 192.168.2.253 >> > 192.168.2.0/24 <http://192.168.2.0/24> dev eth2 scope link >> > root@OpenWrt:/etc# >> > >> > >> > >> > >> > For a site to site tunnel >> > ----------------------- >> > root@openwrt# ip route show table 220 >> > 44.44.44.0/24 <http://44.44.44.0/24> dev eth0 scope link >> > 172.31.38.0/24 <http://172.31.38.0/24> via 44.44.44.254 dev eth0 >> proto static src 192.168.26.254 >> > >> > >> > >> > >> > On a Remote-Access VPN Client (split-tunnel) >> > --------------------------- >> > root@linuxgw2:~/dump3# ip route show table 220 >> > 192.168.6.0/24 <http://192.168.6.0/24> via 100.100.100.2 dev eth1 >> proto static src 10.1.104.100 >> > root@linuxgw2:~/dump3# >> > >> > On a Remote-Access VPN Client (full-tunnel: local<>any) >> > --------------------------- >> > >> > root@OpenWrt:/etc# ip route show table 220 >> > default via 95.1.1.1 dev pppoe-wan proto static src 10.1.5.10 >> > 192.168.10.0/24 <http://192.168.10.0/24> dev eth2 scope link >> > root@OpenWrt:/etc# >> > >> > >> > >> > ======================================================= >> > >> > >> > >> > >> > >> > Now in later Strongswan versions its been recommended to use >> "install_routes=NO" >> > >> > So again here too as a kind request, in layman's perspective/view and >> understanding >> > 1. What happens to the routes that used to be installed earlier in >> table 220? >> > >> > 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? >> > >> > 3. With the "install_routes=NO": >> > a) does charon rely ONLY on the "default route" in the main-routing >> table now? >> > >> > 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???? >> > >> > 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) >> > >> > >> > regards >> > Rajiv >> > >> > >> > >> >>
