Sanity Check
-
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.