On 8/20/24 00:10, Jim C via discuss wrote: > Oh also I noticed that the port used for VXLAN is always udp 4789. > Then I suppose I can just always hard code that in our strongSwan policy?
Yes, 4789 is a registered port for VXLAN: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers If you use Geneve tunnels, it will be 6081. It is possible to override with 'dst_port' option, but it is rarely used. If 'dst_port' is not specified, then it will be 4789 for VXLAN. > > 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. With such a configuration all the UDP traffic that goes to port 1234 on 10.0.0.2 will be encrypted. Tunnels are listening on a specific UDP port, so only traffic to this port on a particular remote machine is affected. > > 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"? Hard to tell, but it seems like BFD didn't start on that interface. What 'ovs-appctl bfd/show' tells? Any clues in the logs? > > Thanks, > Jim > > On Mon, Aug 19, 2024 at 4:52 AM Ilya Maximets <i.maxim...@ovn.org > <mailto: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 _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
