<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all, Is there anyone familiar enough with the source to confirm or correct me on this premise below? It still seems to me that the addresses presented by the updown plugin for PLUTO_MY_SOURCEIP are only those from <span style="font-family: Consolas, "Bitstream Vera Sans Mono", monospace; font-size: 13px; white-space: pre-wrap; background-color: rgb(248, 248, 248);" class="">ike_sa_t->my_vips</span> and unless the responder is able to somehow get addresses in there, the script will always have insufficient information to generate the tunnel on the responder side.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2019, at 3:08 PM, Brian Topping <<a href="mailto:brian.topping@gmail.com" class="">brian.topping@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks Felipe! I had checked that out in the past and there are no values that are set that could be used in in the script for the same effect (the static side tunnel endpoint address).<div class=""><br class=""></div><div class="">There are two things I am wondering at this point:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Getting this working probably has something to do with the code in <a href="https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979" class="">https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979</a>. As I have seen an error where “site-1-static-ip has both left- and rightsourceip, but IKE can negotiate one virtual IP only, ignoring local virtual IP”, I clearly need to specify the leftsourceip on the static side. But the IP is no longer virtual in that case. And when it is no longer virtual, the code at <a href="https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182" class="">https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182</a> never finds it. </li><li class="">Alternatively, maybe I should drop this idea of using Strongswan setting up VTIs. Maybe Bird can deal with tunnels that do not have VTIs and I just don’t understand that construction. </li></ol><div class=""><br class=""></div><div class="">I am worried that I will also lose future compatibility with VTI-capable routers (like Cisco et al) if I go with #2. I don’t have any present need for doing so, but if I did, converting everything would be a lot of tears.</div><div class=""><br class=""></div><div class="">It seems like what I am trying to do in #1 is not possible given that addresses pushed through the updown plugin can only read from IPs found in <span style="font-family: Consolas, "Bitstream Vera Sans Mono", monospace; font-size: 13px; white-space: pre-wrap; background-color: rgb(248, 248, 248);" class="">ike_sa_t->my_vips</span>.</div><div class=""><br class=""></div><div class="">Brian</div></div></div></div></blockquote></div><br class=""></body></html>