Default deny overriding pass rule on one interface

johnpoz

There is a default block out rule, but that should only come into play where there is no state.

Off the top, guess its possible that if traffic is being seen inbound on different interface than the vlan30 interface. Trying to send out different interface would be stopped by the default deny..

When you ping pfsense 30.1 from 30.100

What interface are you seeing the state create on. Or when you try and hit the gui, which is that 443 SA traffic your seeing..

amorimpermissus

@johnpoz Thanks for looking, I will check the states, shortly when trying to access the web gui on .30.1. I don't think it creates a state for ICMP though does it?

johnpoz

yeah you will see a "state" created for icmp

I started a constant ping to pfsense from my pc, then looking in the state table I see it.

edit: Off the top of my head that only thing that is coming to mind where the default block out deny rule would come into play. Is if there is no state for answer, which I would think could only happen when your trying to answer via a different interface than the traffic came in on.

So you have IP set on the native interface your re1, and only have vlans 10 for your lan and 30 for your other vlan sitting on this physical interface.

If traffic came into re1 without a tag, and source IP was 30.x then pfsense would try and answer via its vlan30 interface. But would be denied because no state on that interface - that is a GUESS to possible scenario that could maybe cause what your seeing..

amorimpermissus

@johnpoz Gotcha. Regardless, I started a pcap on the firewall, listening on the LAN30 interface for 192.168.30.100, along with opening up the states page in another tab and filtering on all interfaces to 192.168.30.100. Then I opened https://192.168.30.1 on my laptop. I saw it creating a TCP connection on 443 in Windows perfmon. On the pcap, both the pings and the https traffic showed up, but in the states page, it stayed at "No states were found that match the current filter," no matter how many times I refreshed.

If you don't see anything misconfigured in the pastebin of my firewall rules, I'm leaning toward thinking some system files (or disk sectors) are corrupted. It's just the only logical explanation at this point. Plus, I used UFS when I built this box, so it doesn't have the same protection from bitrot that ZFS does, even when you aren't using ECC memory.

I'm going to see if I can figure out what files/folders the E2Guardian package lands in, and copy those off. Then I'll wipe and reinstall. I hope it's not something inherently wrong with my hardware, but I'll update here once I reconfigure everything. That way you all will know whether it worked or not.

Thanks again, everyone, for your help!

johnpoz

Well a state can not be created unless allowed.

I didn't go through all your rules.. But if your saying your seeing traffic hit the firewall

But nothing logged on the inbound?

Your sure the traffic was tagged with vlan30? You can do a tcpdump on pfsense with the -e to view vlan info..

example

I did a tcpdump -i igb2 -e

Where igb2 is parent interface for multiple vlans - you can see here traffic from vlan4

11:48:12.539018 00:08:a2:0c:e6:20 (oui Unknown) > 68:57:2d:98:36:83 (oui Unknown), ethertype 802.1Q (0x8100), length 58: vlan 4, p 0, ethertype IPv4, ec2-54-187-112-38.us-west-2.compute.amazonaws.com.https > 192.168.4.202.53966: Flags [F.], seq 717, ack 851, win 3752, length 0
11:48:12.541636 68:57:2d:98:36:83 (oui Unknown) > 00:08:a2:0c:e6:20 (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 4, p 0, ethertype IPv4, 192.168.4.202.53966 > ec2-54-187-112-38.us-west-2.compute.amazonaws.com.https: Flags [.], ack 718, win 3663, length 0

amorimpermissus

@johnpoz Yeah, the log data I posted the screenshots of are, consistently, the only thing appearing in the firewall logs, period, for traffic on that interface/subnet. Even when I do a continual ping from .30.100 to .30.1, the ICMP traffic never shows up in the firewall logs at all, but it's definitely showing up in tcpdumps:

https://pastebin.com/rR36L1QJ

And a tcpdump on re1 shows up as tagged for that MAC:

[2.4.5-RELEASE]/:  tcpdump -i re1 -e | grep 54:ee:75:3b:ab:f9
listening on re1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:58:40.912971 54:ee:75:3b:ab:f9 (oui Unknown) > 40:62:31:03:e5:f9 (oui Unknown), ethertype 802.1Q (0x8100), length 78: vlan 30, p 0, ethertype IPv4, SUPPORT3.demasci.intra > 192.168.30.1: ICMP echo request, id 1, seq 192, length 40
12:58:45.914341 54:ee:75:3b:ab:f9 (oui Unknown) > 40:62:31:03:e5:f9 (oui Unknown), ethertype 802.1Q (0x8100), length 78: vlan 30, p 0, ethertype IPv4, SUPPORT3.demasci.intra > 192.168.30.1: ICMP echo request, id 1, seq 193, length 40

This is also confirmed by the fact that my laptop always receives an IP address from the DHCP server listening on LAN30. It's so. Freaking. Weird.

johnpoz

@amorimpermissus

What rules do you have on port forwards, those are evaluated before.. You don't see them with your -sr

amorimpermissus

@johnpoz Eh, don't remember exactly-- blew the whole install away and reinstalled from scratch. After setup, same problem as before.

Even tried a different vlan again-- 50 instead of 30. Made no difference.

Moved the port configuration to a different switchport on my managed switch... it worked on VLAN 50.

Deleted the re1.50, recreated it as re1.30. Created the allow all firewall rule.

Traffic now working without any issues. I think I may have just put myself through hell for nothing, reinstalling and everything when it was something strange on my switch. But now my firewall is running ZFS instead of UFS, so that's good at least.

THE MORAL OF THE STORY IS THAT, EVEN IF:
-There are no errors in ethtool
-There is every indication that the packets are uncorrupted based on packet captures
-You have switched out all of your cables

IT COULD STILL BE SOMETHING DUMB ON YOUR SWITCH.

For anyone else who might be experiencing this, I am using a Comtrend GS-7408. Maybe all of this information contained herein could help someone else in the future >_<

johnpoz

What doesn't make any sense with the switch being the problem is that you were seeing stuff tagged with vlan 30, but it was being blocked outbound..

Some piece of the puzzle is missing to what was actually going on.. But at least you got it working. And zfs is plus coming out of it. I am waiting for 2.5 to drop and then will do a clean install myself to go to zfs on my sg4860.

Griffo

In one of your earlier posts, the dump shows some "Bad Checksum" packets at the beginning. That indicates to me a hardware or switchport config issue, like the vlan tagging was not right leading to framing issues. I tried to post that last night but was still in draft on my phone this morning :-( Glad you fixed the issue.

amorimpermissus

@griffo Doh! Oh well, better late than never lol