> On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco <[email protected]> > wrote: > > Please recheck how you are getting the environment variables, those values > are definitely there. > > Did you try the exact command I sent on my last email? Put that inside the > temporary updown script, put the shebang on the top and make it executable, > the output file will contain all environment variables including PLUTO > variables.
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. > From there you can issue each of your commands manually after connection > setup and see what specific command is not working. > > I know this works as I set this up for a client some time ago and we faced a > similar situation. 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. 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). 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.
