Re: vxlan(4) custom destination UDP port seems not working
David Gwynne wrote: > On Wed, Nov 15, 2023 at 06:13:15AM -0700, Theo de Raadt wrote: > > Luca Di Gregorio wrote: > > > > > I'm not sure about this, but I think that public cloud datacenters filter > > > out > > > (or do something with) udp traffic to standard udp vxlan port. > > > > But that would not be a reason for allowing selection of the pre-standard > > port number. > > > > Rather, it would be a reason for provididing *any non-standard port number* > > > > Which is perhaps what the code does. But noone would actually want this. > > VXLAN on port 54? 80? Noone would want this. > > > > And if they filter it, then put it inside an underlay. The standard says > > nothing about permitting vxlan on any old random stupid port number. > > from a quick look around it appears that at least linux, juniper and > arista allow for the configuration of a non-standard port for vxlan. > linux documentation even says it defaults to the pre-iana assigned port > because their driver pre dates the standard, which is peak linux. > > independent of whether our vxlan(4) driver should support it or not, > ifconfig should be fixed to handle setting up sockaddrs for these > ioctls better anyway. OK, I am convinced.
Re: vxlan(4) custom destination UDP port seems not working
On Wed, Nov 15, 2023 at 06:13:15AM -0700, Theo de Raadt wrote: > Luca Di Gregorio wrote: > > > I'm not sure about this, but I think that public cloud datacenters filter > > out > > (or do something with) udp traffic to standard udp vxlan port. > > But that would not be a reason for allowing selection of the pre-standard > port number. > > Rather, it would be a reason for provididing *any non-standard port number* > > Which is perhaps what the code does. But noone would actually want this. > VXLAN on port 54? 80? Noone would want this. > > And if they filter it, then put it inside an underlay. The standard says > nothing about permitting vxlan on any old random stupid port number. from a quick look around it appears that at least linux, juniper and arista allow for the configuration of a non-standard port for vxlan. linux documentation even says it defaults to the pre-iana assigned port because their driver pre dates the standard, which is peak linux. independent of whether our vxlan(4) driver should support it or not, ifconfig should be fixed to handle setting up sockaddrs for these ioctls better anyway. dlg
Re: vxlan(4) custom destination UDP port seems not working
Third option :-) Il giorno dom 19 nov 2023 alle ore 18:14 Crystal Kolipe < kolip...@exoticsilicon.com> ha scritto: > On Sun, Nov 19, 2023 at 06:04:16PM +0100, Luca Di Gregorio wrote: > > Confirmed with the cloud service provider that they block input traffic > of > > type VXLAN. > > Not only the port 4789, all ports carrying VXLAN. > > Did it mention that in their terms of service? > > If not, can't you just tunnel it via IPSEC, or do they block IPSEC tunnels > as > well? > > Or just ask them if it can be enabled for your account. > > Or switch to a better provider. >
Re: vxlan(4) custom destination UDP port seems not working
On Sun, Nov 19, 2023 at 06:04:16PM +0100, Luca Di Gregorio wrote: > Confirmed with the cloud service provider that they block input traffic of > type VXLAN. > Not only the port 4789, all ports carrying VXLAN. Did it mention that in their terms of service? If not, can't you just tunnel it via IPSEC, or do they block IPSEC tunnels as well? Or just ask them if it can be enabled for your account. Or switch to a better provider.
Re: vxlan(4) custom destination UDP port seems not working
Confirmed with the cloud service provider that they block input traffic of type VXLAN. Not only the port 4789, all ports carrying VXLAN. I tested another CSP, and VXLAN traffic on OpenBSD flows as expected. On the other hand, another issue is that OpenBSD sends VXLAN traffic always with Source Port 4789, the same as Destination Port. RFC says: - Source Port: It is recommended that the UDP source port number be calculated using a hash of fields from the inner packet -- one example being a hash of the inner Ethernet frame's headers. This is to enable a level of entropy for the ECMP/load- balancing of the VM-to-VM traffic across the VXLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335]. Regards Il giorno mer 15 nov 2023 alle ore 14:15 Luca Di Gregorio ha scritto: > Fair enough. > So, I think that man page(s), and maybe code, should be corrected. > Thanks > > Il giorno mer 15 nov 2023 alle ore 14:13 Theo de Raadt < > dera...@openbsd.org> ha scritto: > >> Luca Di Gregorio wrote: >> >> > I'm not sure about this, but I think that public cloud datacenters >> filter out >> > (or do something with) udp traffic to standard udp vxlan port. >> >> But that would not be a reason for allowing selection of the pre-standard >> port number. >> >> Rather, it would be a reason for provididing *any non-standard port >> number* >> >> Which is perhaps what the code does. But noone would actually want this. >> VXLAN on port 54? 80? Noone would want this. >> >> And if they filter it, then put it inside an underlay. The standard says >> nothing about permitting vxlan on any old random stupid port number. >> >
Re: vxlan(4) custom destination UDP port seems not working
Fair enough. So, I think that man page(s), and maybe code, should be corrected. Thanks Il giorno mer 15 nov 2023 alle ore 14:13 Theo de Raadt ha scritto: > Luca Di Gregorio wrote: > > > I'm not sure about this, but I think that public cloud datacenters > filter out > > (or do something with) udp traffic to standard udp vxlan port. > > But that would not be a reason for allowing selection of the pre-standard > port number. > > Rather, it would be a reason for provididing *any non-standard port number* > > Which is perhaps what the code does. But noone would actually want this. > VXLAN on port 54? 80? Noone would want this. > > And if they filter it, then put it inside an underlay. The standard says > nothing about permitting vxlan on any old random stupid port number. >
Re: vxlan(4) custom destination UDP port seems not working
Luca Di Gregorio wrote: > I'm not sure about this, but I think that public cloud datacenters filter out > (or do something with) udp traffic to standard udp vxlan port. But that would not be a reason for allowing selection of the pre-standard port number. Rather, it would be a reason for provididing *any non-standard port number* Which is perhaps what the code does. But noone would actually want this. VXLAN on port 54? 80? Noone would want this. And if they filter it, then put it inside an underlay. The standard says nothing about permitting vxlan on any old random stupid port number.
Re: vxlan(4) custom destination UDP port seems not working
I'm not sure about this, but I think that public cloud datacenters filter out (or do something with) udp traffic to standard udp vxlan port. Maybe it's because they have their vlanx infrastructure running on the standard port, don't know. I see no traffic coming from a VPS that tries to send to the standard vxlan port, even if tcpdump of the VPS says that packets are sent. Il giorno mer 15 nov 2023 alle ore 13:59 Theo de Raadt ha scritto: > Otto Moerbeek wrote: > > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > # uname -a > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > > # ifconfig vxlan0 inet 192.168.5.1/30 > > > # ifconfig vxlan0 up > > > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > > vxlan0: flags=8843 mtu 1500 > > > lladdr fe:e1:ba:d9:e4:0b > > > index 18 llprio 3 > > > encap: vnetid 5 parent none txprio 0 rxprio outer > > > groups: vxlan > > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > > Addresses (max cache: 100, timeout: 240): > > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > > > # ping 192.168.5.2 > > > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 > tell > > > 192.168.5.1 [ttl 1] > > > > > > Is this a bug? > > > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. > > Is there any reason to allow people to use non-standard ports? Equipment > that > does this is rare. >
Re: vxlan(4) custom destination UDP port seems not working
Stuart Henderson wrote: > On 2023/11/15 05:59, Theo de Raadt wrote: > > Otto Moerbeek wrote: > > > > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > > > # uname -a > > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > > > # ifconfig vxlan0 inet 192.168.5.1/30 > > > > # ifconfig vxlan0 up > > > > > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > > > vxlan0: flags=8843 mtu 1500 > > > > lladdr fe:e1:ba:d9:e4:0b > > > > index 18 llprio 3 > > > > encap: vnetid 5 parent none txprio 0 rxprio outer > > > > groups: vxlan > > > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > > > Addresses (max cache: 100, timeout: 240): > > > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > > > > > # ping 192.168.5.2 > > > > > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 > > > > tell > > > > 192.168.5.1 [ttl 1] > > > > > > > > Is this a bug? > > > > > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > > > ports. > > > > Is there any reason to allow people to use non-standard ports? Equipment > > that > > does this is rare. > > pre-RFC implementations used 8472 That doesn't answer the question. I checked all the devices i have, none of them can do 8472. So they must be very rare. Why does OpenBSD need to interop with them?
Re: vxlan(4) custom destination UDP port seems not working
On 2023/11/15 05:59, Theo de Raadt wrote: > Otto Moerbeek wrote: > > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > # uname -a > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > > # ifconfig vxlan0 inet 192.168.5.1/30 > > > # ifconfig vxlan0 up > > > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > > vxlan0: flags=8843 mtu 1500 > > > lladdr fe:e1:ba:d9:e4:0b > > > index 18 llprio 3 > > > encap: vnetid 5 parent none txprio 0 rxprio outer > > > groups: vxlan > > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > > Addresses (max cache: 100, timeout: 240): > > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > > > # ping 192.168.5.2 > > > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 tell > > > 192.168.5.1 [ttl 1] > > > > > > Is this a bug? > > > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > > ports. > > Is there any reason to allow people to use non-standard ports? Equipment that > does this is rare. pre-RFC implementations used 8472
Re: vxlan(4) custom destination UDP port seems not working
Otto Moerbeek wrote: > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > # uname -a > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > # ifconfig vxlan0 inet 192.168.5.1/30 > > # ifconfig vxlan0 up > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > vxlan0: flags=8843 mtu 1500 > > lladdr fe:e1:ba:d9:e4:0b > > index 18 llprio 3 > > encap: vnetid 5 parent none txprio 0 rxprio outer > > groups: vxlan > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > Addresses (max cache: 100, timeout: 240): > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > # ping 192.168.5.2 > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 tell > > 192.168.5.1 [ttl 1] > > > > Is this a bug? > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. Is there any reason to allow people to use non-standard ports? Equipment that does this is rare.
Re: vxlan(4) custom destination UDP port seems not working
In the EXAMPLES section of vxlan(4) manpage, I see a multicast dest address 239.1.1.100 with the non standard dest port 8472. Does it mean that for point-to-point tunnels the destination port is static to 4789? If this is the case, I think that the ifconfig command should at least raise an alert, when the dest port is specified with an unicast dest address. In my example with tcpdump, DEST_IP is unicast. Il giorno mer 15 nov 2023 alle ore 13:06 Stuart Henderson < s...@spacehopper.org> ha scritto: > On 2023/11/15 13:03, Otto Moerbeek wrote: > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > # uname -a > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > ... > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > ... > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. > > according to EXAMPLES - > > : Prior to the assignment of UDP port 4789 by IANA, some early VXLAN > : implementations used port 8472. A non-standard port can be specified > : with the tunnel destination address: > ^^^ > : > : # ifconfig vxlan0 tunnel 192.168.1.100 239.1.1.100:8472 > > which is as set, but it contradicts the ioctl doc - > > :if the destination address is unspecified. A > non-standard UDP > :port for VXLAN packets can be specified by the port in the > :source address, otherwise use 0 to request the default. > The > ^^ > :addresses may only be configured while the interface is > down. > > so at least there's a doc bug >
Re: vxlan(4) custom destination UDP port seems not working
On 2023/11/15 13:03, Otto Moerbeek wrote: > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > # uname -a > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 ... > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 ... > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. according to EXAMPLES - : Prior to the assignment of UDP port 4789 by IANA, some early VXLAN : implementations used port 8472. A non-standard port can be specified : with the tunnel destination address: ^^^ : : # ifconfig vxlan0 tunnel 192.168.1.100 239.1.1.100:8472 which is as set, but it contradicts the ioctl doc - :if the destination address is unspecified. A non-standard UDP :port for VXLAN packets can be specified by the port in the :source address, otherwise use 0 to request the default. The ^^ :addresses may only be configured while the interface is down. so at least there's a doc bug
Re: vxlan(4) custom destination UDP port seems not working
On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > # uname -a > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > # ifconfig vxlan0 inet 192.168.5.1/30 > # ifconfig vxlan0 up > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > vxlan0: flags=8843 mtu 1500 > lladdr fe:e1:ba:d9:e4:0b > index 18 llprio 3 > encap: vnetid 5 parent none txprio 0 rxprio outer > groups: vxlan > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > Addresses (max cache: 100, timeout: 240): > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > # ping 192.168.5.2 > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 tell > 192.168.5.1 [ttl 1] > > Is this a bug? It helps to read the vxlan(4) manpage, specifcially the paragraph abouts ports. -Otto
