Issue #3171
Unexpected behavior in Virtual IP negotiation when requesting specifc virtual ip in swanctl.conf by initiator
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 over 1 year 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?
#2 Updated by Tobias Brunner 4 months ago
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to No feedback