can still hit port 25 with no rules in place
-
i have pfsense installed on hyper v with 4 interfaces -WAN, LAN, OPT1 and OPT2. on OPT2 is an exchange server. there are no firewall rules set so should be no network traffic. why can i contact port 25 on exchange server from the LAN when no rules are set. i have all the bases covered. latest version , restarted etc etc ???? this surely cant be an acceptable function of the software >??
-
@johno1233 Because you have to put firewall rules on the interface that traffic ENTERS on. In your case, LAN. And by default, all traffic from LAN is accepted. If you want to block port 25, either delete the "allow all" rule on LAN or put an explicit block rule above it.
-
@luckman212 i blocked all traffic i thought, the only rule is any to lan net on 443 for the web configurator. i disabled the allow all protocols to any 1pv4 and 6 ? communication must not be allowed between LAN and OPT1 on any port without a rule in my opinion, that is the whole point. thanks for answering but i think ill drop this product. thing is you see, from the web config it will contact the port with no rule in place but when i try to connect a server on that interface then NOTHING even with rules set. now i know everyone will say configuration problem but at the end of the day with no rules my mail server should never be available right.
-
@johno1233 just an update, i have set up a test lab with two dns servers , one on LAN and one on OPT1, no rules set, is it then correct functionality that port 53 can be reached from lan to OPT1 using the web config ?
-
@johno1233 port 53 on opt1 blocked, web config test port LAN to OPT1 on port 53 connection successful , is there even an explanation lol
-
@johno1233 Since this is your very first post here on the forum how about providing a bit more detail, screenshots, useful information so we can try to help you before saying "i think ill drop this product, Lolz".
Pretty sure you can make pfSense do whatever it is you need it to do. Yes you do need to understand how the firewall rules work to configure them correctly. Don't forget to reset states as well when making changes. Sometimes there are existing states that allow traffic to flow even though you have added rules to block it.
-
@luckman212 I do apologize Sir, however all traffic between interfaces should be blocked until rules are in place, this would appear not to be the case if you have a server running for e.g. port 53 in the OPT1 interface then that traffic is allowed regardless of rules if you use the web config, further i think i explained the issue clearly enough, you are obviously learned in this product and its quite simple. my mail server can be reached from the web config on port 25 when there are no rules set to allow this. this is obviously a security risk which would make me reluctant to use this product which led to my 'DROP' comment. screenshots to follow
-
@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
