2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 09:58:01 +00:00
ovs/tests/system-ipsec.at

836 lines
32 KiB
Plaintext
Raw Normal View History

AT_BANNER(IPsec)
dnl IPSEC_SETUP_UNDERLAY()
dnl
dnl Configure anything required in the underlay network
m4_define([IPSEC_SETUP_UNDERLAY],
[AT_CHECK([cp ${abs_top_srcdir}/vswitchd/vswitch.ovsschema vswitch.ovsschema])
dnl Set up the underlay switch
AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])])
m4_define([START_PLUTO], [
rm -f $ovs_base/$1/pluto.pid
mkdir -p $ovs_base/$1/ipsec.d
touch $ovs_base/$1/ipsec.conf
touch $ovs_base/$1/secrets
ipsec initnss --nssdir $ovs_base/$1/ipsec.d
NS_CHECK_EXEC([$1], [ipsec pluto --config $ovs_base/$1/ipsec.conf \
--ipsecdir $ovs_base/$1 --nssdir $ovs_base/$1/ipsec.d \
--logfile $ovs_base/$1/pluto.log --secretsfile $ovs_base/$1/secrets \
--rundir $ovs_base/$1], [0], [], [stderr])
])
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
dnl IPSEC_ADD_NODE([namespace], [device], [address], [peer address],
dnl [custom-ipsec-conf], [extra])
dnl
dnl Creates a dummy host that acts as an IPsec endpoint. Creates host in
dnl 'namespace' and attaches a veth 'device' to 'namespace' to act as the host
dnl NIC. Assigns 'address' to 'device' and adds the other end of veth 'device' to
dnl 'br0' which is an OVS bridge in the default namespace acting as an underlay
dnl switch. Sets the default gateway of 'namespace' to 'peer address'.
dnl
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
dnl Starts all daemons in 'namespace' that are required for IPsec.
dnl
dnl If 'custom-ipsec-conf' is provided, then it will be used as --ipsec-conf
dnl and the ipsec.conf will be used as --root-ipsec-conf.
dnl
dnl If 'extra' is provided, passes it as an additional argument list for
dnl ovs-monitor-ipsec.
m4_define([IPSEC_ADD_NODE],
[ADD_NAMESPACES($1)
dnl Disable DAD. We know we wont get duplicates on this underlay network.
NS_EXEC([$1], [sysctl -w net.ipv6.conf.all.accept_dad=0])
NS_EXEC([$1], [sysctl -w net.ipv6.conf.default.accept_dad=0])
ADD_VETH($2, $1, br0, $3/24)
NS_EXEC([$1], [ip route add default via $4 dev $2])
mkdir -p $ovs_base/$1
touch $ovs_base/$1/.conf.db.~lock~
NS_EXEC([$1], [ovsdb-tool create $ovs_base/$1/conf.db \
$abs_top_srcdir/vswitchd/vswitch.ovsschema], [0], [], [stderr])
dnl Start ovsdb-server.
NS_EXEC([$1],[ovsdb-server $ovs_base/$1/conf.db --detach --no-chdir \
--log-file=$ovs_base/$1/ovsdb.log --pidfile=$ovs_base/$1/ovsdb.pid \
--remote=punix:$OVS_RUNDIR/$1/db.sock], [0], [], [stderr])
on_exit "kill `cat $ovs_base/$1/ovsdb.pid`"
NS_EXEC([$1], [ovs-vsctl --no-wait init])
dnl Start ovs-vswitchd.
NS_EXEC([$1], [ovs-vswitchd unix:${OVS_RUNDIR}/$1/db.sock --detach \
--no-chdir --pidfile=$ovs_base/$1/vswitchd.pid \
--unixctl=$ovs_base/$1/vswitchd.ctl \
--log-file=$ovs_base/$1/vswitchd.log -vvconn -vofproto_dpif -vunixctl],\
[0], [], [stderr])
on_exit "kill_ovs_vswitchd `cat $ovs_base/$1/vswitchd.pid`"
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
m4_if([$5], [], [], [
AT_CHECK([echo "## A read-only root config. ##" > $ovs_base/$1/ipsec.conf])
AT_CHECK([echo "include $ovs_base/$1/$5" >> $ovs_base/$1/ipsec.conf])
])
AT_CHECK
dnl Start pluto
START_PLUTO([$1])
on_exit 'kill $(cat $ovs_base/$1/pluto.pid)'
dnl Start ovs-monitor-ipsec
NS_CHECK_EXEC([$1], [ovs-monitor-ipsec unix:${OVS_RUNDIR}/$1/db.sock\
--pidfile=${OVS_RUNDIR}/$1/ovs-monitor-ipsec.pid --ike-daemon=libreswan\
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
--ipsec-conf=$ovs_base/$1/m4_if([$5], [], [ipsec.conf], [$5]) \
m4_if([$5], [], [], [--root-ipsec-conf=$ovs_base/$1/ipsec.conf]) \
--ipsec-d=$ovs_base/$1/ipsec.d \
--ipsec-secrets=$ovs_base/$1/secrets \
--log-file=$ovs_base/$1/ovs-monitor-ipsec.log \
--ipsec-ctl=$ovs_base/$1/pluto.ctl \
m4_if([$6], [], [], [$6]) \
--no-restart-ike-daemon --detach ], [0], [], [stderr])
on_exit "kill `cat $ovs_base/$1/ovs-monitor-ipsec.pid`"
dnl Set up OVS bridge
NS_CHECK_EXEC([$1],
[ovs-vsctl --db unix:$ovs_base/$1/db.sock add-br br-ipsec \
-- set-controller br-ipsec punix:$ovs_base/br-ipsec.$1.mgmt])]
)
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
m4_define([IPSEC_ADD_NODE_LEFT],
[IPSEC_ADD_NODE(left, p0, $1, $2, [$3], [$4])])
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
m4_define([IPSEC_ADD_NODE_RIGHT],
[IPSEC_ADD_NODE(right, p1, $1, $2, [$3], [$4])])
dnl OVS_VSCTL([namespace], [sub-command])
dnl
dnl Runs `ovs-vsctl 'sub-command'` in 'namespace'
m4_define([OVS_VSCTL],
[[ip netns exec $1 ovs-vsctl --db unix:$ovs_base/$1/db.sock $2 ]])
m4_define([OVS_VSCTL_LEFT], [OVS_VSCTL(left, $1)])
m4_define([OVS_VSCTL_RIGHT], [OVS_VSCTL(right, $1)])
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
dnl IPSEC_ADD_TUNNEL([namespace], [type], [options]])
dnl
dnl Creates a tunnel of type 'type' in namespace 'namespace' using 'options'
m4_define([IPSEC_ADD_TUNNEL],
[OVS_VSCTL([$1], [add-port br-ipsec tun -- set Interface tun type=$2 $3])
dnl Wait for all expected connections to be loaded into Libreswan.
dnl GRE creates 1 connection, all others create 2.
m4_if($2, [gre],
[OVS_WAIT_UNTIL([test `IPSEC_STATUS_LOADED($1)` -eq 1])],
[OVS_WAIT_UNTIL([test `IPSEC_STATUS_LOADED($1)` -eq 2])])
])
m4_define([IPSEC_ADD_TUNNEL_LEFT], [IPSEC_ADD_TUNNEL(left, $1, $2)])
m4_define([IPSEC_ADD_TUNNEL_RIGHT], [IPSEC_ADD_TUNNEL(right, $1, $2)])
dnl CHECK_LIBRESWAN()
dnl
dnl Check if necessary Libreswan dependencies are available on the test machine
m4_define([CHECK_LIBRESWAN],
[dnl Skip tests if system has not been set up for Libreswan
AT_SKIP_IF([!(ipsec --version | grep Libreswan)])
AT_SKIP_IF([test ! -x $(which certutil)])
AT_SKIP_IF([test ! -x $(which pk12util)])
AT_SKIP_IF([test ! -x $(which openssl)])
dnl If '$ovs_base' is too long, the following Libreswan issue will trigger
dnl so we check that it is not too long and skip test if it is.
dnl https://github.com/libreswan/libreswan/issues/428
AT_SKIP_IF([test "${#ovs_base}" -gt "90" ])])
dnl IPSEC_SA_LIST([namespace], [output-file])
dnl
dnl Get numbers of all the currently active SAs.
m4_define([IPSEC_SA_LIST], [
AT_CHECK([ipsec --rundir $ovs_base/$1 status > $2.status])
AT_CHECK([grep -oE '#[0-9]+:' $2.status | sort -u], [0], [stdout])
AT_CHECK([mv stdout $2])
])
dnl IPSEC_STATUS_LOADED([])
dnl
dnl Get number of loaded connections from ipsec status
m4_define([IPSEC_STATUS_LOADED], [
ipsec --rundir $ovs_base/$1 status | \
grep "Total IPsec connections" | \
sed 's/[[0-9]]* *Total IPsec connections: loaded \([[0-9]]*\), active \([[0-9]]*\).*/\1/m'])
dnl IPSEC_STATUS_ACTIVE([])
dnl
dnl Get number of active connections from ipsec status
m4_define([IPSEC_STATUS_ACTIVE], [
ipsec --rundir $ovs_base/$1 status | \
grep "Total IPsec connections" | \
sed 's/[[0-9]]* *Total IPsec connections: loaded \([[0-9]]*\), active \([[0-9]]*\).*/\2/m'])
dnl CHECK_ESP_TRAFFIC()
dnl
dnl Checks for connectivity between nodes and that the underlay traffic is ESP.
m4_define([CHECK_ESP_TRAFFIC],
[dnl Add test interfaces for pinging
NS_EXEC([left], [ip addr add 192.0.0.1/24 dev br-ipsec])
NS_EXEC([left], [ip link set dev br-ipsec up])
NS_EXEC([right], [ip addr add 192.0.0.2/24 dev br-ipsec])
NS_EXEC([right], [ip link set dev br-ipsec up])
dnl Capture any underlay esp packets
OVS_DAEMONIZE([tcpdump -l -nn -i ovs-p0 esp > $ovs_base/left/tcpdump.log], [tcpdump0.pid])
OVS_DAEMONIZE([tcpdump -l -nn -i ovs-p1 esp > $ovs_base/right/tcpdump.log], [tcpdump1.pid])
dnl Wait for all loaded connections to be active
OVS_WAIT_UNTIL([test `IPSEC_STATUS_LOADED(left)` -eq `IPSEC_STATUS_ACTIVE(left)`])
OVS_WAIT_UNTIL([test `IPSEC_STATUS_LOADED(right)` -eq `IPSEC_STATUS_ACTIVE(right)`])
dnl Ping over IPsec tunnel
tests: Use ping timeout instead of deadline. Many system tests currently use ping with the combination of a low packet count (-c 3), short interval between sends (-i 0.3) and a _deadline_ of 2 seconds (-d 2). This combination of options may lead to a situation where more than count packets are sent however ping will stop when count packets are received. This results in a failed test due to how the result is checked, for example: ping6 -q -c 3 -i 0.3 -w 2 fc00::3 | FORMAT_PING @@ -1,2 +1,2 @@ -3 packets transmitted, 3 received, 0% packet loss, time 0ms +4 packets transmitted, 3 received, 25% packet loss, time 0ms To reiterate, in the above example there is no packet loss, but ping stops after _receiving_ 3 packets, not bothering with waiting for the response to the fourth packet it just sent out. If we look at the iputils ping manual for the -w deadline option we can read that this is expected behavior: > Specify a timeout, in seconds, before ping exits regardless of > how many packets have been sent or received. In this case ping > does not stop after count packet are sent, it waits either for > deadline expire or until count probes are answered or for some > error notification from network. To avoid these kinds of failures in checks where a response is expected, we replace ping -w with ping -W. We keep ping -w for checks where it is expected to NOT get a response. Acked-by: Simon Horman <horms@ovn.org> Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2023-10-21 17:04:48 +02:00
NS_CHECK_EXEC([left], [ping -q -c 3 -i 0.3 -W 2 192.0.0.2 | FORMAT_PING], [0], [dnl
3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
tests: Use ping timeout instead of deadline. Many system tests currently use ping with the combination of a low packet count (-c 3), short interval between sends (-i 0.3) and a _deadline_ of 2 seconds (-d 2). This combination of options may lead to a situation where more than count packets are sent however ping will stop when count packets are received. This results in a failed test due to how the result is checked, for example: ping6 -q -c 3 -i 0.3 -w 2 fc00::3 | FORMAT_PING @@ -1,2 +1,2 @@ -3 packets transmitted, 3 received, 0% packet loss, time 0ms +4 packets transmitted, 3 received, 25% packet loss, time 0ms To reiterate, in the above example there is no packet loss, but ping stops after _receiving_ 3 packets, not bothering with waiting for the response to the fourth packet it just sent out. If we look at the iputils ping manual for the -w deadline option we can read that this is expected behavior: > Specify a timeout, in seconds, before ping exits regardless of > how many packets have been sent or received. In this case ping > does not stop after count packet are sent, it waits either for > deadline expire or until count probes are answered or for some > error notification from network. To avoid these kinds of failures in checks where a response is expected, we replace ping -w with ping -W. We keep ping -w for checks where it is expected to NOT get a response. Acked-by: Simon Horman <horms@ovn.org> Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2023-10-21 17:04:48 +02:00
NS_CHECK_EXEC([right], [ping -q -c 3 -i 0.3 -W 2 192.0.0.1 | FORMAT_PING], [0], [dnl
3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
dnl Check for esp traffic
dnl Note: Geneve tests may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
AT_CHECK([cat $ovs_base/left/tcpdump.log | grep ESP], [0], [stdout], [stderr])
AT_CHECK([cat $ovs_base/right/tcpdump.log | grep ESP], [0], [stdout], [stderr])])
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, defaultroute, psk)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, localip, psk)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 \
options:local_ip=10.1.1.1 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 \
options:local_ip=10.1.1.2 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, defaultroute, self-signed)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve self-signed])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Create and set self-signed certs
ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log req -u left
ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log req -u right
ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log self-sign left
ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log self-sign right
OVS_VSCTL_LEFT(set Open_vSwitch . \
other_config:certificate=${ovs_base}/left-cert.pem \
other_config:private_key=${ovs_base}/left-privkey.pem)
OVS_VSCTL_RIGHT(set Open_vSwitch . \
other_config:certificate=${ovs_base}/right-cert.pem \
other_config:private_key=${ovs_base}/right-privkey.pem)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 \
options:remote_cert=${ovs_base}/right-cert.pem])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 \
options:remote_cert=${ovs_base}/left-cert.pem])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, defaultroute, ca-signed)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve ca-signed])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Create and set ca-signed certs
ovs-pki --force -b --dir=${ovs_base} -l ${ovs_base}/ovs-pki.log init
ovs-pki -b --dir=${ovs_base} -l ${ovs_base}/ovs-pki.log req+sign -u left
ovs-pki -b --dir=${ovs_base} -l ${ovs_base}/ovs-pki.log req+sign -u right
OVS_VSCTL_LEFT(set Open_vSwitch . \
other_config:ca_cert=${ovs_base}/switchca/cacert.pem \
other_config:certificate=${ovs_base}/left-cert.pem \
other_config:private_key=${ovs_base}/left-privkey.pem)
OVS_VSCTL_RIGHT(set Open_vSwitch . \
other_config:ca_cert=${ovs_base}/switchca/cacert.pem \
other_config:certificate=${ovs_base}/right-cert.pem \
other_config:private_key=${ovs_base}/right-privkey.pem)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 options:remote_name=right])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 options:remote_name=left])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, gre, defaultroute, psk)])
AT_KEYWORDS([ipsec libreswan ipv4 gre psk])
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([gre],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([gre],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, vxlan, defaultroute, psk)])
AT_KEYWORDS([ipsec libreswan ipv4, vxlan psk])
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2)
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([vxlan],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([vxlan],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv6, vxlan, defaultroute, psk)])
AT_KEYWORDS([ipsec libreswan ipv6 vxlan psk])
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(fd01::101, fd01::102)
IPSEC_ADD_NODE_RIGHT(fd01::102, fd01::101)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([vxlan],
[options:remote_ip=fd01::102 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([vxlan],
[options:remote_ip=fd01::101 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv6, vxlan, localip, psk)])
AT_KEYWORDS([ipsec libreswan ipv6 vxlan psk])
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(fd01::101, fd01::102)
IPSEC_ADD_NODE_RIGHT(fd01::102, fd01::101)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([vxlan],
[options:remote_ip=fd01::102 \
options:local_ip=fd01::101 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([vxlan],
[options:remote_ip=fd01::101 \
options:local_ip=fd01::102 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv6, geneve, defaultroute, psk)])
AT_KEYWORDS([ipsec libreswan ipv6 geneve psk])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up dummy hosts
IPSEC_ADD_NODE_LEFT(fd01::101, fd01::102)
IPSEC_ADD_NODE_RIGHT(fd01::102, fd01::101)
dnl Set up IPsec tunnel on 'left' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=fd01::102 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host
ipsec: Fix race in system tests. This patch fixes an issue where, depending on timing fluctuations, each node has not fully loaded all connections before the other node begins to establish a connection. In this failure case, the "ovs-monitor-ipsec" instance on the "left" node may `ipsec auto --start` a connection which then gets rejected by the "right" side. Almost, simulaneously, the "right" side may initiate a connection that gets rejected by the "left" side. This can happen as, for all tunnels except for GRE, each node has two connections (an "in" connection and an "out" connection) that get added one after the other. If the "in" connection "starts" on both sides, the "out" connection from the other node may not be available causing the connection to fail. At this point, "Libreswan" will wait to retry the connection. In the interim, the OVS system test times out. This race manifests itself more frequently in a virtualized environment. This patch resolves this issue by waiting for the "left" node to load all connections before starting the "right" side. This will cause the "left" side to fail to establish a connection with the "right" side (as the "right" side connections have not been loaded) but will cause the "right" side to succeed to establish a connection as all connections will have been loaded on the "left" side. Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/381857.html Fixes: 8fc62df8b135 ("ipsec: Introduce IPsec system tests for Libreswan.") Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Tested-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-04-13 13:06:40 -04:00
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=fd01::101 options:psk=swordfish])
CHECK_ESP_TRAFFIC
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
ipsec: Add support for using non-root ipsec.conf. Typical configuration file hierarchy for Libreswan in distributions looks like this: /etc /ipsec.conf /ipsec.d /*.conf /crypto-policies/back-ends/libreswan.config The root ipsec.conf contains the 'setup' section with the base configuration of the IKE daemon, includes system-wide crypto-policies and all the sub-config files in ipsec.d folder describing connections. ovs-monitor-ipsec today is not able to leverage this structure, because it requires the complete ownership of the ipsec.conf. If someone attempts to pass a sub-config file to the daemon in order to make it not overwrite the root ipsec.conf, this may cause a lot of trouble: 1. New tunnel is created in OVS. 2. ovs-monitor-ipsec writes it into sub-config file. 3. ovs-monitor-ipsec calls ipsec --start conn --config sub-config 4. Libreswan starts connection using configuration from only the sub-config and not taking into account any other file. 5. Re-start Libreswan. 6. Libreswan now reads all the files and configures connections using information from all the configuration files, including system-wide crypto policies and other potential 'conn %default' sections from all the files. 7. Now the connection is configured differently and potentially in an incompatible way with the other side. Worst of all is the behavior is unpredictable, taking into account the re-start can happen due to a crash or other random event. Another point is that 'setup' and 'conn %default' sections defined in our sub-config file will also bleed out configuration to connections defined in other files. And it's hard to say in which order configuration will be applied, because it's not clear in which order the files are included and parsed. So, this kind of file structure cannot be safely used. Let's add a minimal support for running with a sub-config. A new option '--root-ipsec-conf' is introduced to specify the location of the root ipsec.conf file, so ovs-monitor-ipsec can provide it while calling ipec commands instead. This will make Libreswan (pluto) to parse the whole tree of includes and apply the same configuration every time, regardless of restarts and other issues. When this new option is set, ovs-monitor-ipsec will also not define the 'setup' section to avoid overriding global configuration and will not define 'conn %default' section for the same reason. Instead, important connection options will be defined for every connection, so they are still applied without polluting defaults. The 'setup' section is just omitted in this case. We only define 'uniqeids', but it's true by default and we may assume users know what are they doing if they are changing this config in the main ipsec.conf. The Libreswan documentation also discourages from turning this option off and mentions that it may be removed in the future. Only implementing for Libreswan, because we do not even support non-default location of ipsec.conf with StrongSwan today. Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-12-11 00:07:03 +01:00
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, custom conf)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk custom conf])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up hosts.
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2, [custom.conf])
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1, [custom.conf])
dnl Set up IPsec tunnel on 'left' host.
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host.
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
dnl Check that custom.conf doesn't include default section, but has
dnl ike and esp configuration per connection.
AT_CHECK([grep -q "conn %default" $ovs_base/left/custom.conf], [1])
AT_CHECK([grep -c -E "(ike|ikev2|esp)=" $ovs_base/left/custom.conf], [0], [6
])
AT_CHECK([grep -q "conn %default" $ovs_base/right/custom.conf], [1])
AT_CHECK([grep -c -E "(ike|ikev2|esp)=" $ovs_base/right/custom.conf], [0], [6
])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, default crypto)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk default crypto])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up hosts.
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2, [], [--use-default-crypto])
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1, [], [--use-default-crypto])
dnl Set up IPsec tunnel on 'left' host.
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host.
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
dnl Check that ipsec.conf doesn't include ike or esp configuration.
AT_CHECK([grep -q "conn %default" $ovs_base/left/ipsec.conf])
AT_CHECK([grep -q -E "(ike|ikev2|esp)=" $ovs_base/left/ipsec.conf], [1])
AT_CHECK([grep -q "conn %default" $ovs_base/right/ipsec.conf])
AT_CHECK([grep -q -E "(ike|ikev2|esp)=" $ovs_base/right/ipsec.conf], [1])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan (ipv4, geneve, custom conf, default crypto)])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk custom conf default crypto])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up hosts.
IPSEC_ADD_NODE_LEFT(10.1.1.1, 10.1.1.2, [custom.conf], [--use-default-crypto])
IPSEC_ADD_NODE_RIGHT(10.1.1.2, 10.1.1.1, [custom.conf], [--use-default-crypto])
dnl Set up IPsec tunnel on 'left' host.
IPSEC_ADD_TUNNEL_LEFT([geneve],
[options:remote_ip=10.1.1.2 options:psk=swordfish])
dnl Set up IPsec tunnel on 'right' host.
IPSEC_ADD_TUNNEL_RIGHT([geneve],
[options:remote_ip=10.1.1.1 options:psk=swordfish])
CHECK_ESP_TRAFFIC
dnl Check that custom.conf doesn't include default section, and also doesn't
dnl have ike or esp configuration.
AT_CHECK([grep -q "conn %default" $ovs_base/left/custom.conf], [1])
AT_CHECK([grep -q -E "(ike|ikev2|esp)=" $ovs_base/left/custom.conf], [1])
AT_CHECK([grep -q "conn %default" $ovs_base/right/custom.conf], [1])
AT_CHECK([grep -q -E "(ike|ikev2|esp)=" $ovs_base/right/custom.conf], [1])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan - established conns survive new additions - ipv4])
AT_KEYWORDS([ipsec libreswan ipv4 geneve psk persistence])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up hosts.
IPSEC_ADD_NODE_LEFT([10.1.1.1], [10.1.1.254])
IPSEC_ADD_NODE_RIGHT([10.1.1.2], [10.1.1.254])
m4_define([PSK_OPTIONS], [options:remote_ip=$1 options:psk=swordfish])
dnl Set up IPsec tunnel on a 'left' host.
IPSEC_ADD_TUNNEL_LEFT([geneve], PSK_OPTIONS([10.1.1.2]))
dnl Set up IPsec tunnel on a 'right' host.
IPSEC_ADD_TUNNEL_RIGHT([geneve], PSK_OPTIONS([10.1.1.1]))
CHECK_ESP_TRAFFIC
dnl Get the numbers of all the current SAs.
IPSEC_SA_LIST([left], [left/sa.before])
IPSEC_SA_LIST([right], [right/sa.before])
dnl Add a third host and wire it up only to the left to avoid creating a loop.
IPSEC_ADD_NODE([third], [p3], [10.1.1.3], [10.1.1.254])
IPSEC_ADD_TUNNEL([third], [geneve], PSK_OPTIONS([10.1.1.1]))
OVS_VSCTL([left], add-port br-ipsec tun3 \
-- set Interface tun3 type=geneve PSK_OPTIONS([10.1.1.3]))
dnl Wait for all the expected connections to be loaded into Libreswan.
dnl 2 tunnels == 4 connections.
OVS_WAIT_UNTIL([test $(IPSEC_STATUS_LOADED(left)) -eq 4])
dnl Wait for tunnels to become active.
OVS_WAIT_UNTIL([test $(IPSEC_STATUS_LOADED(left)) \
-eq $(IPSEC_STATUS_ACTIVE(left))])
OVS_WAIT_UNTIL([test $(IPSEC_STATUS_LOADED(third)) \
-eq $(IPSEC_STATUS_ACTIVE(third))])
dnl Check that the original left-right tunnel still works.
NS_CHECK_EXEC([left], [ping -q -c 3 -i 0.1 -W 2 192.0.0.2 | FORMAT_PING], [0],
[3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
NS_CHECK_EXEC([right], [ping -q -c 3 -i 0.1 -W 2 192.0.0.1 | FORMAT_PING], [0],
[3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
dnl Check that ovs-monitor-ipsec didn't touch the original tunnel.
IPSEC_SA_LIST([left], [left/sa.after])
IPSEC_SA_LIST([right], [right/sa.after])
dnl Right SAs should not change at all.
AT_CHECK([diff -u right/sa.before right/sa.after])
dnl Left SAs should be the same, but there will be new ones for the third conn.
AT_CHECK([test $(grep -c ':' left/sa.after) -gt $(grep -c ':' left/sa.before)])
AT_CHECK([head -n $(grep -c ':' left/sa.before) left/sa.after \
| diff -u - left/sa.before])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan - established conns survive new additions - ipv6])
AT_KEYWORDS([ipsec libreswan ipv6 geneve psk persistence])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
dnl Set up hosts.
IPSEC_ADD_NODE_LEFT([fd01::101], [fd01::254])
IPSEC_ADD_NODE_RIGHT([fd01::102], [fd01::254])
m4_define([PSK_OPTIONS], [options:remote_ip=$1 options:psk=swordfish])
dnl Set up IPsec tunnel on a 'left' host.
IPSEC_ADD_TUNNEL_LEFT([geneve], PSK_OPTIONS([fd01::102]))
dnl Set up IPsec tunnel on a 'right' host.
IPSEC_ADD_TUNNEL_RIGHT([geneve], PSK_OPTIONS([fd01::101]))
CHECK_ESP_TRAFFIC
dnl Get the numbers of all the current SAs.
IPSEC_SA_LIST([left], [left/sa.before])
IPSEC_SA_LIST([right], [right/sa.before])
dnl Add a third host and wire it up only to the left to avoid creating a loop.
IPSEC_ADD_NODE([third], [p3], [fd01::103], [fd01::254])
IPSEC_ADD_TUNNEL([third], [geneve], PSK_OPTIONS([fd01::101]))
OVS_VSCTL([left], add-port br-ipsec tun3 \
-- set Interface tun3 type=geneve PSK_OPTIONS([fd01::103]))
dnl Wait for all the expected connections to be loaded into Libreswan.
dnl 2 tunnels == 4 connections.
OVS_WAIT_UNTIL([test `IPSEC_STATUS_LOADED(left)` -eq 4])
dnl Wait for tunnels to become active.
OVS_WAIT_UNTIL([test $(IPSEC_STATUS_LOADED(left)) \
-eq $(IPSEC_STATUS_ACTIVE(left))])
OVS_WAIT_UNTIL([test $(IPSEC_STATUS_LOADED(third)) \
-eq $(IPSEC_STATUS_ACTIVE(third))])
dnl Check that the original left-right tunnel still works.
NS_CHECK_EXEC([left], [ping -q -c 3 -i 0.1 -W 2 192.0.0.2 | FORMAT_PING], [0],
[3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
NS_CHECK_EXEC([right], [ping -q -c 3 -i 0.1 -W 2 192.0.0.1 | FORMAT_PING], [0],
[3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
dnl Check that ovs-monitor-ipsec didn't touch the original tunnel.
IPSEC_SA_LIST([left], [left/sa.after])
IPSEC_SA_LIST([right], [right/sa.after])
dnl Right SAs should not change at all.
AT_CHECK([diff -u right/sa.before right/sa.after])
dnl Left SAs should be the same, but there will be new ones for the third conn.
AT_CHECK([test $(grep -c ':' left/sa.after) -gt $(grep -c ':' left/sa.before)])
AT_CHECK([head -n $(grep -c ':' left/sa.before) left/sa.after \
| diff -u - left/sa.before])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP
AT_SETUP([IPsec -- Libreswan NxN geneve tunnels + reconciliation])
AT_KEYWORDS([ipsec libreswan scale reconciliation])
dnl Note: Geneve test may not work on older kernels due to CVE-2020-25645
dnl https://bugzilla.redhat.com/show_bug.cgi?id=1883988
CHECK_LIBRESWAN()
OVS_TRAFFIC_VSWITCHD_START()
IPSEC_SETUP_UNDERLAY()
m4_define([NODES], [20])
dnl Set up fake hosts.
m4_for([id], [1], NODES, [1], [
IPSEC_ADD_NODE([node-id], [p-id], 10.1.1.id, 10.1.1.254)
AT_CHECK([ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log \
req -u node-id], [0], [stdout])
AT_CHECK([ovs-pki -b -d ${ovs_base} -l ${ovs_base}/ovs-pki.log \
self-sign node-id], [0], [stdout])
AT_CHECK(OVS_VSCTL([node-id], set Open_vSwitch . \
other_config:certificate=${ovs_base}/node-id-cert.pem \
other_config:private_key=${ovs_base}/node-id-privkey.pem \
-- set bridge br-ipsec other-config:hwaddr=f2:ff:00:00:00:id),
[0], [ignore], [ignore])
on_exit "ipsec --rundir $ovs_base/node-id status > $ovs_base/node-id/status"
])
dnl Create a full mesh of tunnels.
m4_for([LEFT], [1], NODES, [1], [
m4_for([RIGHT], [1], NODES, [1], [
if test LEFT -ne RIGHT; then
AT_CHECK(OVS_VSCTL(node-LEFT, add-port br-ipsec tun-RIGHT \
-- set Interface tun-RIGHT type=geneve options:remote_ip=10.1.1.RIGHT \
options:remote_cert=${ovs_base}/node-RIGHT-cert.pem),
[0], [ignore], [ignore])
fi
])])
dnl These are not necessary, but nice to have in the test log in
dnl order to spot pluto failures during the test.
on_exit "grep -E 'Timed out|outdated|half-loaded|defunct' \
$ovs_base/node-*/ovs-monitor-ipsec.log"
on_exit "grep -E 'ABORT|ERROR' $ovs_base/node-*/pluto.log"
m4_define([WAIT_FOR_LOADED_CONNS], [
m4_for([id], [1], NODES, [1], [
echo "================== node-id ========================="
iterations=0
loaded=0
active=0
dnl Using a custom loop instead of OVS_WAIT_UNTIL, because it may take
dnl much longer than a default timeout. The default retransmit timeout
dnl for pluto is 60 seconds. Also, we need to make sure pluto didn't
dnl crash in the process and revive it if it did, unfortunately.
while true; do
date
AT_CHECK([ipsec --rundir $ovs_base/node-id status 2>&1 \
| grep -E "whack|Total"], [ignore], [stdout])
if grep -E 'is Pluto running?|refused' stdout; then
echo "node-id: Pluto died, restarting..."
START_PLUTO([node-id])
else
loaded=$(IPSEC_STATUS_LOADED(node-id))
m4_if([$1], [active],
[active=$(IPSEC_STATUS_ACTIVE(node-id))], [active=$loaded])
fi
if test "$loaded" -ne "$(( (NODES - 1) * 2 ))" -o \
"$loaded" -ne "$active"; then
sleep 3
else
break
fi
let iterations=$iterations+1
AT_CHECK([test $iterations -lt 100])
done
])
])
dnl Wait for all the connections to be loaded to pluto. Not waiting for
dnl them to become active, because if pluto is down on one of the nodes,
dnl some connections may not become active until we revive it. Some
dnl connections may also never become active due to bugs in libreswan 4.x.
WAIT_FOR_LOADED_CONNS()
AT_CHECK([ipsec auto --help], [ignore], [ignore], [stderr])
auto=auto
if test -s stderr; then
auto=
fi
dnl Remove connections for two tunnels. One fully and one partially.
AT_CHECK([ipsec $auto --ctlsocket $ovs_base/node-1/pluto.ctl \
--config $ovs_base/node-1/ipsec.conf \
--delete tun-5-out-1], [0], [stdout])
AT_CHECK([ipsec $auto --ctlsocket $ovs_base/node-1/pluto.ctl \
--config $ovs_base/node-1/ipsec.conf \
--delete tun-2-in-1], [0], [stdout])
AT_CHECK([ipsec $auto --ctlsocket $ovs_base/node-1/pluto.ctl \
--config $ovs_base/node-1/ipsec.conf \
--delete tun-2-out-1], [0], [stdout])
dnl Wait for the monitor to notice the missing connections.
OVS_WAIT_UNTIL([grep -q 'tun-2.*need to reconcile' \
$ovs_base/node-1/ovs-monitor-ipsec.log])
dnl Wait for all the connections to be loaded back.
WAIT_FOR_LOADED_CONNS()
dnl Next section will check connectivity between all the nodes.
dnl Different versions of Libreswan 4.x have issues where connections
dnl are not being correctly established or never become active in a
dnl way that can not be mitigated from ovs-monitor-ipsec or the test.
dnl So, only checking connectivity for Libreswan 3- or 5+.
dnl Skipping in the middle of the test, so test can still fail while
dnl testing with Libreswan 4, if the first half fails.
AT_SKIP_IF([ipsec --version 2>&1 | grep -q 'Libreswan 4\.'])
dnl Turn off IPv6 and add static ARP entries for all namespaces to avoid
dnl any broadcast / multicast traffic that would otherwise be multiplied
dnl by each node creating a traffic storm. Add specific OpenFlow rules
dnl to forward traffic to exact destinations without any MAC learning.
m4_for([LEFT], [1], NODES, [1], [
NS_CHECK_EXEC([node-LEFT], [sysctl -w net.ipv6.conf.all.disable_ipv6=1],
[0], [ignore])
AT_CHECK([ovs-ofctl del-flows unix:$ovs_base/br-ipsec.node-LEFT.mgmt])
AT_CHECK([ovs-ofctl add-flow unix:$ovs_base/br-ipsec.node-LEFT.mgmt \
"dl_dst=f2:ff:00:00:00:LEFT actions=LOCAL"])
m4_for([RIGHT], [1], NODES, [1], [
if test LEFT -ne RIGHT; then
NS_CHECK_EXEC([node-LEFT],
[ip neigh add 192.0.0.RIGHT lladdr f2:ff:00:00:00:RIGHT dev br-ipsec])
AT_CHECK([ovs-ofctl add-flow unix:$ovs_base/br-ipsec.node-LEFT.mgmt \
"dl_dst=f2:ff:00:00:00:RIGHT actions=tun-RIGHT"])
fi
])
])
dnl Bring up and add IP addresses for br-ipsec interface.
m4_for([id], [1], NODES, [1], [
echo "================== node-id ========================="
NS_CHECK_EXEC([node-id], [ip addr add 192.0.0.id/24 dev br-ipsec])
NS_CHECK_EXEC([node-id], [ip link set dev br-ipsec up])
])
dnl Wait for all the connections to be loaded and active. In case one of
dnl the pluto processes crashed some of the connections may never become
dnl active. But we did run this loop with a pluto reviving logic twice
dnl already, so the chances for pluto to be down here are much lower.
WAIT_FOR_LOADED_CONNS([active])
dnl Check the full mesh ping.
m4_for([LEFT], [1], NODES, [1], [
m4_for([RIGHT], [1], NODES, [1], [
if test LEFT -ne RIGHT; then
echo "====== ping: node-LEFT --> node-RIGHT =========="
dnl Ping without checking in case connection will recover after the
dnl first packet.
NS_CHECK_EXEC([node-LEFT],
[ping -q -c 1 -W 2 192.0.0.RIGHT | FORMAT_PING],
[ignore], [stdout])
dnl Now check. If this one fails, there is no actual connectivity.
NS_CHECK_EXEC([node-LEFT],
[ping -q -c 3 -i 0.1 -W 2 192.0.0.RIGHT | FORMAT_PING],
[0], [dnl
3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
fi
])])
OVS_TRAFFIC_VSWITCHD_STOP()
AT_CLEANUP