DMZ bridged to WAN cannot reach LAN
-
HI All,
I installed pfSense with this config:
- WAN interface with public IP
- DMZ interface without IP and bridged to WAN
- LAN NATted with WAN IP address
In DMZ i have an host with public IP filtered with rules on WAN
In LAN i have an host with private IP and should be reached from the DMZ host on a specific port (to access the DB in LAN)
All works fine expect that DMZ can't reach the host on the LAN. I also tried to relax rules ....but nothing. And i get a surprising behaviour packets from DMZ to LAN seems arrive from WAN interface...in system log.
Here a "graphic" scheme:
PPP.PPP.PPP.x are public IPs
LLL.LLL.LLL.x are local IPs|---------------------pfsense---------------------| INTERNET ------- ROUTER --------------|WAN -----------------bridge------------------DMZ |--------DMZ HOST IP: PPP.PPP.PPP.94 |IP: PPP.PPP.PPP.90/29 | IP: PPP.PPP.PPP.91/29 |GW: PPP.PPP.PPP.94 | GW: PPP.PPP.PPP.90 | | |LAN | |LLL.LLL.LLL.1/24 | |-------------------------------------------------| | | |------------ LAN HOST IP: LLL.LLL.LLL.20/24 GW: LLL.LLL.LLL.1
Thanks in advance,
Alessandro -
Is this /29 routed to you?
What is the point of hiding your local - which I assume are rfc1918?
So you want to create a BRIDGE, yet you set the devices on your dmz gateway to pfsense IP on the bridge?? Your going to get some odd behavior with such a setup.
Did you setup filtering on the bridge interface or on each interface in the bridge?
If /29 is just attached... Why would you not just send traffic through to dmz via VIP and port forward or 1:1 NAT vs this bridge nonsense..
-
@johnpoz said in DMZ bridged to WAN cannot reach LAN:
Is this /29 routed to you?
Short answer: YES: Long: It is on the OVH infrastructure on a dedicated server with proxmox, IP PPP.PPP.PPP.88/29 are routed to/through proxmox with the associated virtual MAC.
What is the point of hiding your local - which I assume are rfc1918?
The LAN is RFC1918 (192.168.x.0/24) and contains some virtual desktop VMs and a freenas server VM with data. I want to protect these but i have to mount an NFS share of the freenas on the DMZ Host.
So you want to create a BRIDGE, yet you set the devices on your dmz gateway to pfsense IP on the bridge?? Your going to get some odd behavior with such a setup.
The bridge is between WAN and DMZ only, LAN is NATted with WAN IP. Why so odd?
This way i can assign PUBLIC IP in DMZ directly without wast IPs in subnet.
I could use NAT but it could give me some problem with some service(inside DMZ) like ftp server or VoIP....and others...Did you setup filtering on the bridge interface or on each interface in the bridge?
Filtering is on each single interface (WAN/DMZ)
If /29 is just attached... Why would you not just send traffic through to dmz via VIP and port forward or 1:1 NAT vs this bridge nonsense..
I'm evaluating this option, too. But 1) i would avoid NAT 2) i would understand something more.
Thanks in advance...in you can help me.
Alessandro -
So the answer is NO to routed.. I believe - I do not believe OVH will route to you? If it was routed to you there would be a transit network to your wan and the /29 would be "routed" to your IP on you wan and you could just put this /29 behind pfsense without nat..
There have been other threads with OVH and how they do things.. But don't really recall all the details have to do some browsing of old threads.
I think more this /29 is just attached and assigned to you for use.. In such a case its better to just create a VIP on your wan and then just either port forward or do a 1:1 nat..
Even with your bridge and trying to use the bridge IP as a gateway your going to see asymmetrical traffic flow.. Since your client sends to bridge IP, then bridge IP (pfsense) has to send the traffic back on to actual gateway. But the return traffic would just go to the host /29 IP that created the traffic... And vise versa when traffic was sent to the host directly - the host would send data back to its gateway the .90 in your setup.. A real mess for any sort of stateful firewalling..
-
Yes, with a bridged setup like that I expect the DMZ clients to use the .94 gateway directly.
They would then need a static route to the LAN subnet via the bridge IP, .90, if they need to able to open connections that way. Usually the idea of a DMZ is prevent that though.Steve
-
Well I can see prevent dmz from creating traffic into the lan, but lan into dmz is norm fine because you normally allow internet traffic into dmz ;)
But yeah this setup is ODD and a real asymmetrical mess with the gateway like that.. If you were going to bridge then concur with Stephen on the gateway should be the isp side IP. But if you think it is routed - then you would never do it anything like that.
I personally would never do it like that even if directly attached, ie would just create vip.. Unless there was some layer 2 protocol needed bridging gets you nothing but a more complex setup and headaches in the long run.
-
I've had to do that a few times for devices that just would not work through NAT. Older PBXs mostly.
Never had any real issues with it.Steve
-
@stephenw10 said in DMZ bridged to WAN cannot reach LAN:
I've had to do that a few times for devices that just would not work through NAT. Older PBXs mostly.
Never had any real issues with it.The problem are:
-
if I use .94 as gateway, DMZ host goes on the internet but it cannot ping LAN HOST. I tried to add a static route but pfSense says that "This network conflicts with address configured on interface LAN"
-
if I use .90 as gateway, LAN HOST seems to ping DMZ HOST from WAN interface (!) and DMZ HOST doesn't go on the internet.
What's wrong?
Thx
Alessandro -
-
You need to add the static routes on the DMZ clients themselves so they know how to reach the pfSense LAN subnet. Not in pfSense.
Steve
-
@lalex86 said in DMZ bridged to WAN cannot reach LAN:
I could use NAT but it could give me some problem with some service(inside DMZ) like ftp server or VoIP....and others...
For starters you shouldn't even be using ftp ;) Use sftp or just some web protocol to server or receive files. But it can work through nat just fine - same with voip.. You would save yourself a lot of grief just natting this.. Or routing it and just loose the couple of IPs out of the /29
Your causing yourself way more pain than just doing it with nat or route..
-
@lalex86 said in DMZ bridged to WAN cannot reach LAN:
@stephenw10 said in DMZ bridged to WAN cannot reach LAN:
I've had to do that a few times for devices that just would not work through NAT. Older PBXs mostly.
Never had any real issues with it.
The problem are:
- if I use .94 as gateway, DMZ host goes on the internet but it cannot ping LAN HOST. I tried to add a static route but pfSense says that "This network conflicts with address configured on interface LAN"
The way I design DMZs this is the correct behavior. I design a DMZ so that it only accepts incoming traffic from specific ports and can only respond to those incoming connection. That way, if the endpoint is breached, it's contained and cannot get out. By allowing your DMZ to initiate a connection to your internal network, if the endpoint is breached, it now has access to your internal network.
It does make things a bit more complicated, and software developers generally hate me for it, but I have my reasons for it, and it does make things more secure IMHO. In the cases where I need to make exceptions, they are locked down (port/protocol/single endpoint, etc.). But I generally try to avoid opening any outgoing ports in a DMZ where I can.
-
If "dmz" was open to your lan - then it wouldn't be a dmz ;)
You might open a pinhole or 2... But open - I think everyone would agree that is horrible practice..
Lan into dmz - that is a different story..
-
Ok thanks all.
-
i finally decided to use VIP with port forwarding. I would say as memo for people in the same condition that OVH send you packet with the VIP IP (.91 in my case) only if you give it (on the OVH panel) the same MAC address as the WAN IP (and that you should have configure on the WAN interface of the pfSense VM);
-
you are ALL right, connections from DMZ to LAN are not a good practise even if reduced to the minimum. So what is the best practise to access data (db or shared files) from DMZ servers to LAN NAS?
Thx
Alessandro -
-
Quite often data that has to be access by dmz is put in the dmz ;) Or you can do what is called an internal dmz and external dmz.. It amounts to just another firewall segment that is more isolated..
So say all your server there users normally access.. They are in the server lan.. Server that house data that dmz server need to access would be in say the internal dmz, while servers touched by the public is external dmz.. Where you allow specific pinholes into the internal dmz from external..
Lot of factors that come into play here... Without understanding of your data, servers in use it is impossible to say what sort of setup would best suite your needs.. Keep in mind there are always one offs to any sort of security policy ;) Unless your in some dod facility, etc.
-
I do similar stuff as @johnpoz has recommended but can simplify the explanation:
If you have an application that requires access to a data source, put that data source into the DMZ with the app server. Things that need to access that data can always reach into the DMZ to pull things out, by design.
Now the complicated part that usually annoys the heck out of app developers:
For security purposes, the data source inside the DMZ should contain very little data. You can have a LAN-based database replicate or extract any new data at a set interval (1 second, 5 seconds) to move it into the LAN. The concept is application and data segregation over the network. Always assume your exposed server is going to get breached. You should move all important data into the LAN into another part of the application that will poll the servers/services in the DMZ for new data. They will pull data into the LAN where it can be processed and then pushed back into the DMZ, and then the servers/services in the DMZ can send it out the WAN to the client that requested it. This way, when your servers in the DMZ get breached, there is very little data there at all.
Architecting applications like this creates overhead, and you need to take that into account as you architect them. However, the principles are there to protect your data. Once a hacker breaches your stuff, the next thing they will do is pivot to exploit other devices. By caging them in the DMZ, they cannot pivot, or they can only pivot to other servers within the DMZ (or not, depending on how you designed it). If your data source of record is stored in your LAN, there is very little chance that when you do get breached, they won't be able to reach that data.
If I can't design like that and am required to create pinholes, I usually have someone sign off in blood on that. My network is only as secure as your app requirements allow me make it. :)
-
Hi, you give us good and right suggestions....
just to explain...
In my case the (main) purpose is to use a NAS (freenas) in the LAN both as LAN file server (throught smb shares) and as repository for the git server in the DMZ.
The best solution would be one NAS in the DMZ and a second NAS in the LAN that replicates or backups data in the DMZ (with a connection LAN to DMZ).... but we are a small office and we to deal with resources; so i decided to compromise using the same NAS in the LAN also for the DMZ server....
Thx
Alessandro -
So you understand there is risk, yet you choose to expose ALL of your data to the public, not just the git data?
So who signs off on this risk? Is Tim's point ;)
Get another nas for your git data.. Have your nas from your secure network back up the data.. Sorry your normal nas data that users access is now at risk.. Lets say the box is exploited... What keeps them from compromise of the data your users are accessing.
You might be more secure leaving the nas in lan, and only allow pin hole from the git server to the git data that is isolated on its own volume/lun and only access via specific protocol from the git dmz server.. This reduces the protocols that are allowed through the firewall... Vs say http to the git server which would then have unfettered access to the nas since on the same network with no firewall between. If your going to do such a thing then you need to make sure all other protocols disabled or locked down with HOST firewall, etc. etc.. Or you put the nas in the internal dmz vs the external one like I was saying.
-
@lalex86 said in DMZ bridged to WAN cannot reach LAN:
Hi, you give us good and right suggestions....
just to explain...
In my case the (main) purpose is to use a NAS (freenas) in the LAN both as LAN file server (throught smb shares) and as repository for the git server in the DMZ.
The best solution would be one NAS in the DMZ and a second NAS in the LAN that replicates or backups data in the DMZ (with a connection LAN to DMZ).... but we are a small office and we to deal with resources; so i decided to compromise using the same NAS in the LAN also for the DMZ server....
Thx
AlessandroI have a similar requirement at a client's office. Here was my general approach:
Only give specific and limited access to devices that need to do this. So in pfSense you want to only open the ports/protocol necessary to make and maintain a SMB connection to the NAS. I think that's 3 ports. The point that you're mounting on the NAS should only contain the data that the server needs to access. Create a "service login" specifically for that server to use, and limit the access of that login only to the mount point with the data it needs to access.
This way when the server gets breached, the bad actor can only access a SMB mount point that only contains that server's data. It will be very difficult for them to pivot from that point, but it does put your data at risk of corruption from a bad actor. With proper backups in place (and a reasonable RTO/RPO), you can minimize that risk.
-
SMB should run over 1 port tcp 445... No need to open up the the old school netbios ports.
-
@lalex86 yes, you are missed basic's of networking security?
I totally agree with @johnpoz and @stephenw10 write , but if you want explore new ways for make firewall-ing concept to work, I advice you to add , first of all ...more NIC on your server, and reserve one nic for DmZ and other to Lan.
By this way , you can handle connections of any kind , with a proper configuration for each one, meets firewall-ing standard concept in mind.
More nic's more fun! hahah lool
Please forgive me