[strongSwan] [EDIT] Traffic selection problems

[Eduardo Mirahyes]

ỪNSUBSCRIBE PLEASE

On 3/3/2019 at 6:15 AM, "Felipe Arturo Polanco"  wrote: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  wrote:

On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco  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/20190304/b928a441/attachment.html>