Sanity Check
-
A Demilitarized zone by default allows every connection from wan port to a specific static ip address .
That is NOT a Demilitarized zone/DMZ. That is what crap SOHO routers call a DMZ, but it is not, by any definition, a real DMZ. It's a horrible, insecure practice that is no more than a 1:1 NAT from a single WAN IP address to an IP address on LAN. If the host is compromised, your whole LAN can be compromised.
An actual DMZ is an isolated network that is more secure than the Internet at-large and less secure than the LAN. The DMZ should be blocked from the LAN, and the LAN should also be blocked from the DMZ. Allow only the specific services on WAN you need to reach in the DMZ, not everything, and only allow from LAN to DMZ the services you absolutely need, and perhaps some additional management ports.
Traffic is filtered as it enters the firewall so your DMZ rules should have a source of DMZ Net, not WAN. To allow traffic into the DMZ from WAN, place the pass rules on WAN. To allow traffic from the DMZ out to the Internet, pass on the DMZ tab from a source of DMZ Net to any/*.
-
your original dmz were close, you were preventing access to your lan network.. But you would still allow access to pfsense on any IP address, etc. You would prob want to lock that down as well
"A Demilitarized zone by default allows every connection from wan port to a specific static ip address ."
Where did you get that nonsense?? Here this is a better definition of what a dmz is https://en.wikipedia.org/wiki/DMZ_%28computing%29
As jimp pointed yes soho routers often all the host you expose to the internet the dmz host.. Which in just a plain out BAD IDEA no matter how you look at it. They put that feature in so when all else fails you can do that, or when you want/need more than their 1 or 2 port forward gui allows for you can just forward every single port to that IP.
-
You only explained the concept of DMZ , you should explain him how should he do it , if not by using a DMZ for the server and a firewall rule forwarding traffic from wan to an ip on lan then what .
In an overall , you will get to the same position as i were here , the difference between your point of view and mine , is basically because you consider a DMZ zone as a protection for Internal Lan , while i consider a DMZ zone a good place for a webserver without anything much important .
However , a firewall only protects you from attacks on your IP address , if by any chance an user on internal network runs a malicious script , the attacker can get into the lan bypassing the firewall and accessing lan computer/s (trojan horse).
People using a firewall and expecting that they can do whatever they want on the web without responsibility is the same thing as not having a firewall at all .Well , could you please explain him how should he do it ?
-
You are misusing the term "DMZ". It doesn't mean that. See the previous replies. You're confusing the actual DMZ concept with 1:1 NAT, and you're doing everyone a disservice by continuing to perpetuate the wrong definition. Word choice matters, it's not a point of view, it's an industry standard definition.
We have docs explaining how to make a proper DMZ. It's discussed in the book, I did a hangout about it not long ago, and there is this doc on the wiki: https://doc.pfsense.org/index.php/Example_basic_configuration
-
Ok, well based on all the advice, I've tried to follow the guide posted by jimpo but feel I've made a poor attempt. My DMZ doesn't even have internet access :(
-
And where is a rule that would allow internet access?
And why do you have a WAN net source in your dmz interface tab? You read the guide??? Really? From your rules seems unlikely to be honest..
Why would your dmz devices need access to pfsense wan address on 53?? They should be asking pfsense dmz IP address for dns or some other IP for dns, etc..
Here is a sample dmz setup from my setup.
So lets walk thru the rules
first 2 allow clients in the dmz to ping and use ipv6 icmp to pfsense IP address in the dmz segment
3rd allows clients in the dmz to ask pfsense both ipv4 and v6 for dns.
4 rule - any other access to any other IP that is on pfsense, be it dmz, lan, wan, any IP address configured on pfsense on any port would get a reject(blocked) and be logged..
5 This rules allow dmz clients to go anywhere they want as long as NOT rfc1918 space (192.168, 172.16-31, 10.) ie this allows internet access..
6 Is the same sort of rule but allows dmz client to go to any IPv6 address space that is not mine.. I have a /48 from HE.. This alias includes /64 I am using currently.
-
Ok. How about this… Also, bear in mind that this pfSense box is already inside a network, it is not used as the main router.
-
What I don't get is why you would block only icmp to your wan net?? So every other service to your "wan net" is fine - http, ssh, anything UDP, etc. etc..
And then lets block only TCP to the firewall?? So you can ping anything, you can query dns on any interface, etc.
Do you have other networks other than lan? If so that last rule allows access to them, even on the wan net etc..
-
What I don't get is why you would block only icmp to your wan net?? So every other service to your "wan net" is fine - http, ssh, anything UDP, etc. etc..
Ideally I'd like to block all on the wan net to the DMZ, however when I chose 'any' it killed all internet access to the DMZ.
And then lets block only TCP to the firewall?? So you can ping anything, you can query dns on any interface, etc.
I've changed this now, forgot to change the protocol.
Do you have other networks other than lan? If so that last rule allows access to them, even on the wan net etc..
I have WAN and LAN. What do your bottom two rules in the example picture look like in edit mode?
-
Attached is rule page, and alias used in that page.
As to blocking any to your wan net stopping internet access.. Well you got something ODD then.. clients in the dmz shouldn't give 2 shits about what your "wan net" is.. Are they pointing to something in your wan net for dns, proxy? etc..
-
I think it's because this pfsense box is inside a network already. So the WAN is actually DHCP to the outer network.
Would that make a difference?
Edit: This seems to be doing the trick…
Can you forsee any downsides with this?
-
Doesn't matter in the big picture how many nested nat levels your below the public internet for your wan.. pfsense clients don't give 2 shits about that.. Pfsense out of the box nats all the clients behind it to wan IP be it public or rfc1918 and sends the traffic to its gateway.. The clients behind have NO use of any of this information or access to any of that..
Why don't you put a log on that rule that is allowing tcp/udp to your wan net and see what is going on - my guess is they are point to dns in your wan net vs using pfsense as dns.
-
Doesn't matter in the big picture how many nested nat levels your below the public internet for your wan.. pfsense clients don't give 2 shits about that.. Pfsense out of the box nats all the clients behind it to wan IP be it public or rfc1918 and sends the traffic to its gateway.. The clients behind have NO use of any of this information or access to any of that..
Why don't you put a log on that rule that is allowing tcp/udp to your wan net and see what is going on - my guess is they are point to dns in your wan net vs using pfsense as dns.
I suspect that you are indeed as normal right, John. Thanks for your help.
-
so did you log the rule and see what they are trying to talk to in the wan net?
-
I would get rid of both those Destination: WAN net rules. I don't see the point.
And, for consistency, I would change the Block DMZ Access to LAN rule to IPv4+IPv6.
Other than that if your only inside interfaces are LAN and DMZ you're getting close.
I would also consider only allowing the ports out that need to go out, like TCP/25 for a mail server, etc.