Observing unexpected VLAN traffic on F5OS TMOS Tenant

Question

I noticed running on TMOS (17.1.3) based tenant on an F5 OS (1.7) appliance (R4800) that I was receiving traffic from unattached VLAN.

It was first observed while investigating something else and happened to run 'pcacp -ni 0.0' (within the TMOS Tenant shell).

Confirmed the unexpected frames still held the correct VLAN TAG # (one that was not attached/assigned to this Tenant).

Curious if anyone else has seen this, if this expected (that L2 traffic would be seen that does not belong to a Tenant)? Running on R4000 series appliance. Both expected VLANs and unexpected vlans are sharing the same LACP Bond (2x 10g) to the network in the F5 OS layer. I would expect this sounds like a bug, otherwise why even have the 'VLAN' assignment section in Tenant configuration.

I am curious though if this may just be a side effect of the NIC driver / 'pcacp' running in a VM-on-Container environment that is F5OS w/ TMOS.

Curious if anyone else has run into this.

The way I read this documentation would indicate this probably shouldn't be happening:

https://clouddocs.f5.com/training/community/rseries-training/html/rseries_networking.html

zamroni777 · Answer

https://clouddocs.f5.com/training/community/rseries-training/html/rseries_performance_and_sizing.html

above doc mentions that r4000 series shares network adapter using sr-iov.

probably the host f5os doesnt disable promiscuous mode which causes traffic of other vlans is captured by that particular tenant.

mj_1024 · Answer

My thoughts exactly, which is the initial point in this post.I will probably open a ticket to report a potential bug just to be safe, but that requires I get the serial number, which I do not have handy at the moment and probably wait on the phone (as many times serials are not attached to my account). If anyone knows a faster/easier way to report something, bypassing the normal support case, I would be glad to know.In this case, VLAN assignments and LACP bond are all validated, did at least some homework before reaching out to anyone.&nbsp;I may do more testing to confirm no unexpected traffic from other links, thankfully major tenants are running on different bonds (DMZ vs Internal), otherwise we would have more security concern. Still, I think zamroni777 is probably correct, that doesn't mean there isn't still some security concern still but may at least contain the issue to be treated more as a limitation on traffic separation for TMOS Tenants on this platform.

mj_1024 · Answer

I think you are correct.This link also goes into some of the extra shared information in a r2000 and r4000 platform, and how more interface level visibility is seen due to the platform design.https://clouddocs.f5.com/training/community/rseries-training/html/rseries_inside_the_tenant.htmlWhat I don't see anywhere in the document is a warning/note for additional traffic isolation considerations on these platforms.My next step is to actually test if traffic can be generated / processed incorrectly on a Tenant.It's one thing to 'see' someone else's VLAN traffic, it is much worse if a tenant can be re-configured to communicate on a VLAN it should not be part of.

zamroni777 · Answer

i think the f5 community manager e.g.&nbsp;JRahm can help raising the problem to f5 rnd.in the mean time, you can try setting the sr iov vf of the tenant to untrusted, e.g.ip link set ens785f1 vf 0 trust offi saw the example in this nvidia sr iov doc:https://docs.nvidia.com/networking/display/mlnxenv584150lts/single+root+io+virtualization+(sr-iov)#src-2477565063_safe-id-U2luZ2xlUm9vdElPVmlydHVhbGl6YXRpb24oU1JJT1YpLVByaXZpbGVnZWRWRnNDb25maWd1cmF0aW9u

Forum Discussion

Observing unexpected VLAN traffic on F5OS TMOS Tenant

Recent Discussions

CRYPTO SCAM RECOVERY SERVICE – A LEGIT COMPANY FOR HIRE- DIGITAL TECH GUARD RECOVERY

Bypass "Bad unescape" in Body POST (ASM, POST, JSON)

URL redirect

Bypass the character for Evasion technique Detected violation

URL redirection

Related Content

ebPF for Observability

Traffic Policy to Split Content Between IIS Server and Cloud Provider - unexpected behavior

fellow traffic

iRule - unexpected behavior

Managing Kubernetes Traffic With F5 NGINX: A Practical Guide