Project

General

Profile

Issue #3171

Unexpected behavior in Virtual IP negotiation when requesting specifc virtual ip in swanctl.conf by initiator

Added by Yanzhe Lee 9 days ago. Updated 9 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.8.1
Resolution:

Description

The initiator request a specific vip by connections.<conn>.vips = 10.10.6.1
The responder setting in swanctl.conf is connections.<conn>.pools.test1.addrs = 10.10.0.0/16,connections.<conn>.pools = test1
The expected behavior is that if the requested vip 10.10.6.1 is available in responder's pool, the responder should return the requested vip. If it's not available, the responder should reject it or just return a new one.
However, the actual behavior I observed is no matter the requested vip is available or not, the responder will always return a new one, which is 10.10.0.1 in this case, ignoring what is requested by initiator.
It seems that the behavior of righsourceip = %config is not supported in responder's swanctl.conf, and it is also removed from Virtual IP documentation [[https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIP]]
The documentation only mentions how to set it in ipsec.conf

Alternatively, the responder may define the following to let the client choose an address. This is not recommended if the client is not completely trusted.
Configuration File IPv4 & IPv6
ipsec.conf rightsourceip=%config

I know if I need to use specific virtual ip, I can do it manually by

To use a specific and static virtual IP (i.e. without exchanging any configuration payloads) it may simply be added to any local interface (even lo) and referenced in the client's local traffic selector (local_ts in swanctl.conf or leftsubnet in ipsec.conf). Configuring such an IP as in the example above will not have the intended effect because the IP won't get installed on the system unless the server actually assigns that IP to the client with a configuration payload.

But it requires me to write additional updown scripts to add that VIP to interface, and maybe change the incorrect route table because of #3170.
So I prefer using the equivalent setting of rightsourceip=%config in responder's swanctl.conf, and the initiator can install the requested VIP automatically during VIP negotiation.

History

#1 Updated by Tobias Brunner 9 days ago

  • Category changed from charon-systemd to configuration
  • Status changed from New to Feedback

However, the actual behavior I observed is no matter the requested vip is available or not, the responder will always return a new one, which is 10.10.0.1 in this case, ignoring what is requested by initiator.

Yes, it's nowhere documented that the client can request a particular IP address. Only during a reauthentication will the requested IP address be reassigned.

It seems that the behavior of righsourceip = %config is not supported in responder's swanctl.conf

Correct, it isn't.

But it requires me to write additional updown scripts to add that VIP to interface

It doesn't, just install it before starting the connection.

Why not assign the virtual IP address based on the client's identity?

Also available in: Atom PDF