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 <luc...@gmail.com>
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 <luc...@gmail.com> 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.
>>
>
