I will start off by saying that you should consider an upgrade to 11.5.3HF1. The 11.5 release follows the new model described here:
(11.5 is the Long-Term Stability Release for 11.x).
I don't have any particular reason to believe that updating to 11.5.3HF1 will change the behavior; I simply wanted to note this current best-practice.
Having said that, the basic unit for networking configuration on a BIG-IP is a VLAN object. Interfaces, trunks and tunnels must be associated with a VLAN, and listeners are also associated with VLANs. Any traffic arriving (or leaving) a BIG-IP network interface must be matched to a VLAN for it to be accepted. If the traffic has no VLAN header, it will be associated to the "untagged" VLAN for the interface, if one is defined (if one is not defined, the frame is dropped). This is very similar to Cisco's notion of a "native" VLAN definition (though Cisco accepts frames tagged for the native VLAN and BIG-IP does not).
When untagged frames are copied to the forwarding plane, the appropriate VLAN tag is inserted. As a consequence, all traffic you see in your tcpdump (assuming you dumped on 0.0) will have an associated VLAN id.
I'm afraid I don't completely follow the rest of the information you provided. Perhaps you can restate what you are seeing? In the meantime: generally speaking, a "connection" (tcp connection or udp flow) through a BIG-IP is matched by VLAN, src-ip, src-port, dst-ip and dst-port. Any traffic received on a listener that is not the start of a new connection (a SYN-only segment for tcp) will be rejected by the BIG-IP unless it matches an existing connection table entry. That means, among other things, that tcp segments for an existing flow must all arrive on the same VLAN, and if the BIG-IP initiated the connection (as happens on the server-side of the full proxy), all traffic for that flow must arrive on whatever VLAN the BIG-IP used when initiating the flow. This solution article contains more information: