
<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=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco <<a href="mailto:felipeapolanco@gmail.com" class="">felipeapolanco@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Please recheck how you are getting the environment variables, those values are definitely there.<div class=""><br class=""></div><div class="">Did you try the exact command I sent on my last email? Put that inside the temporary <span class="gmail-ins-del gmail-gr_91 gmail-gr-alert gmail-gr_spell gmail-gr_run_anim gmail-ContextualSpelling gmail-gr_inline_cards gmail-multiReplace gmail-gr_" id="gmail-91" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">updown</span> script, put the shebang on the top and make it executable, the output file will contain all environment variables including PLUTO variables.</div></div></div></blockquote><div><br class=""></div>Yes, I definitely checked it again to be sure. The PLUTO_MY_SOURCEIP and PLUTO_MY_SOURCEIP4_1 variables are defined to one side of the tunnel on the dynamic side, but those variables are not even defined on the static side. What more, the correct value does not show up under any key.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">From there you can issue each of your commands manually after connection setup and see what specific command is not working.</div><div class=""><br class=""></div><div class="">I know this works as I set this up for a client some time ago and we faced a similar situation.</div></div></div></blockquote><br class=""></div><div>Thanks, I appreciate that. Sometimes it’s easy to overlook stuff like this and without really closely examining the feedback, one can miss an opportunity to solve the issue.</div><div><br class=""></div><div>If it were possible at this stage without PLUTO_MY_SOURCEIP, I could imagine something like a PLUTO_PEER_SOURCEIP being defined, then figure out the address that remains using the set difference of PLUTO_MY_CLIENT (which is set to the tunnel network address and netmask). </div><div><br class=""></div><div>On the dynamic side, PLUTO_MY_SOURCEIP is defined but PLUTO_PEER_SOURCEIP is not. On the static side, neither is defined. This says to me that there is something about the static side configuration that leads it to believe it should not be participating in virtual IP setup. But that’s just a hunch and I’ll dig through the sources some more to see if I can prove that out.</div></body></html>