Oh also I noticed that the port used for VXLAN is always udp 4789
<https://github.com/openvswitch/ovs/blob/19d809afb3525eb6aeb8dafc8eb5d13deca8da04/ipsec/ovs-monitor-ipsec.in#L69-L78>.
Then I suppose I can just always hard code that in our strongSwan policy?
On Mon, Aug 19, 2024 at 12:12 PM Jim C <jimc84...@gmail.com> wrote:
> 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
