Is it possible for one to "slip through"?
-
Okay. There it is. Been quite busy at work.
-
@stephenw10 Now that I look at it, something seems off. I'm not quite sure.
-
@obxjeepguy yeah that is not a port forward, that is a allow rule outbound to some 192.168 address, why would you think you need to hide a rfc1918 address.
-
Yes, very unlikely that rule would ever match anything. You can see no states have been opened by it. I would just disable that.
You can see the port forward in Firewall > NAT > Port Forwards.
The associated firewall rule will be on the WAN tab.
Steve
-
@johnpoz said in Is it possible for one to "slip through"?:
@obxjeepguy yeah that is not a port forward, that is a allow rule outbound to some 192.168 address, why would you think you need to hide a rfc1918 address.
You are absolutely correct. And I have disabled it. That is left over from when I fist set everything up, and knew ZERO about pfSense. As for hiding an rfc1918 address, that would be for no apparent reason. Just like the folks who cover their license plates in photos of their cars.
-
@obxjeepguy said in Is it possible for one to "slip through"?:
Just like the folks who cover their license plates in photos of their cars.
No not the same - lic number is unique and could be looked up ;)
Rfc1918 space used by everyone.. It would be like telling you I live on the planet earth ;) could you find me with that info hehehe
My pc is 192.168.9.100, my gateway is 192.168.9.253 - does that give you any info at all that could be used to track me to where I am exactly, or even what ISP I use, etc.
edit: but knowing what address space is being used can be very helpful in troubleshooting so that easier to understand difference in vlans and why some rfc1918 IP can not talk to another one, etc. When they are obfuscated it can be more difficult understanding quickly what is going on.. While hiding your public IP space is very understandable - when you hide rfc1918 it can get confusing is all. Just something to consider in future posts is all.
-
@johnpoz said in Is it possible for one to "slip through"?:
@obxjeepguy said in Is it possible for one to "slip through"?:
Just like the folks who cover their license plates in photos of their cars.
No not the same - lic number is unique and could be looked up ;)
Rfc1918 space used by everyone.. It would be like telling you I live on the planet earth ;) could you find me with that info hehehe
My pc is 192.168.9.100, my gateway is 192.168.9.253 - does that give you any info at all that could be used to track me to where I am exactly, or even what ISP I use, etc.
All very true. I was always told to not even let any of those numbers out. Especially port numbers. I know the only way is if I knew your public IP address. So that being said, I will get on with port forwarding, and @stephenw10 will see there is a linked rule.
-
@obxjeepguy I not sure who told you to hide those or ports.. But they don't work in networking that is for sure.
Me knowing your forwarding to 80 or 443 provides me nothing if I don't know what your public wan IP is. Like saying hay your house number is 123.. What city, what street ;) if I do not know these things 123 is meaningless and provides nothing to track you. But it can be very helpful in spotting problems. Hey that should be 443, not 444 etc.
For example I forward externally port 23040 to my plex on 32400. Without even a clue to what my public IP is - how does that give away anything?
-
@johnpoz I seem to be learning quite a bit today.
-
Anyway can we assume you are not translating the ports between the WAN and targets?
The floating block rule you had would have blocked that traffic you saw unless it was somehow not applied at that time or a state already existed. Since you're only forwarding TCP traffic though a state remaining open would be far less likely.
Steve
-
@stephenw10 said in Is it possible for one to "slip through"?:
Anyway can we assume you are not translating the ports between the WAN and targets?
The floating block rule you had would have blocked that traffic you saw unless it was somehow not applied at that time or a state already existed. Since you're only forwarding TCP traffic though a state remaining open would be far less likely.
Steve
No port translating.
That floating block rule has been in place since I first set this up. The thing I don't understand is a "state already existed". -
@johnpoz And I just looked at the state table. I guess too much time has passed and it has dropped off the list.
-
Another possibility is that the alias somehow became invalid when pfBlocker updated and it wasn't applied. I would put a custom list in a separate entry because that will always be valid and doesn't require updating.
-
@stephenw10 Never even thought of that possibility. Very interesting. I wouldn't even begin to know how to put that list in a separate entry, so I will leave well enough alone. This setup has worked insanely well for me in a lot of ways. It just kind of puzzled me when that one IP got through.
And thanks a million for all of the replies. I feel I have learned a ton, even about things not on this subject.
-
-
@obxjeepguy just create a IP/network alias under firewall aliases
Then you can use that in any rule you want.. There is nothing wrong with have 2 rules that are suppose to block the same thing. You know for sure your manually created alias will have what you put in it.. There is always the off chance, slim as it might be that when you automate stuff to update that something goes wrong and maybe doesn't update correctly. It should work 9999 out of 10k - but you never know..
-
@nimrod said in Is it possible for one to "slip through"?:
Wouldnt this option prevented this issue ?
That's a good point. Yes I would expect it to if it was set. Assuming this was caused by an open state.
-
@nimrod said in Is it possible for one to "slip through"?:
Wouldnt this option prevented this issue ?
Just to add my 2 cents worth, I just ran into a situation where the states were not being cleared because an IP appeared to remain after the force command. I ended up manually clearing the states to fix the issue.
I would say, if all else fails, manually clear the states as was suggested earlier, I think.