You are right in that, the virtual IPs sent to the initiators are available in initiator.
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. 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. Put a big /16 network and put that in the range of the responder, use a roadwarrior configuration and make this an NBMA network. 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. 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. On Sat, Mar 2, 2019 at 7:00 PM Brian Topping <brian.topp...@gmail.com> wrote: > > On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco < > felipeapola...@gmail.com> 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. >
