On Mon, Aug 19, 2024 at 3:40 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
> 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. > *************************** I see. And this requires both *vx_node1-in-1 and vx_node1-out-1* policies to exist at the same time. Is that correct? I guess I was a bit confused about the functionalities of the two policies, respectively. I.e. why do we need both policies to make the traffic TO port 1234 on 10.0.0.2 covered? It feels like *vx_node1-out-1* should do the work. I'm not sure what role *vx_node1-in-1* does here. It seems to me that it encrypts all the traffic from port 1234 on the source machine to any ports on 10.0.0.2. *************************** > > > > 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? > *************************** ovs-appctl bfd/show gives something like this ---- vx_node1 ---- Forwarding: false Detect Multiplier: 3 Concatenated Path Down: false TX Interval: Approx 1000ms RX Interval: Approx 1000ms Detect Time: now -763764383ms Next TX Time: now +460ms Last TX Time: now -360ms Local Flags: none Local Session State: down Local Diagnostic: No Diagnostic Local Discriminator: 0x7c0a51cb Local Minimum TX Interval: 1000ms Local Minimum RX Interval: 1000ms Remote Flags: none Remote Session State: down Remote Diagnostic: No Diagnostic Remote Discriminator: 0x0 Remote Minimum TX Interval: 0ms Remote Minimum RX Interval: 1ms Remote Detect Multiplier: 0 *************************** > > > > > 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
