NAT to openSUSE server SSH over DMZ not working
-
I set up a NAT in pfsense 2.0.1 from my WAN to my DMZ NIC on an openSUSE 11.4 server on port 22 for SSH. When I SSH my WAN IP from the outside it just hangs for awhile and then times out. Using nmap on pfsense I can see that over the DMZ port 22 is open and is returning the openSSH version. If I set the NAT to the internal NIC/IP of the server, SSH works. If I SSH into the pfsense box I can then SSH to the DMZ IP of the server and it works just fine. So why in the world would it work to the internal, work from the pfsense box, but not work to the DMZ? I'm really stumped…
-
Hmmm… I feel like I might not have been very clear because I haven't gotten any responses. Could it have to do with the fact that my default gateway for my server is on the internal side? WAN-->Firewall-->DMZ-->Server-->Internal? In other words, if the default gateway is on the internal side, would that mean that responses to my SSH request on the DMZ would be answered on the internal side, thus going nowhere?
-
Hello, yes, you have a split route, if you make the server's default gateway the DMZ interface address on the pfSense machine, it should work without any problems. Assuming that you have NAT and your rules correct. Generally, if you are going to make a DMZ, those server would not have an internal address per se. The reason is that if the server is compromised, they would have access into the LAN, thus rendering the firewall useless.
-
True, and usually I try not to do this. This is a very small deployment and for cost reasons the server needs to have internal and DMZ access. I'm relying on openSUSEs internal firewall to do it's job. There's no private customer data on anything in this particular internal network so it wouldn't be catastrophic for it to be compromised. What I'm thinking is that rather than changing default gateways, I'll throw a raspberry pi on the DMZ and use it as an SSH server and change the NAT to it's address. That way, because the DMZ NIC on the server would be on the same subnet as the pi it wouldn't look for the gateway to resolve and therefore wouldn't go internal. Right? Then for securities sake I would go certificate only login on the pi with a large passphrase. I think that's about as safe as I could make it…
-
that sounds good. it would not need to route to the default gateway because it is on the same subnet …
-
Thank you for your help!