can still hit port 25 with no rules in place
-
@johno1233 screenshots are beyond me right now, i have created a test situation . dns server using 53 tcp/udp on LAN and the same on OPT1. the only rules on all three interfaces including WAN are the local and bogon blocks on WAN only and the anti lock out rule for the web config on LAN. from the web config i can reach port 53 on both servers. LAN to OPT1 test port 53 connection successful. I feel this should not happen unless i allow traffic on port 53 LAN to OPT1
-
@johno1233 When you say from web config, you mean the pf configuration web page?
If you need to limit the firewalls access to connected networks, you need floating rules.
But why you need this? -
@netblues thanks for the answer, havent checked out floating rules so i will now. yeah its really very simple although i got it wrong i guess, i expected that traffic between interfaces should be blocked but its not. what i want is that my mail server on my internal network is only reachable from web facing mail server and no other server, when i say web config YES i mean web configurator of pfsense. basically i should be able to open port 25 from ip adress to ip adress , this would stop any other server contacting my mail server on port 25. however port 25 is available from anywhere with no rules because a mail server is present. same with port 53 in my test network, see my previous posts. it would seem that as soon as a server makes a service available then the port test will find it even when rules are not in place. see previous posts. i dont think that should happen as all traffic should be blocked until i make a rule to the effect
-
@johno1233 in short if i test port 25 from LAN to OPT1 with no rule in place then web config makes a successful connection which should not be possible
-
@johno1233 The default setting with pFsense is to block all incoming on the WAN port and allow all incoming on the LAN port. (all other firewalls that I have used do the same.)
In your case, you just need a single rule on the LAN which blocks any to any. -
@decibel what you say is correct but if you add another interface for example OPT1 then there should be no network communication between LAN and OPT1 until rules are in place. Im not trying to block traffic between computers on the same interface so my opinion is that blocks are not required. Try and see OPT1 as a DMZ . theres no way these two networks should be able to communicate without rules in place but the diagnostic functions on pfsense web configurator say this is certainly not the case and your an open target ?
-
@johno1233 There IS a rule in place - all incoming traffic on the LAN is allowed through the firewall to where-ever it wants to go.
The reason for this is two-fold -
1] it is your traffic on the LAN so it "should" be trustworthy
2] if all LAN originating traffic was blocked, you would have to create a swarm of rules to allow outgoing traffic - browsers, FTP, email, SSH, pings, etc.It is a lot easier to allow ALL and then block the odd one.
In your case, the answer is SIMPLE - add ONE rule to block any to any and you are now at your desired situation.
-
@johno1233 said in can still hit port 25 with no rules in place:
@decibel ..and your an open target ?..
Open target from the LAN ??
Who exactly on the LAN is trying to target the DMZ?
Go around to their desk and whack them around the ears !!
-
@decibel i understand what you say but i think your overlooking the fact that the OPT1 interface and the LAN interface should not be able to communicate. it actually says in the documentation that when you add an interface all rules are blocked even to the LAN interface, you can see this from the log in panel in the rules section for each interface . there is no upstream , downstream NOTHING until you create a rule allowing it. HOWEVER a simple test from the diagnostics section of the web panel shows that if a service is available on one of these interfaces then it can be contacted from the other interface without appropriate rules in place. NOW that is not what is supposed to happen RIGHT ??
-
@johno1233 You are not supposed to use the diagnostic page of pf to test interface rules.
It does not belong to any interface.Do your tests from something physicaly connected to opt1
and try to reach something @lan
Lan is the only interface that has a built in allow to all rule, and its there to help the noobs. (and is something common in simple installations too)
In all other interfaces an implicit INCOMING deny is in place -
@netblues okay i will try from the servers connected to the interfaces, i didnt go that far because although you say you shouldnt use the web interface to test interfaces the its kinda misleading to have it there with those options available , when that failed i binned it, but will try again
-
@johno1233 It is VERY important to understand that packets are filtered when they ENTER the firewall.
This is the case with most if not all firewalls.
What you are seeing is what happens from inside the firewall
The only way to manipulate this is with floating rules.
And I would strongly recommend to stay clear from floating rules at this stage, as the concept is much more difficult to understand and even experienced people have a hard times doing such chores without introducing side effects. -
@netblues so yeah, just done some quick tests and indeed the servers cannot communicate without rules, ip adress to ip adress did not work but allow all works fine which will do i guess for now. so the diagnostic tool offers options to test from all sorts not just in the LAN , im going to say that doesnt function properly in addition to the rules having to be any is a poor show regardless of a persons experience
-
@johno1233 The point of that Test Port tool in Diagnostics, as I understand it, is NOT to verify if your firewall rules are working. It's more to test and see if ports are correctly opened on destination servers. Because as @netblues pointed out, the rules (except floating) would not be applied to packets originating from the firewall itself.
So, in the end, it sounds like once you tested properly, everything was actually working as you expected. This was a misunderstanding on your part of how the rules work and how to properly test. I don't see why you're calling this a "poor show". Frankly, this whole thread is in bad taste- people here are trying to help you (for free) with a firewall you downloaded (also for free) and you don't seem the slightest bit appreciative.
-
@johno1233 said in can still hit port 25 with no rules in place:
im going to say that doesnt function properly in addition to the rules having to be any is a poor show regardless of a persons experience
Sure. And an F1 McLaren doesn't go well on mud.
-
@luckman212 @luckman212 both you answers are not contributing at all to the issue in the post, putting me down seems to be your main concern, yes my test worked with limitations , and the the web config gives you various options to test from all connected interfaces which does not function as expected. no misunderstanding on my part, maybe you should try it yourself before you knock me
-
@netblues yep expecting too much i guess , thanks for your help
