[strongSwan] [EDIT] Traffic selection problems

[Felipe Arturo Polanco]

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>
wrote:

>
> 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>