LAN ip blocked but seems to be passing traffic

h1pp13p373

@JeGr I worked with an admin in another thread and it lets him post the exact same text, but not me. Time for gist/etherpad/something else. It'll be much easier in the long run.

h1pp13p373

Just found hastebin... pretty slick. Even a cli client so you can pipe stuff to it.
https://hastebin.com/about.md

So, back to my original issue, here's my dump and rules:
https://hastebin.com/elamojuvaw.coffeescript

I'd found an old pfsense thread that suggested I place a specific allow for that alias before the block but that didn't work either. I still could see traffic being passed.

Derelict

Please paste /tmp/rules.debug

Establish a connection that should be blocked. While connected or immediately thereafter get the output of this:

pfctl -vvss | grep -A 3 192.168.42.89

h1pp13p373

@Derelict Got it:
https://hastebin.com/pocurolagi.coffeescript

Derelict

Great. Now:

pfctl -vvsr | grep -A3 '^@24('

h1pp13p373

@Derelict Newest at the top:

https://hastebin.com/umedifopej.coffeescript

Derelict

Great. Do you have a captive portal on that interface?

What are the various IP address and MAC address pass throughs there?

h1pp13p373

@Derelict Good thinking! I do have a captive portal active, but I only have a few ip's allowed and 192.168.42.89 is not on the allowed list. I don't have any allowed MAC addresses set.
https://hastebin.com/ifabayekin.coffeescript

Derelict

Well that's probably why you're seeing what you're seeing. I am not sure why yet but those sloppy rules are likely the culprit. Note that there is no state shown that passes traffic into LAN from 192.168.42.89:39163 -> 99.193.64.55:80. Only the reply traffic passed by sloppy rule 24.

Turn off the captive portal. Is the traffic blocked?

Move the specific block rule to the top of the rule set. Is the traffic blocked?

Most people would not stack a bunch of stuff on an interface with a portal on it. They'd create two different security zones (interfaces) and put the captive portal on one and the hosts that should be able to pass through on the other.

What is the output of ipfw show

h1pp13p373

@Derelict said in LAN ip blocked but seems to be passing traffic:

ipfw show

https://hastebin.com/isadazabew.coffeescript

Looks like that was the culprit! After turning the portal off, I didn't see any return traffic from the remote ip. I guess the portal returning the login page looked like a return from the remote ip in the dump...? Strange though. I sure appreciate your help, @Derelict !!

I'm also going to look into security zones like you suggested. Is the purpose of using the zones to have an abstract layer of trusted and untrusted hosts sort of like aliases for fw rules, or is it a performance thing?
I was a linux guy for years and know just enough networking to be dangerous. :)

Derelict

The purpose is to segment secure portions of your network from each other, each with the capabilities necessary for that segment (like captive portal).

Yes, the captive portal page being returned would look like that if you were capturing on LAN. I (and everyone else probably) assumed you were looking at a web browser when you were testing and seeing the portal page instead of the outside site would have seemed like an obvious clue to me.

h1pp13p373

Thanks again, and that makes sense about segmenting.

This all started when I saw traffic to that LAN ip on ntopng (installed on the pfsense box) and did a pcap download. That's where I saw the traffic from the remote ip to the LAN address and I got concerned. The 302 should have also gave me a clue about the portal.
The portal was only set up to rick roll guests and I guess I deserve it for that. lol
Have a great day!

h1pp13p373

@Derelict I'm having trouble finding documentation on using interfaces to segment. Is it like creating virtual interfaces and assigning ip lists to one or both? Would you mind linking me an article?

Derelict

This discusses network segmentation:

https://www.youtube.com/watch?v=QFk5jX-oeSo

h1pp13p373

@Derelict Thanks!