Looking at the code it seems that handling VRFs in transport layer is broken.
In UDP and TCP packet reception VRF of the input interface is ignored when a packet it matched with a PCB. Thus packets from all VRFs are processed by the same PCB if addresses & ports match.
In almost all cases packets output by TCP go to VRF 0. With UDP it depends on the used API whether an output packet is sent to VRF 0 or the VRF of the input interface associated with the packet provided to the API function.
Also VxLAN input processing ignores VRF.
Perhaps the intended behavior is that UDP, TCP, and VxLANs would be available in VRF 0 only and such packets received in other VRFs would be dropped. OTOH, there is a commit (b2796c6 VRF support for sockets added) that hints toward VRF support in transport layer but that commit seems to be quite incomplete.
Looking at the code it seems that handling VRFs in transport layer is broken.
In UDP and TCP packet reception VRF of the input interface is ignored when a packet it matched with a PCB. Thus packets from all VRFs are processed by the same PCB if addresses & ports match.
In almost all cases packets output by TCP go to VRF 0. With UDP it depends on the used API whether an output packet is sent to VRF 0 or the VRF of the input interface associated with the packet provided to the API function.
Also VxLAN input processing ignores VRF.
Perhaps the intended behavior is that UDP, TCP, and VxLANs would be available in VRF 0 only and such packets received in other VRFs would be dropped. OTOH, there is a commit (b2796c6 VRF support for sockets added) that hints toward VRF support in transport layer but that commit seems to be quite incomplete.