Wireshark - why I can only see outgoing traffic
-
i've search the internet, the only thing that they suggest is to check for firewall/av or anything that can interfere with pcap...
so maybe you have additional packages on pfSense that can interfere with that?
i have a SPAN port configured on my cisco to a raspberry with wireshark (my raspberry have a dedicated usb network card up but without ip) so i don't know where could be your problem, no one is answering,here, which means they don't have an answer so i put my 2 cents -
@johnmen said in Wireshark - why I can only see outgoing traffic:
with a SPAN port configured on the LAN interface of a pfSense firewall box
How exactly do you have this setup? Your spanning the port on your switch that is connected pfsense?
-
@johnmen said in Wireshark - why I can only see outgoing traffic:
Update:
Now I started to suspect the firewall hardware is the culprit for such strange issue. Not sure if I can verify my thinking somehow.
Err your network just wouldn't work if this was the case, you could verify this by doing a packet capture on pfSense itself.
What switch are you using?
https://wiki.wireshark.org/CaptureSetup/Ethernet
-
@NogBadTheBad
This is funny now that you mentioned "packet capture on pfSense itself". I have tried this built-in function for many times over the years of using pfSense. 5 out of 10 capture sessions I would get nothing from the capture. I always wonder if the capture function is not working or not. Having said that when it captures traffic it looks completely normal. Therefore I didn't dig any deeper into this.In terms of switch, I am not using any switch. The firewall hardware comes with 4 ports, one used as WAN, two as LAN ports bridged into a LAN interface, the last one as SPAN port. This hardware uses Intel WG82583 gigabit network chip, which I assume to be pretty robust. My monitoring laptop connects to the SPAN port to try to capture traffic sent from the LAN bridge.
-
I use the capture feature ALL the time.. it works just fine.
You still have not stated how you "spanned" this port? Sounds like you did it on some bridge port actually on pfsense?
-
@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.
