In case when there is no local/remote prefix configured in a tunnel settings, a protocol configured for such tunnel is ignored.
Example:
set vpn ipsec esp-group e1 proposal 10 encryption 'aes256' set vpn ipsec esp-group e1 proposal 10 hash 'sha256' set vpn ipsec ike-group i1 proposal 10 encryption 'aes256' set vpn ipsec ike-group i1 proposal 10 hash 'sha256' set vpn ipsec site-to-site peer p1 authentication mode 'pre-shared-secret' set vpn ipsec site-to-site peer p1 connection-type 'none' set vpn ipsec site-to-site peer p1 default-esp-group 'e1' set vpn ipsec site-to-site peer p1 ike-group 'i1' set vpn ipsec site-to-site peer p1 local-address '192.168.122.5' set vpn ipsec site-to-site peer p1 remote-address '192.168.122.6' set vpn ipsec site-to-site peer p1 tunnel 1 protocol 'gre'
Will create the following config:
children {
p1-tunnel-1 {
esp_proposals = aes256-sha256-modp1024
life_time = 3600s
ipcomp = no
mode = tunnel
start_action = none
close_action = none
replay_window = 32
}
}But, if we add an IP prefix, then the selector will be set up as expected:
set vpn ipsec site-to-site peer p1 tunnel 1 local prefix '192.168.122.5/32'
children {
p1-tunnel-1 {
esp_proposals = aes256-sha256-modp1024
life_time = 3600s
local_ts = 192.168.122.5/32[gre/]
ipcomp = no
mode = tunnel
start_action = none
close_action = none
replay_window = 32
}
}This inconsistency leads to a situation where an established IPSec connection matches traffic that it should not.
According to the strongSwan manual, if there are no prefixes configured explicitly, a special dynamic option is used, which we can see in the swanctl -L output:
p1-tunnel-1: TUNNEL, rekeying every 3272s local: 192.168.122.5/32[gre] remote: dynamic
The correct way to generate the configuration is to set the prefix to dynamic if it was not set. The correct config for the described case is:
local_ts = dynamic[gre/] remote_ts = dynamic[gre/]