[strongSwan] Multiple connections same virtual pool without sharing FIXED

[Marwan Khalili]

Hi! I am wondering if it is possible for multiple connections to have the same pool without being shared? E.g. client1 on conn1 and client2 on conn2 are both assigned 10.10.0.1.

I read on the “Virtual IP” wiki page that multiple connections can share the same pool if they use the same rightsourceip. As I tried this out, both clients were on separate connections but client1 was assigned 10.10.0.1 and client2 10.10.0.2.

Regards,

Marwan

[Tobias Brunner]

Hi Marwan,

Post by Marwan Khalili
I am wondering if it is possible for multiple connections to have
the same pool without being shared?

Not when configuring via ipsec.conf, you can probably do this via
vici/swanctl or attr-sql.

Post by Marwan Khalili
E.g. client1 on conn1 and client2 on
conn2 are both assigned 10.10.0.1.

What exactly would the purpose be of that?

Regards,
Tobias

[Marwan Khalili]

Hi Tobias,

Thank you for the advice, I will try to configure vici/swanctl.

In my use case, client1 and client2 are specifying which virtual pool they want assigned to their VPN connection. I was hoping that multiple clients (connections) could select the same pool without any conflicts.

Regards,

Marwan

Post by Tobias Brunner
Hi Marwan,

Post by Marwan Khalili
I am wondering if it is possible for multiple connections to have
the same pool without being shared?

Not when configuring via ipsec.conf, you can probably do this via
vici/swanctl or attr-sql.

Post by Marwan Khalili
E.g. client1 on conn1 and client2 on
conn2 are both assigned 10.10.0.1.

What exactly would the purpose be of that?
Regards,
Tobias

[Tobias Brunner]

Hi Marwan,

Post by Marwan Khalili
In my use case, client1 and client2 are specifying which virtual pool they want assigned to their VPN connection. I was hoping that multiple clients (connections) could select the same pool without any conflicts.

What do you mean with that? If they select a different pool but get the
same address assigned you obviously have a conflict.

Regards,
Tobias

[Marwan Khalili]

[Tobias Brunner]

Hi Marwan,

3. Client1 connects multiple devices to the VPN, each device has a
unique virtual IP address and can be accessed through Client1’s VPN

How does it do that? Do you mean it allocates addresses from
10.0.0.0/24 to those clients? (Without the server being aware of that,
which is not a good idea.) Or does it NAT traffic from these devices to
the IP address it received from the VPN server?

6. Same as step3, however these devices are not accessible from
Client1’s VPN and vice versa

So why not use distinct subnets? Reaching these devices from other
hosts (e.g. behind the VPN server, or the server itself) could be tricky
if they have the same IP addresses assigned. And depending on the
traffic selector on the server's side and whether you use marks this
will actually result in duplicate IPsec policies, which won't work.

And are you sure this would be easier with a site-to-site setup instead
of using virtual IP pools in the first place? The IP addresses used on
the client end could still be "virtual IPs", i.e. only usable inside the
VPN, but they wouldn't be assigned by the server (to use duplicate
subnets is still tricky, though).

Regards,
Tobias

[Marwan Khalili]

Hi Tobias,

How does it do that? Do you mean it allocates addresses from
10.0.0.0/24 to those clients? (Without the server being aware of that,
which is not a good idea.) Or does it NAT traffic from these devices to
the IP address it received from the VPN server?

The idea is that the client has its connection configured with e.g. “leftsubnet=192.168.1.0/24” and each device located on the 192.168.1.0/24 subnet allocates a virtual IP address from 10.0.0.0/24.

So why not use distinct subnets? Reaching these devices from other
hosts (e.g. behind the VPN server, or the server itself) could be tricky
if they have the same IP addresses assigned. And depending on the
traffic selector on the server's side and whether you use marks this
will actually result in duplicate IPsec policies, which won't work.

Many of our customers that are setting up these "clients" are already connected to a VPN when they wish to connect to the devices. To avoid conflicts, we thought the customer could select the virtual subnet. If it is possible to set up duplicate subnets, there is no need to check if a certain subnet is available for the customer to use.

And are you sure this would be easier with a site-to-site setup instead
of using virtual IP pools in the first place? The IP addresses used on
the client end could still be "virtual IPs", i.e. only usable inside the
VPN, but they wouldn't be assigned by the server (to use duplicate
subnets is still tricky, though).

Yeah, any setup will do as long as we can duplicate the subnets. I was hoping that it could be done as I read in the Virtual IP wiki that it might have been possible before: “previously each connection would use it's own copy and the same virtual IP may have been handed out to different clients”.

Regards,

Marwan



On 16 Oct 2018, at 12:28, Tobias Brunner <***@strongswan.org<mailto:***@strongswan.org>> wrote:

Hi Marwan,

3. Client1 connects multiple devices to the VPN, each device has a
unique virtual IP address and can be accessed through Client1’s VPN

How does it do that? Do you mean it allocates addresses from
10.0.0.0/24 to those clients? (Without the server being aware of that,
which is not a good idea.) Or does it NAT traffic from these devices to
the IP address it received from the VPN server?

6. Same as step3, however these devices are not accessible from
Client1’s VPN and vice versa

So why not use distinct subnets? Reaching these devices from other
hosts (e.g. behind the VPN server, or the server itself) could be tricky
if they have the same IP addresses assigned. And depending on the
traffic selector on the server's side and whether you use marks this
will actually result in duplicate IPsec policies, which won't work.

And are you sure this would be easier with a site-to-site setup instead
of using virtual IP pools in the first place? The IP addresses used on
the client end could still be "virtual IPs", i.e. only usable inside the
VPN, but they wouldn't be assigned by the server (to use duplicate
subnets is still tricky, though).

Regards,
Tobias

[Tobias Brunner]

Hi Marwan,

Post by Marwan Khalili

How does it do that?  Do you mean it allocates addresses from
10.0.0.0/24 to those clients?  (Without the server being aware of that,
which is not a good idea.)  Or does it NAT traffic from these devices to
the IP address it received from the VPN server?

The idea is that the client has its connection configured with e.g.
“leftsubnet=192.168.1.0/24” and each device located on the
192.168.1.0/24 subnet allocates a virtual IP address from 10.0.0.0/24.

Then you definitely don't need virtual IPs managed by the VPN server.
Just use that leftsubnet configuration (and rightsubnet set accordingly
on the server) and get rid of left|rightsourceip.

Post by Marwan Khalili

So why not use distinct subnets?  Reaching these devices from other
hosts (e.g. behind the VPN server, or the server itself) could be tricky
if they have the same IP addresses assigned.  And depending on the
traffic selector on the server's side and whether you use marks this
will actually result in duplicate IPsec policies, which won't work.

Many of our customers that are setting up these "clients" are already
connected to a VPN when they wish to connect to the devices. To avoid
conflicts, we thought the customer could select the virtual subnet. If
it is possible to set up duplicate subnets, there is no need to check if
a certain subnet is available for the customer to use.

OK, then you'll definitely want to use marks etc. to properly handle
duplicate subnets.

Post by Marwan Khalili

And are you sure this would be easier with a site-to-site setup instead
of using virtual IP pools in the first place?  The IP addresses used on
the client end could still be "virtual IPs", i.e. only usable inside the
VPN, but they wouldn't be assigned by the server (to use duplicate
subnets is still tricky, though).

Yeah, any setup will do as long as we can duplicate the subnets. I was
hoping that it could be done as I read in the Virtual IP wiki that it
might have been possible before: “previously each connection would use
it's own copy and the same virtual IP may have been handed out to
different clients”.

But that's not your use case. The devices behind each client won't
request virtual IPs from the VPN server, so these pools are irrelevant.

Regards,
Tobias