Thank you, Ilya, as always for the complete answer! I have some follow
up questions:
1. For the strongSwan policy that OVS creates, I see something like this
(on one of my 2 nodes) (I have also replaced the ports and the IPs with
dummy values):
config setup
uniqueids=yes
conn %default
keyingtries=%forever
type=transport
keyexchange=ikev2
auto=route
ike=aes256gcm16-sha256-modp2048
esp=aes256gcm16-modp2048
conn vx_node1-in-1
left=%any
right=10.0.0.2
authby=psk
leftprotoport=udp/1234
rightprotoport=udp
conn vx_node1-out-1
left=%any
right=10.0.0.2
authby=psk
leftprotoport=udp
rightprotoport=udp/1234
The two policies/conns are mostly identical except the protoport parts. But
does this combination mean every traffic from my source machine to the
remote machine will be encrypted? I want to understand what these policies
actually mean, mapping to the OVS configs, and how they guarantee that only
the traffic between the OVS tunnels is encrypted.
2. I tried to enable BFD to my tunnels. But the status always shows:
bfd_status: {diagnostic="No Diagnostic", flap_count="0",
forwarding="false", remote_diagnostic="No Diagnostic", remote_state=down,
state=down}
for both of my nodes. I do think the tunnel is working since our upper
layer who uses the OVS tunnel works. But why are the states all down and
it's showing "No Diagnostic"?
Thanks,
Jim
On Mon, Aug 19, 2024 at 4:52 AM Ilya Maximets <i.maxim...@ovn.org> wrote:
> On 8/18/24 11:16, Jim C via discuss wrote:
> > Hi,
> >
> > I'm looking into the implementation of StrongSwanHelper in OVS IPSec. I
> noticed that
> > we are using */usr/sbin/ipsec* for strongSwan, which means we are still
> using the
> > legacy *strongswan-starter* systemd service (which uses *charon*).
>
> That's true. The reason is that strongSwan support in ovs-monitor-ipsec
> script is
> mostly tailored for Ubuntu/Debian and, AFAICT, strongswan-starter is still
> a default
> method for running strongSwan in Ubuntu. At least, that's what is getting
> installed
> with 'apt install strongswan' on the latest Ubuntu 24.04.
>
> We should migrate to swanctl at some point, but I'm not aware of anyone
> actively
> working on this transition.
>
> > However, the environment that I'm working on is using the new strongSwan
> service
> > *strongswan* which uses *swanctl* and *charon-systemd*.
> >
> > Hence, I'm trying to see if I can modify that part of the implementation
> and integrate
> > the new strongSwan service. Now I have a couple of questions:
> >
> > 1) In function StrongSwanHelper, do we only update the new policy to
> strongSwan?
> > Do we make any updates on the OVS side (e.g. update OVS dbs, configs,
> etc.)? I.e.,
> > if we can somehow update the strongSwan policy somewhere else (e.g.
> hardcode the policy
> > in the new strongSwan config files), we don't actually need to rely on
> that OVS helper
> > function?
>
> ovs-monitor-ipsec daemon is not necessary to use IPSec with OVS. It's a
> small
> convenience daemon that monitors changes in OVS database and re-configures
> the
> IKE daemon according to these changes. It doesn't write anything back nor
> does
> it change any other configuration in OVS.
>
> So, it's mostly a convenience script that would change the tunnels if you
> change a "remote_ip" of one of the tunnels in the database, for example.
>
> If your setup is not highly dynamic, you should be able to just create a
> static
> configuration for strongSwan and update it manually when needed.
>
> >
> > 2) Currently, the way I'm using to verify if the OVS tunnel works is
> > *ovs-appctl -t ovs-monitor-ipsec tunnels/show *
> > After I manually update the strongSwan policy in its config files, I can
> see output for
> >
> > * Kernel policies installed
> > * Kernel security associations installed
> >
> > but NOT
> >
> > * IPsec connections that are active
> >
> > I checked the code and it seems expected because the result of the last
> item comes from
> > *ipsec status*, but our env doesn't have strongswan-starter so we can't
> support that command.
>
> That's correct.
>
> > But I'm more interested in the field *CFM state*. For my case, it's
> *disabled*. Does it mean
> > that the OVS tunnel is FOR SURE not working correctly? Or OVS doesn't
> know in this case?
> >
> > And in my case, is there a better way to check what's going on with the
> CFM state, and overall
> > is there another way to verify the tunnel works correctly?
>
> CFM is disabled by default and it will not be enabled until you manually
> set
> 'cfm_mpid' for your tunnels in the OVS database. So, "Disabled" means
> that the
> CFM mechanism is disabled, it does not indicate any issue with the tunnel.
> If you enable CFM and CFM detects tunnel failure, then the state will be
> "Down".
> I'd suggest to use BFD instead of CFM though, it seems to be more widely
> used.
>
> To enable BFD (check_tnl_key is not necessary, but recommended):
> ovs-vsctl set interface <tunnel> bfd:enable=true bfd:check_tnl_key=true
> Then you may monitor bfd_status column in the interface table for the
> current
> state of the tunnel. It will also show up in the ovs-vsctl show. More
> detailed
> status is also available in 'ovs-appctl bfd/show'.
>
> More info in ovs-vswitchd.conf.db(5).
>
> Best regards, Ilya Maximets.
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
