LAN ip blocked but seems to be passing traffic
-
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 -
@Derelict Got it:
https://hastebin.com/pocurolagi.coffeescript -
Great. Now:
pfctl -vvsr | grep -A3 '^@24(' -
@Derelict Newest at the top:
https://hastebin.com/umedifopej.coffeescript
-
Great. Do you have a captive portal on that interface?
What are the various IP address and MAC address pass throughs there?
-
@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 -
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 -
@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. :) -
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.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
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! -
@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?
-
This discusses network segmentation:
https://www.youtube.com/watch?v=QFk5jX-oeSo
-
@Derelict Thanks!
