The basics are obvious, but there are technical points of networking implication which I don't understand.
Some of these are general to networking, others general to all routing/firewall softwares or to a specific implementation. If specific implementation is relevant then I'm thinking of general purpose rather than specialised networking devices - I use OpenBSD/FreeBSD's pf here so that would be most helpful to illustrate any firewall-specific handling. (i.e., not asking about specialised networking firmware such as Cisco/Juniper). I imagine that pf's
bridge directives would be good exemplars, but at a pinch 'tcpdump` might also be relevant.
I'm assuming the broadest case, where all packets on a port are mirrored to another port (OSI 2 and by implication also OSI 3, without any selective filters).
- Does a mirror port in effect imply an implicit "block all inbound" rule, so that it can be listened to externally but no other interaction or change to the original traffic flow can occur, if packets are sent on the mirror port?
- If it does create the equivalent of a "block all inbound" rule, is a no-state rule parameter necessary and/or sufficient to ensure packets will mirror correctly even though replies (SYN-ACK etc) will be blocked on the mirror port? If not, what then?
- The act of mirroring probably needs consideration of either promiscuous mode (using
tcpdump), or a span port,
dup-todirective or bridge interface (using
pf), to mirror all (not just directed) traffic to another port. Are these 4 approaches equivalent or equally suited for a mirrored port?
- The mirror needs to treat as data, copies of packets such as ARP, RSTP and BGP on the source interface, which are normally automatically treated as actionable input (unless blocked inbound), when an appropriate service is configured to recognise them. Does this break the layering/packet processing model as it seemingly needs the fîrewall implementation to actively breach the usual data/instruction norm and forward such packets as data on the "mirror" stream while also actioning them as instructions on the "real" stream?
- Forwarding packets usually involves automatic generation of additional packets such as ARP who-has, possible routing protocols, and the MAC field automatically being generated/updated on the packet, all of which are clearly undesirable for mirrored port traffic. Clearly this is implementation-specific. Is this an issue when creating a mirrored port on a general OS, since these and other automated routing methods on an interface have to be suppressed while still forwarding a packet? (Put another way, the copy must always exit the mirror port without any header modification, and without additional internally-originated packets being auto-added on the stream, but technically do general purpose fw sw allow this on a port by port basis?)
(Hoping this is appropriate for this site, if not can it be moved to the most appropriate site for a technical network-engineering based answer?)