Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

Hi all, Is there anyone familiar enough with the source to confirm or correct 
me on this premise below? It still seems to me that the addresses presented by 
the updown plugin for PLUTO_MY_SOURCEIP are only those from ike_sa_t->my_vips 
and unless the responder is able to somehow get addresses in there, the script 
will always have insufficient information to generate the tunnel on the 
responder side.

> On Mar 2, 2019, at 3:08 PM, Brian Topping  wrote:
> 
> Thanks Felipe! I had checked that out in the past and there are no values 
> that are set that could be used in in the script for the same effect (the 
> static side tunnel endpoint address).
> 
> There are two things I am wondering at this point:
> 
> Getting this working probably has something to do with the code in 
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979
>  
> .
>  As I have seen an error where “site-1-static-ip has both left- and 
> rightsourceip, but IKE can negotiate one virtual IP only, ignoring local 
> virtual IP”, I clearly need to specify the leftsourceip on the static side. 
> But the IP is no longer virtual in that case. And when it is no longer 
> virtual, the code at 
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182
>  
> 
>  never finds it. 
> Alternatively, maybe I should drop this idea of using Strongswan setting up 
> VTIs. Maybe Bird can deal with tunnels that do not have VTIs and I just don’t 
> understand that construction. 
> 
> I am worried that I will also lose future compatibility with VTI-capable 
> routers (like Cisco et al) if I go with #2. I don’t have any present need for 
> doing so, but if I did, converting everything would be a lot of tears.
> 
> It seems like what I am trying to do in #1 is not possible given that 
> addresses pushed through the updown plugin can only read from IPs found in 
> ike_sa_t->my_vips.
> 
> Brian

Re: [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.

Re: [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 
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.
>

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

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

Re: [strongSwan] [EDIT] Traffic selection problems

[Felipe Arturo Polanco]

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.

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

On Sat, Mar 2, 2019 at 6:08 PM Brian Topping 
wrote:

> Thanks Felipe! I had checked that out in the past and there are no values
> that are set that could be used in in the script for the same effect (the
> static side tunnel endpoint address).
>
> There are two things I am wondering at this point:
>
>
>1. Getting this working probably has something to do with the code in
>
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979.
>As I have seen an error where “site-1-static-ip has both left- and
>rightsourceip, but IKE can negotiate one virtual IP only, ignoring local
>virtual IP”, I clearly need to specify the leftsourceip on the static side.
>But the IP is no longer virtual in that case. And when it is no longer
>virtual, the code at
>
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182
>  never
>finds it.
>2. Alternatively, maybe I should drop this idea of using Strongswan
>setting up VTIs. Maybe Bird can deal with tunnels that do not have VTIs and
>I just don’t understand that construction.
>
>
> I am worried that I will also lose future compatibility with VTI-capable
> routers (like Cisco et al) if I go with #2. I don’t have any present need
> for doing so, but if I did, converting everything would be a lot of tears.
>
> It seems like what I am trying to do in #1 is not possible given that
> addresses pushed through the updown plugin can only read from IPs found in
> ike_sa_t->my_vips.
>
> Brian
>
> On Mar 2, 2019, at 8:22 AM, Felipe Arturo Polanco <
> felipeapola...@gmail.com> wrote:
>
> You can extract the env variables information by using the "set" command,
> use a temporary updown script that has the following "set > /tmp/output",
> after establishing the connection, check that output file both in initiator
> and responder and see if the values are as expected, if they are, try to
> reproduce the script by typing each command one by one in the console and
> see its behavior.
>
> Remember to disable the updown script in strongswan when running it
> manually.
>
> Sent from mobile.
>
> On Sat, Mar 2, 2019, 2:22 AM Brian Topping 
> wrote:
>
>> Hi Felipe,
>>
>> That use of `left|rightsubnet` was a huge help.
>>
>> In an effort to automate the address assignment for a larger network
>> (same theme as the OSPF), I’ve been using the `leftupdown` script in
>> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
>> .
>>
>> So I’ve updated it as shown:
>>
>> =
>> Dynamic:
>> conn site-2-dynamic-ip
>>
>>mark=%unique
>>
>> left=%defaultroute
>>
>>leftsourceip=%config4
>>
>> leftsubnet=10.10.0.0/22,10.9.255.252/30
>> leftfirewall=no
>>
>>leftupdown=/etc/strongswan.d/ipsec-vti.sh
>>right=st.at.ic.ip
>>
>> rightsubnet=10.10.4.0/22,10.9.255.252/30
>> rightid=%specific.example.com
>> auto=add
>>
>> Static:
>> conn site-1-static-ip
>>
>>mark=%unique
>>
>> left=st.at.ic.ip
>> leftsubnet=10.10.4.0/22,10.9.255.252/30
>> leftid=%specific.example.com
>> leftfirewall=no
>>
>>leftsourceip=10.9.255.253
>>leftupdown=/etc/strongswan/ipsec-vti.sh
>>
>> right=%any
>>
>>rightsourceip=10.9.255.254
>>
>> rightsubnet=10.10.0.0/22,10.9.255.252/30
>> auto=add
>> ===
>>
>>
>> With this configuration, I get full SA and IKE negotiation including TS
>> and dynamic side tunnel configuration:
>>
>> root@dynamic:/# ip a show vti1
>> 49: vti1@NONE:  mtu 1472 qdisc noqueue
>> state UNKNOWN group default qlen 1000
>> link/ipip dy.na.mi.cip peer st.at.ic.ip
>>
>> inet 10.9.255.254/32 scope global vti1
>>valid_lft forever preferred_lft forever
>>
>>
>> On the static side, I get an error from the script:
>>
>> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP:
>> unbound variable
>>
>>
>> I initially had the same problem on the dynamic side, but the addition of
>> `leftsourceip=%config4` and `rightsourceip` on the static side resolved
>> that.
>>
>> Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound
>> variable” problem?
>>
>> Thanks so much for your insight!
>>
>
>

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

Thanks Felipe! I had checked that out in the past and there are no values that 
are set that could be used in in the script for the same effect (the static 
side tunnel endpoint address).

There are two things I am wondering at this point:

Getting this working probably has something to do with the code in 
https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979
 
.
 As I have seen an error where “site-1-static-ip has both left- and 
rightsourceip, but IKE can negotiate one virtual IP only, ignoring local 
virtual IP”, I clearly need to specify the leftsourceip on the static side. But 
the IP is no longer virtual in that case. And when it is no longer virtual, the 
code at 
https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182
 

 never finds it. 
Alternatively, maybe I should drop this idea of using Strongswan setting up 
VTIs. Maybe Bird can deal with tunnels that do not have VTIs and I just don’t 
understand that construction. 

I am worried that I will also lose future compatibility with VTI-capable 
routers (like Cisco et al) if I go with #2. I don’t have any present need for 
doing so, but if I did, converting everything would be a lot of tears.

It seems like what I am trying to do in #1 is not possible given that addresses 
pushed through the updown plugin can only read from IPs found in 
ike_sa_t->my_vips.

Brian

> On Mar 2, 2019, at 8:22 AM, Felipe Arturo Polanco  
> wrote:
> 
> You can extract the env variables information by using the "set" command, use 
> a temporary updown script that has the following "set > /tmp/output", after 
> establishing the connection, check that output file both in initiator and 
> responder and see if the values are as expected, if they are, try to 
> reproduce the script by typing each command one by one in the console and see 
> its behavior.
> 
> Remember to disable the updown script in strongswan when running it manually. 
> 
> Sent from mobile. 
> 
> On Sat, Mar 2, 2019, 2:22 AM Brian Topping  > wrote:
> Hi Felipe,
> 
> That use of `left|rightsubnet` was a huge help.
> 
> In an effort to automate the address assignment for a larger network (same 
> theme as the OSPF), I’ve been using the `leftupdown` script in 
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
>  
> .
>  
> 
> So I’ve updated it as shown:
> 
>> =
>> Dynamic:
>> conn site-2-dynamic-ip
>  mark=%unique
>>  left=%defaultroute
>leftsourceip=%config4
>>  leftsubnet=10.10.0.0/22,10.9.255.252/30 
>> 
>>  leftfirewall=no
>leftupdown=/etc/strongswan.d/ipsec-vti.sh
>right=st.at.ic.ip
>>  rightsubnet=10.10.4.0/22,10.9.255.252/30 
>> 
>>  rightid=%specific.example.com 
>>  auto=add
>> 
>> Static:
>> conn site-1-static-ip
>mark=%unique
>>  left=st.at.ic.ip
>>  leftsubnet=10.10.4.0/22,10.9.255.252/30 
>> 
>>  leftid=%specific.example.com 
>>  leftfirewall=no
>leftsourceip=10.9.255.253 
>leftupdown=/etc/strongswan/ipsec-vti.sh
>>  right=%any
>rightsourceip=10.9.255.254
>>  rightsubnet=10.10.0.0/22,10.9.255.252/30 
>> 
>>  auto=add
>> ===
> 
> With this configuration, I get full SA and IKE negotiation including TS and 
> dynamic side tunnel configuration:
> 
>> root@dynamic:/# ip a show vti1
>> 49: vti1@NONE:  mtu 1472 qdisc noqueue state 
>> UNKNOWN group default qlen 1000
>> link/ipip dy.na.mi.cip peer st.at.ic.ip
>> inet 10.9.255.254/32  scope global vti1
>>valid_lft forever preferred_lft forever
> 
> On the static side, I get an error from the script:
>> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP: 
>> unbound variable
> 
> I initially had the same problem on the dynamic side, but the addition of 
> `leftsourceip=%config4` and `rightsourceip` on the static side resolved that.
> 
> Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound 
> variable” problem?
> 
> Thanks so much for your insight!

Re: [strongSwan] [EDIT] Traffic selection problems

[Felipe Arturo Polanco]

You can extract the env variables information by using the "set" command,
use a temporary updown script that has the following "set > /tmp/output",
after establishing the connection, check that output file both in initiator
and responder and see if the values are as expected, if they are, try to
reproduce the script by typing each command one by one in the console and
see its behavior.

Remember to disable the updown script in strongswan when running it
manually.

Sent from mobile.

On Sat, Mar 2, 2019, 2:22 AM Brian Topping  wrote:

> Hi Felipe,
>
> That use of `left|rightsubnet` was a huge help.
>
> In an effort to automate the address assignment for a larger network (same
> theme as the OSPF), I’ve been using the `leftupdown` script in
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
> .
>
> So I’ve updated it as shown:
>
> =
> Dynamic:
> conn site-2-dynamic-ip
>
>mark=%unique
>
> left=%defaultroute
>
>leftsourceip=%config4
>
> leftsubnet=10.10.0.0/22,10.9.255.252/30
> leftfirewall=no
>
>leftupdown=/etc/strongswan.d/ipsec-vti.sh
>right=st.at.ic.ip
>
> rightsubnet=10.10.4.0/22,10.9.255.252/30
> rightid=%specific.example.com
> auto=add
>
> Static:
> conn site-1-static-ip
>
>mark=%unique
>
> left=st.at.ic.ip
> leftsubnet=10.10.4.0/22,10.9.255.252/30
> leftid=%specific.example.com
> leftfirewall=no
>
>leftsourceip=10.9.255.253
>leftupdown=/etc/strongswan/ipsec-vti.sh
>
> right=%any
>
>rightsourceip=10.9.255.254
>
> rightsubnet=10.10.0.0/22,10.9.255.252/30
> auto=add
> ===
>
>
> With this configuration, I get full SA and IKE negotiation including TS
> and dynamic side tunnel configuration:
>
> root@dynamic:/# ip a show vti1
> 49: vti1@NONE:  mtu 1472 qdisc noqueue
> state UNKNOWN group default qlen 1000
> link/ipip dy.na.mi.cip peer st.at.ic.ip
>
> inet 10.9.255.254/32 scope global vti1
>valid_lft forever preferred_lft forever
>
>
> On the static side, I get an error from the script:
>
> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP:
> unbound variable
>
>
> I initially had the same problem on the dynamic side, but the addition of
> `leftsourceip=%config4` and `rightsourceip` on the static side resolved
> that.
>
> Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound
> variable” problem?
>
> Thanks so much for your insight!
>

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

Hi Felipe,

That use of `left|rightsubnet` was a huge help.

In an effort to automate the address assignment for a larger network (same 
theme as the OSPF), I’ve been using the `leftupdown` script in 
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
 
.
 

So I’ve updated it as shown:

> =
> Dynamic:
> conn site-2-dynamic-ip
   mark=%unique
>   left=%defaultroute
   leftsourceip=%config4
>   leftsubnet=10.10.0.0/22,10.9.255.252/30 
> 
>   leftfirewall=no
   leftupdown=/etc/strongswan.d/ipsec-vti.sh
   right=st.at.ic.ip
>   rightsubnet=10.10.4.0/22,10.9.255.252/30 
> 
>   rightid=%specific.example.com 
>   auto=add
> 
> Static:
> conn site-1-static-ip
   mark=%unique
>   left=st.at.ic.ip
>   leftsubnet=10.10.4.0/22,10.9.255.252/30 
> 
>   leftid=%specific.example.com 
>   leftfirewall=no
   leftsourceip=10.9.255.253 
   leftupdown=/etc/strongswan/ipsec-vti.sh
>   right=%any
   rightsourceip=10.9.255.254
>   rightsubnet=10.10.0.0/22,10.9.255.252/30 
> 
>   auto=add
> ===

With this configuration, I get full SA and IKE negotiation including TS and 
dynamic side tunnel configuration:

> root@dynamic:/# ip a show vti1
> 49: vti1@NONE:  mtu 1472 qdisc noqueue state 
> UNKNOWN group default qlen 1000
> link/ipip dy.na.mi.cip peer st.at.ic.ip
> inet 10.9.255.254/32 scope global vti1
>valid_lft forever preferred_lft forever

On the static side, I get an error from the script:
> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP: 
> unbound variable

I initially had the same problem on the dynamic side, but the addition of 
`leftsourceip=%config4` and `rightsourceip` on the static side resolved that.

Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound 
variable” problem?

Thanks so much for your insight!

Re: [strongSwan] [EDIT] Traffic selection problems

[Felipe Arturo Polanco]

Hi Brian,

Please try this configuration:
=
Dynamic:
conn site-2-dynamic-ip
left=%defaultroute
leftsubnet=10.10.0.0/22,10.9.255.252/30
leftfirewall=no
right=dy.na.mi.cip
rightsubnet=10.10.4.0/22,10.9.255.252/30
rightid=%specific.example.com
auto=add

Static:
conn site-1-static-ip
left=st.at.ic.ip
leftsubnet=10.10.4.0/22,10.9.255.252/30
leftid=%specific.example.com
leftfirewall=no
right=%any
rightsubnet=10.10.0.0/22,10.9.255.252/30
auto=add
===


Two things to observe:
In Initiator:
ip address add 10.9.255.253/30 dev vti
ip route add 10.10.4.0/22 dev vti src 10.9.255.253 #for locally generated
packets sent to 10.10.4.0/22 to have source as 10.9.255.253
OR
ip route add 10.10.4.0/22 dev vti src 10.10.0.1 #for locally generated
packets sent to 10.10.4.0/22 to have source as 10.10.0.1

Apply the same logic on the responder by replacing the destination network
and the source IP

Also

OSPF uses multicast for default operation in Ethernet, remember to change
this link to Point to Point so it uses unicast.

Let us know how it goes.

Thanks,

On Thu, Feb 28, 2019 at 7:51 PM Brian Topping 
wrote:

> Hi Felipe, thank you for your consideration of this. It took me a bit to
> create a diagram:
>
>
>  10.10.0.0/22 10.10.4.0/22
>   ^ ^
>   v v
>+---++---+
>|  Initiator||   Responder   |
>|---||---|
>|10.9.255.253/30| <- - - -VTI - - - ->|
> 10.9.255.254/30| 
>+---++---+
>  ^  ^
>  v  v
> ini.tia.tor.ip  < Internet >  res.pon.der.ip
>
> From the bottom, the internet connection between the initiator and
> responder, a PtP VTI between the the two nodes and in turn, the two /22
> networks that I want to connect through the VTI as native routing between
> networks (hence the VTI interfaces on each node). The initiator public IP
> is dynamic.
>
> The reason for not doing straight tunneling between the two /22 networks
> is OSPF discovery of interfaces, typical routing daemons can only see
> interfaces to add discovery over (ie “vti*”). As the network grows, the
> routing daemons will self-discover for optimal backbone routing.
>
> Apologies that I didn’t get deeper into that previously! Does it help?
>

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

Hi Felipe, thank you for your consideration of this. It took me a bit to create 
a diagram:


 10.10.0.0/22 10.10.4.0/22
  ^ ^
  v v
   +---++---+
   |  Initiator||   Responder   |
   |---||---|
   |10.9.255.253/30|<- - - -VTI - - - ->|10.9.255.254/30|
   +---++---+
 ^  ^
 v  v
ini.tia.tor.ip  < Internet >  res.pon.der.ip

From the bottom, the internet connection between the initiator and responder, a 
PtP VTI between the the two nodes and in turn, the two /22 networks that I want 
to connect through the VTI as native routing between networks (hence the VTI 
interfaces on each node). The initiator public IP is dynamic. 

The reason for not doing straight tunneling between the two /22 networks is 
OSPF discovery of interfaces, typical routing daemons can only see interfaces 
to add discovery over (ie “vti*”). As the network grows, the routing daemons 
will self-discover for optimal backbone routing.

Apologies that I didn’t get deeper into that previously! Does it help?

Re: [strongSwan] [EDIT] Traffic selection problems

[Felipe Arturo Polanco]

Hi Brian,

Your traffic selectors look strange, left implies the source IP XFRM will
see and right implies the destination IP XFRM will see in order to know if
it has to transform and encrypt that IP packet.

Can you tell us the existing subnets in both sites?
Site 1 with static IP has x.x.x.x subnet
Site 2 with dynamic IP has x.x.x.x subnet

Also, what are those two /30 networks for? is that needed to go inside the
tunnel as well?

On Thu, Feb 28, 2019 at 5:10 AM Brian Topping 
wrote:

> > VTI devices won't change anything.  You can't use transport mode with
> > any IPs other than those of the endpoints (i.e. it doesn't work with
> > virtual IPs or arbitrary subnets - you have to use tunnel mode for that).
>
> Got it, thanks Tobias. But the logs say `06[IKE] not using transport mode,
> not host-to-host` and the SADB modes are all `tunnel`, so the stack appears
> to have made up for my error.
>
> Or has it?
>

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

> VTI devices won't change anything.  You can't use transport mode with
> any IPs other than those of the endpoints (i.e. it doesn't work with
> virtual IPs or arbitrary subnets - you have to use tunnel mode for that).

Got it, thanks Tobias. But the logs say `06[IKE] not using transport mode, not 
host-to-host` and the SADB modes are all `tunnel`, so the stack appears to have 
made up for my error. 

Or has it?

Re: [strongSwan] [EDIT] Traffic selection problems

[Tobias Brunner]

Hi Brian,

VTI devices won't change anything.  You can't use transport mode with
any IPs other than those of the endpoints (i.e. it doesn't work with
virtual IPs or arbitrary subnets - you have to use tunnel mode for
that).  [1] might help to explain these modes to you.

Regards,
Tobias

[1] http://www.unixwiz.net/techtips/iguide-ipsec.html

Re: [strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

> unless, you use an additional tunneling protocol like GRE.  So for
> transport mode you will have to use %dynamic (optional with
> protocol/port) as traffic selector.

Thanks Tobias. After spending the last couple of solid days on this, I’m a 
little closer to a solution. Reading parts of the IKE2 RFC has helped, but not 
enough.

I am working to create a VTI PtP. The updown script I am using is in [1]. At 
one point, it was getting called on both sides, now it’s getting called on the 
initiator after the `CHILD_SA established`, but it does not happen on the 
responder at the same point.

One of the problems I have is because the TS negotiation is not using the 
10.9.255.252/30 network for both sides, so a ping from initiator to responder’s 
policy address does not get accepted by the `policy match dir in pol ipsec` 
netfilter rule because no single address can both send the packet and have the 
response returned. 

Are you able to see what I am missing here? At the end, I would like to have a 
`vti` device on both nodes where as much as possible, the vti tunnel was 
completely configured with Virtual IP from the responder.

Brian

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
 

Common config
> config setup
> charondebug="ike 4, knl 2, cfg 4, mgr 2"
> 
> conn %default
> keyingtries=3
> authby=secret
> type=transport
> 
> ike=aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072
> 
> esp=aes192gcm16-aes128gcm16-ecp256-modp3072,aes192-sha256-ecp256-modp3072

Initiator config
> conn net-net
> mark=%unique
> left=%defaultroute
> leftfirewall=no
> leftsubnet=0.0.0.0/0
> leftupdown=/etc/strongswan.d/ipsec-vti.sh
> leftsourceip=%config4
> right=res.pon.der.ip
> rightid=@example.com
> rightsubnet=%dynamic
> auto=add

Responder config
> conn net-net
> mark=%unique
> left=res.pon.der.ip
> leftupdown=/etc/strongswan/ipsec-vti.sh
> leftid=@example.com
> leftfirewall=no
> leftsourceip=10.9.255.1
> leftsubnet=0.0.0.0/0
> right=%any
> rightsourceip=10.9.255.0/24
> auto=add

Initiator xfrm
> root@initiator:~# ip x p
> src 10.9.255.1/32 dst res.pon.der.ip/32 
>   dir out priority 367231 
>   mark 0x1/0x
>   tmpl src ini.tia.tor.ip dst res.pon.der.ip
>   proto esp spi 0xc97a3d09 reqid 1 mode tunnel
> src res.pon.der.ip/32 dst 10.9.255.1/32 
>   dir fwd priority 367231 
>   mark 0x1/0x
>   tmpl src res.pon.der.ip dst ini.tia.tor.ip
>   proto esp reqid 1 mode tunnel
> src res.pon.der.ip/32 dst 10.9.255.1/32 
>   dir in priority 367231 
>   mark 0x1/0x
>   tmpl src res.pon.der.ip dst ini.tia.tor.ip
>   proto esp reqid 1 mode tunnel
> src 0.0.0.0/0 dst 0.0.0.0/0 
>   socket in priority 0 
> src 0.0.0.0/0 dst 0.0.0.0/0 
>   socket out priority 0 
> src 0.0.0.0/0 dst 0.0.0.0/0 
>   socket in priority 0 
> src 0.0.0.0/0 dst 0.0.0.0/0 
>   socket out priority 0 
> src ::/0 dst ::/0 
>   socket in priority 0 
> src ::/0 dst ::/0 
>   socket out priority 0 
> src ::/0 dst ::/0 
>   socket in priority 0 
> src ::/0 dst ::/0 
>   socket out priority 0 
> root@initiator:~# ip x s
> src ini.tia.tor.ip dst res.pon.der.ip
>   proto esp spi 0xc97a3d09 reqid 1 mode tunnel
>   replay-window 0 flag af-unspec
>   mark 0x1/0x
>   aead rfc4106(gcm(aes))  128
>   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
> src res.pon.der.ip dst ini.tia.tor.ip
>   proto esp spi 0xc2f50f38 reqid 1 mode tunnel
>   replay-window 32 flag af-unspec
>   aead rfc4106(gcm(aes))  128
>   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
> root@initiator:~# ip t l
> vti1: ip/ip remote 173.248.143.113 local 71.33.222.96 ttl inherit key 1
> ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0
> root@initiator:~# ip a sh vti1
> 24: vti1@NONE:  mtu 1472 qdisc noqueue state 
> UNKNOWN group default qlen 1000
> link/ipip ini.tia.tor.ip peer res.pon.der.ip
> inet 10.9.255.1/32 scope global vti1
>valid_lft forever preferred_lft forever
> inet6 fe80::200:5efe:4721:de60/64 scope link 
>valid_lft forever preferred_lft forever

Responder xfrm
> [root@responder ~]# ip x p
> src res.pon.der.ip/32 dst 10.9.255.1/32 
>   dir out priority 367231 ptype main 
>   mark 0x1/0x
>   tmpl src res.pon.der.ip dst ini.tia.tor.ip
>   proto esp spi 0xc2f50f38 reqid 1 mode tunnel
> src 10.9.255.1/32 dst res.pon.der.ip/32 
>   dir fwd priority 367231 ptype main 
>   mark 0x1/0x
>   tmpl src ini.tia.tor.ip dst res.pon.der.ip
>   proto esp reqid 1 mode tunnel
> src 10.9.255.1/32 dst res.pon.der.ip/32 
>   dir in priorit

Re: [strongSwan] [EDIT] Traffic selection problems

[Tobias Brunner]

Hi Brian,

> I am using `type=transport`

You can't use transport mode to tunnel traffic from IPs other than the
two hosts themselves (that's exactly what tunnel mode is for where the
complete IP packet, including the original header, is encapsulated),
unless, you use an additional tunneling protocol like GRE.  So for
transport mode you will have to use %dynamic (optional with
protocol/port) as traffic selector.

Regards,
Tobias

[strongSwan] [EDIT] Traffic selection problems

[Brian Topping]

[Apologies for accidentally hitting send on previous email…]

Hi all, I’m trying to resolve an issue with traffic selection and am running 
out of ideas on how to do so. Hopefully someone here can recognize what I am 
doing wrong. My two endpoints are `strongSwan 5.7.2, Linux 
4.20.3-1.el7.elrepo.x86_64, x86_64` and `strongSwan 5.6.3` from OpenWRT `opkg` 
repositories. 

In my config (below), I have worked on several iterations and have always seen 
the selectors presented to the opposite side specifying the /32 of the external 
interface to each other, never the networks that I am trying to route between. 
I am using `type=transport` as I need to pass OSPF traffic over the links. In 
an effort to cover all bases before posting here, I have mapped my 
configuration to that in 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Site-To-Site-Scenario
 
,
 also with the same results. 

When I remove the `left/rightsubnet` configurations, the TS negotiates cleanly 
and passes traffic bound for to the opposite public endpoint, but then of 
course no xfrm policy exists between the `10.10.0.0/22` and `10.10.4.0/22` 
networks, which is the final goal.

In all cases, SA is being negotiated cleanly, so I have clipped those sections 
for brevity. Apologies if I have lost information and thanks for your 
consideration!

Brian

Common:
> config setup
>   charondebug="ike 2, knl 2, cfg 2, mgr 2"
> 
> conn %default
>   keyingtries=3
>   authby=secret
>   type=transport
>   
> ike=aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072
>   
> esp=aes192gcm16-aes128gcm16-ecp256-modp3072,aes192-sha256-ecp256-modp3072
> 

Dynamic:
> conn site-2-dynamic-ip
>   left=%defaultroute
>   leftsubnet=10.9.254.252/30,10.9.254.248/30
>   leftfirewall=no
>   right=dy.na.mi.cip
>   rightsubnet=10.10.0.0/22
>   rightid=%specific.example.com 
>   auto=add


Static:
> conn site-1-static-ip
>   left=st.at .ic.ip
>   leftsubnet=10.9.254.252/30,10.9.254.248/30
>   leftid=%specific.example.com  
> leftfirewall=no
>   right=%any
>   rightsubnet=10.10.4.0/22
>   auto=add


Dynamic side logs:
> 05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH 
> N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) 
> N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
> 05[NET] sending packet: from dy.na.mi.cip[4500] to st.at.ic.ip[4500] (445 
> bytes)
> 05[MGR] checkin IKE_SA site-2-dynamic-ip[10]
> 05[MGR] checkin of IKE_SA successful
> received packet: from st.at.ic.ip[4500] to dy.na.mi.cip[4500] (205 bytes)
> 13[MGR] checkout IKEv2 SA by message with SPIs 666aa985fa6a1f6b_i 
> 354556de7cfce172_r
> 13[MGR] IKE_SA site-2-dynamic-ip[10] successfully checked out
> 13[NET] received packet: from st.at.ic.ip[4500] to dy.na.mi.cip[4500] (205 
> bytes)
> parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) 
> N(ADD_4_ADDR) N(ADD_6_ADDR) N(TS_UNACCEPT) ]
> 13[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) 
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(TS_UNACCEPT) ]
> 13[IKE] authentication of 'specific.example.com 
> ' with pre-shared key successful
> 13[IKE] IKE_SA site-2-dynamic-ip[10] established between 
> dy.na.mi.cip[dy.na.mi.cip]...st.at.ic.ip[specific.example.com 
> ]
> : 13[IKE] IKE_SA site-2-dynamic-ip[10] established between 
> dy.na.mi.cip[dy.na.mi.cip]...st.at.ic.ip[specific.example.com 
> ]
> 13[IKE] IKE_SA site-2-dynamic-ip[10] state change: CONNECTING => ESTABLISHED
> 13[IKE] scheduling reauthentication in 9950s
> 13[IKE] maximum IKE_SA lifetime 10490s
> 13[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
> 13[IKE] failed to establish CHILD_SA, keeping IKE_SA
> 13[KNL] deleting SAD entry with SPI cee22084
> 13[KNL] deleted SAD entry with SPI cee22084
> 13[IKE] received AUTH_LIFETIME of 9756s, scheduling reauthentication in 9216s
> 13[IKE] peer supports MOBIKE
> 13[IKE] got additional MOBIKE peer address: 10.10.0.41
> 13[IKE] got additional MOBIKE peer address: 172.17.0.1
> 13[IKE] got additional MOBIKE peer address: fc00::10ca:1
> 13[IKE] activating new tasks
> 13[IKE] nothing to initiate
> 13[MGR] checkin IKE_SA site-2-dynamic-ip[10]

Static side logs:
> 07[NET] received packet: from 71.211.224.100[4500] to 173.248.143.113[4500] 
> (445 bytes)
> 07[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH 
> N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) 
> N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
> 07[CFG] looking for a child config for st.at.ic.ip/32 === dy.na.mi.cip/32
> 07[CFG] proposing traffic selectors for us:
> 07[CFG]  st.at.ic.ip/32
> 07[CFG]  st.at.ic.ip/32
> 07[CFG] propo