Traffic going through wrong interface (imminent bug)
-
@cpaixao
It seems that your VLANs are not separated properly.
As you can see in the log, the source IP of the packets coming in on LAN_ACERTO is out of 192.168.25.0/24, which shouldn't be, when the separations works.Possibly your switch is not configured accordingly.
-
@viragomann said in Traffic going through wrong interface (imminent bug):
192.168.25.0/24
Hi @viragomann ,
First of all, thanks for sharing your feedback.
I might be missing something on what you just said, because the printscreen above should show only outgoing traffic. That is, 192.168.25.0/24 ( A - LAN_ACERTO) sending packages to remote host, not the otherwise.
At the same time, with the img I meant to demonstrate that a rule attached to interface B - CF_VLAN is seemly to block packets that should come over (A - LAN_ACERTO, range 192.168.25.1/24).
Besides, such uncommon behavior has started a few weeks ago when we updated to v2.6 and we haven't changed anything in the switch configuration by then.
Would you mind to go a little deeper in your analysis, please? As I said, maybe I'm missing something, and if that's the case, please accept my apologizes.
Regards,
-
@cpaixao
Okay, but above you stated other network ranges for the interfaces:We have an interface (A - "CF_VLAN") that is assigned to 192.168.25.1/24 range, phisical interface em2, default VLAN; Most of our regular traffic uses that interface.
But we also have another interface (B - "LAN_ACERTO") that right now should be out of use: 192.168.70.1/28 range, phisical interface em2, VLAN 70;
Without getting correct data it's pretty hard to help.
To get a more reliable idea which rules are blocking or passing the traffic enable displaying of rule descriptions in Status > System Logs > Settings and ensure that you stated a description in your firewall rules.
-
Hi @viragomann ,
You're absolutely correct about my OP - I got mixed up while writing it. I'm sorry about that. For proper understanding, and since I can't edit there anymore, I'm re-writing the first paragraph:
"Our Netgate PFSense is showing an abnormal behavior since we last updated, version 2.6.0.
We have an interface (A - "LAN_ACERTO") that is assigned to 192.168.25.1/24 range, phisical interface em2, default VLAN; Most of our regular traffic uses that interface.But we also have another interface (B - "CF_VLAN") that right now should be out of use: 192.168.70.1/28 range, phisical interface em2, VLAN 70;"
I double-checked and the rest of that post is correct and accurate.
We do rule description (at least most for most of them). The particular rule in that screenshot is likely to be an aut-generated rule, since I couldn't find that in any interface that we have in Firewall > Rules. I suspect that is from Suricata, tbh.
BTW, just to be sure, I've checked our switch and everything looks fine. I would appreciate any other idea.
Regards,
-
Hi everyone,
The problem persists. Any help is really welcome, so please don't hesitate.
Regards,
-
You can see that the rule associate with that tracker ID is by checking the file /tmp/rules.debug.
However it's almost certainly the antispoof rule for LAN_ACERTO:
antispoof log for $LAN ridentifier 1000002620That is correctly blocking traffic with a source IP in the LAN_ACERTO subnet entering via a different interface. That can only happen if it is somehow being tagged as VLAN 70.
You can try running a packet capture on em2 directly to see exactly what traffic is coming in and how it is tagged.
Steve
-
Hi @stephenw10 , thanks for your insight.
You're right about the the antspoof rule. Thanks to your input, I managed to check that:
When it comes to checking the packets content to see if VLAN 70 is tagged though, apparently it isn't. I am attaching the .cap files and firewall log. I'd would be really glad if you could double-check those, please. This is how the firewall reported when I tried to run a simple sudo apt-get update in one of our servers that is showing the "CF_VLAN" issue. Notice that the firewall shows that it is traffic comes out from CF_VLAN (when it is actually from LAN_ACERTO)
At the same time I captured the traffic running a Diagnostics > Packet Capture. Log attached.
Best regards,
packetcapture cpaixao.7zEdit: BTW, the capture was run on the LAN_ACERTO Interface
-
Hi everyone,
I just want to let you guys know that in the meanwhile and, given the clue that @stephenw10 gave me, I am investigating a cable that possibly is plugged where it shouldn't be. I'm not sure if I've mentioned before, but nowadays we shouldn't be ANY traffic at VLAN 70, that should be completely shut now because we simply don't run any services there anymore.
That a picture from one of our switches, showing that there is a cable plugged on one port that is VLAN 70 assigned
I'll keep you updated.
Regards,
-
@cpaixao I learned a long time ago to check and double check physical connectivity. Never assume you know how things are plugged in because all it takes is someone "helping you" and moving cables.
-
Ok if em2 is assigned directly as LAN_ACERTO then you should see VLAN70 tagged packets on it. But you probably need to enable promiscuous mode and you need to capture more packets.
I would go at least 1000. If that UDP traffic is coming in and being blocked on either interface then it should appear there.Steve
-
Hi folks,
The problem was indeed a cable plugged into wrong switch port. The funny fact is that that mistake was actually done in January, but only now things started to break. Anyways... thanks everyone for assisting me.
Best regards,
