<span style="font-family: Arial; font-size: 14px; line-height: 150%;"><b><font size="5">ỪNSUBSCRIBE</font></b><font color="#ff0000" size="5"><b> PLEASE</b></font><br><br>On 3/3/2019 at 6:15 AM, "Felipe Arturo Polanco" <felipeapolanco@gmail.com> wrote:<blockquote style="border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;"><div dir="ltr">You are right in that, the virtual IPs sent to the initiators are available in initiator.<div><br></div><div>If your setup is point to point and not roadwarrior, you can use a range from .254-.254 and try it out, .253 will be fixed in responder. I can't confirm if this works as I haven't tried it.</div><div><br></div><div>If you want to use a point to multipoint using multiples /30 links, please don't do this, that is a lot of headache to manage.</div><div><br></div><div>Put a big /16 network and put that in the range of the responder, use a roadwarrior configuration and make this an NBMA network.</div><div><br></div><div>OSPF should work fine with this setup and you free yourself from managing virtual /30 networks that its only purpose is to satisfy a next-hop requirement of a dynamic protocol.</div><div><br></div><div>I did this exact same setup but using BGP since it uses TCP unicast and cloud firewalls play nice with that, OSPF is layer 4 so it may bring trouble if you move to the cloud.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 2, 2019 at 7:00 PM Brian Topping <<a>brian.topping@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="border-left:1px solid #ccc;padding-left:1ex;margin:0 0 0 .8ex;"><div style=""><div><br><blockquote><div>On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco <<a>felipeapolanco@gmail.com</a>> wrote:</div><br class="gmail-m_-397799354264452808Apple-interchange-newline"><div><div dir="ltr">Please recheck how you are getting the environment variables, those values are definitely there.<div><br></div><div>Did you try the exact command I sent on my last email? Put that inside the temporary <span class="gmail-m_-397799354264452808gmail-ins-del gmail-m_-397799354264452808gmail-gr_91 gmail-m_-397799354264452808gmail-gr-alert gmail-m_-397799354264452808gmail-gr_spell gmail-m_-397799354264452808gmail-gr_run_anim gmail-m_-397799354264452808gmail-ContextualSpelling gmail-m_-397799354264452808gmail-gr_inline_cards gmail-m_-397799354264452808gmail-multiReplace gmail-m_-397799354264452808gmail-gr_" id="gmail-m_-397799354264452808gmail-91" style="display:inline;border-bottom:2px solid transparent;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></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></div><div><blockquote><div><div dir="ltr"><div>From there you can issue each of your commands manually after connection setup and see what specific command is not working.</div><div><br></div><div>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></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></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></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></div></blockquote></div></blockquote></span>