ACCESS FTP Server on LAN from DMZ
-
Hello,
New to PF
I am trying to setup access for 2 machines on the LAN form a DMZ WebServer, a Database Server using port 2025 and an FTP server using ports 20-21 & 14236 - 14239 (passive).
I can, of course, ftp to the web server from LAN. But I get a timeout when I try to ftp the DMZ address (nat'd to the internal ftp servers) from the web server.
For example. The web server address is 10.0.0.6, the DMZ address is 10.0.0.5. Port forwarding 10.0.0.5:20/21/14236-14239 to 192.168.1.110 (FTP Server) just hangs, no response.
Here come the screenshots of the rules/nat.
NOTE: The LAN Rules have only a partial ftp config, I was doing this in order to test, to see if I was on the wrong tab creating the rules.
TIA!!
Mike
-
The NAT is wrong, but you should just route as there is no need to NAT.
SSH/SFTP from my WAN interface to the DMZ looks like the attachment.
n_ipv4_friendly is an alias for friendly IPv4 public IP addresses.
-
I thought routes were default blocked when a DMZ was setup? Meaning I would have to manually manipulate the rules for DMZ to have access to LAN.
Hence why I am attempting a NAT from DMZ to LAN.
If my FTP-server on the LAN is 192.168.9.110 (Uses another firewall for internet).
If my Database-Server on the LAN is 192.168.9.15
If my Web-Server on the DMZ is 10.0.0.6 GW 10.0.0.5 (DMZ Port)How would I setup a NAT/Route?Rule to allow:
Ftp Ports 20,21,14236-14286
DB Port 2025TIA
Mike
-
Don't NAT its just confusing the issue, route and adjust your firewall rules to suit.
Enable something simple like a ping between the devices for testing then worry FTP, etc … later.
You might be better using something like sftp if you can as it just uses a single port ( 22 TCP ).
Knock up a quick diagram and label the routers and their interface ip addresses, no need to include the external ip addresses.
-
Quick and dirty.
The idea is that I want only specific ports, FTP 20,21,14236:14286 to be routed to an FTP server on the LAN.
THere is another DB server that uses Port 2025 that I will do the same thing with… But different LAN IP.
Everything else dropped between dmz and lan. All outgoing to internet is fine.
-
Okay, something weird is going on.
I can, from the DMZ Web Server, ping a very select few IP's on the LAN side. I see nothing in the rules that indicate why these specific machines can be pinged, but not others.
However, I can ssh from these same machines to the WebServer form the LAN but SSHing directly to the WebServer's IP (I have routing configured on the windows server to point to it via 192.168.9.203)
-
"I see nothing in the rules that indicate why these specific machines can be pinged, but not others."
The machines your pinging could have firewall blocking - for example windows out of the box will block access from any network that is not its local network.
There is no nat need or that would be created between local rfc1918 network, or even between local rf1918 and public space. Auto sure would not of created a nat - so you changed outbound nat to manual/hybrid?
"I thought routes were default blocked when a DMZ was setup?"
Where would you have gotten that idea? DMZ is nothing special, its just a firewall segment like any other segment you create, etc.
Always just blows my mind why anyone would want to setup ftp in this day and age - why not just use sftp? It can be run for free on any OS both as server or client. Shoot MS has even created their own install of it. But I would recommend the openssh version - which here you can get windows version. https://www.mls-software.com/opensshd.html
-
The machines sat on the pfSense LAN know how to route to your DMZ subnet as the two subnets are directly connected via pfSense, its only machines on your DMZ with a default route out the other firewall that will need a static route adding.
With your ping test the ping requests will be hitting your 1st DMZ rule and the reply will be hitting your 3rd LAN rule, pfSense is a stateful firewall.
If you want to see it hit a specific firewall rule add icmp reply above the 3rd LAN rule.
You know you can get it to LOG packets under the extra options.
Also you could do a packet capture on the LAN interface when pinging the machines on the LAN that don't ping from the DMZ, is the packet hitting the LAN interface?
14:17:33.785291 IP 172.16.2.20 > 172.16.5.2: ICMP echo request, id 28578, seq 0, length 64
14:17:33.786052 IP 172.16.5.2 > 172.16.2.20: ICMP echo reply, id 28578, seq 0, length 64
14:17:34.785883 IP 172.16.2.20 > 172.16.5.2: ICMP echo request, id 28578, seq 1, length 64
14:17:34.786527 IP 172.16.5.2 > 172.16.2.20: ICMP echo reply, id 28578, seq 1, length 64
14:17:35.785827 IP 172.16.2.20 > 172.16.5.2: ICMP echo request, id 28578, seq 2, length 64
14:17:35.786502 IP 172.16.5.2 > 172.16.2.20: ICMP echo reply, id 28578, seq 2, length 64
-
"its only machines on your DMZ with a default route out the other firewall that will need a static route adding."
Exactly.. This leads to asymmetrical routing..
-
With regard to FTP, we have a few Spark2 machines that are still active production… 25 years later...
I removed all NAT rules except on wan. Then I just modified the LAN/DMZ rules and it all works now.
What I was running into is that the LAN computers didn't have 192.168.9.203 as an alternate gw. We have a sonicwall for our default gw.
It's the little things in life that keep you up until 5am, doing your best to go bald...
Thanks for all your help guys!
-
what OS are they running SunOS, Solaris? SSH has been around for 22 years.
-
They are running sunOS 4.1.4 - they use rlogin still :'(
LOL, I virtualized one of them just out of concern of the age. We are terrified when we have to reboot them!
-Mike
