[strongSwan] [EDIT] Traffic selection problems

Felipe Arturo Polanco felipeapolanco at gmail.com
Sun Mar 3 00:14:59 CET 2019

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.topping at gmail.com>

> On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco <
> felipeapolanco at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190302/178a3f64/attachment-0001.html>

More information about the Users mailing list