Wireshark - why I can only see outgoing traffic
-
@johnpoz
My setting is as follows, note that there is no switch or hub involved here.My pfSense firewall hardware box has 4 ports, port 1 configured as WAN, port 2 and 3 configured as members of a bridge called LAN, my internal network connects to these two ports. Port 4 configured as SPAN port member of the LAN bridge. This is the setting you can do when going into the bridge configuration on pfSense webGUI. In other words, my SPAN port is part of the pfSense firewall hardware.
My monitoring laptop connects to the SPAN port directly. My internal hosts connect to either port 2 or 3. my WAN port connects to a fibre connection's ONT (On-premises Network Terminal).
-
@kiokoman
Thanks for chiming in. I run pfSense vanilla, no additional packages installed at all. -
This may be an issue with using the span port on the bridge, which I expect is rarely done. If not using an actual switch, I just capture direct from the firewall, and haven't ever (except for version 1.2.3) had any trouble with it. Here's a similar problem on stock FreeBSD (well, five years ago stock FreeBSD)
https://forums.freebsd.org/threads/span-port-only-sees-incoming-side-of-traffic.47591/ -
this also remind me of another 3d of last week where we was unable to make dhcpv6 working on a l2 bridge, we see requests but not the answer
-
@dotdash
I am not aware of anyway other than inside a bridge where you can setup a SPAN port on pfSense. The port configuration itself on pfSense has very limited options, certainly does not have SPAN option to be configured. -
My point was that what you are doing is probably an edge case, most use a managed switch, or capture as needed using the Diagnostics, packet Capture function. There could well be an issue with the way pfSense or FreeBSD does the span port, but you may not find another user here who has tried to do what you are doing. In the linked post, he put the ip on the physical port, not the bridge, but I haven't tried to see if that configuration is possible via the gui.
-
@dotdash
You may be right in that not many people use port on pfSense firewall itself to do the network capture. Although I think the "opt" port that comes with many firewall including Netgate SG-1100 is meant for something like this.In regards to the post you linked it looks similar to my issue but there is one important difference: the TCPdump on my pfSense box can in fact capture traffic from both directions. In other words, issue only exists with physical SPAN port in my case.
Update:
Err, I was wrong. The post you linked, the guy only did TCPdump on the SPAN port, whereas I did the TCPdump on the bridge. We tapped on the different interfaces. I shall try tapping on to the SPAN port and see how it goes.Update again:
Alright, I have just done the TCPdump experiment. What I found is that if I dump traffic from the network port that is configured as the SPAN port inside the LAN bridge, I see nothing! Literally no traffic was captured. Dumping from other network ports such as "bridge0" or "em1" (one of the nics on my firewall box), I could capture traffic without any issue.This is different from capturing traffic by physically connecting a Cat5 cable to the SPAN port to my monitoring laptop's NIC. Physical capture works with one direction traffic captured only, tcpdump on the same network port remotely however captured nothing.
-
@johnmen said in Wireshark - why I can only see outgoing traffic:
Although I think the "opt" port that comes with many firewall including Netgate SG-1100 is meant for something like this.
No... Not sure where you would get that idea ;)
-
If you are doing a packet capture on port that is a bridge have you tweaked the kernel settings as per:-
https://docs.netgate.com/pfsense/en/latest/interfaces/interface-bridges.html
net.link.bridge.pfil_member
net.link.bridge.pfil_bridge -
@NogBadTheBad
Thanks for pointing this out. I have tried setting the net.link.bridge.pfil_bridge to 1 and tested the network capture, sadly still the same result. Therefore this kernel setting doesn't seem to be related. Remember I mentioned remote capturing works properly, and that was done against "bridge0" bridge interface instead of member interfaces whilst the net.link.bridge.pfil_bridge was the default value 0.Regards.
