Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 3251 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mail Server in DMZ -- HELP!!!

martindw
I have tried, completely without success, to install a mailserver into the DMZ of a new client's network tonight.  I'm not sure whether this should be a post for this forum, or for the SMTP or POP3 fora, but this seems the most general.  Here's my situation:

3-NIC setup--LAN 192.168.1.1, DMZ 10.1.1.1, WAN 64.x.x.226.  Second IP address on WAN NIC is 64.x.x.228, which is the address of record for the client's mail and webservers.  LAN access to the internet, including packet filtering, is working flawlessly using a generic Masq rule.

Mail/webserver are actually the same box, an old Cobalt Qube which was installed previously on the LAN side of a very basic Netscreen box, with the .228 IP address simply mapped thru to a LAN address on the Qube.  I changed the Qube's IP address to 10.1.1.2 and stuck it on the DMZ.  I then created a DNAT rule mapping the public ip .228 on http service only to 10.1.1.2, and could surf to the Qube's website from both LAN and internet.

Mailserver was a different story.  Although I can ping the Qube's 10.1.1.2 address from the LAN, I can't connect to it from a mail client.  It occurs to me now (didn't then) that this could be due to allowed networks on the Qube; in this setup, is Qube gonna think it's getting POP3 requests from the 10.x.x.x or the 192.x.x.x networks?  If the latter, no setting changes should be necessary as that's the network that accessed it all along; if the former, this may have been part of my problem.

Anyhow, carrying on, I *also* couldn't get the SMTP to work.  Qube was unable to send any outbound mail out using SMTP Proxy, even tho I set up the proxy with DMZ as allowed network, and pointed the proxy to the 10.1.1.2 IP for the server.

I have the system working temporarily by setting the Qube back on a 192.168.x.x address, mapping the WAN .228 address to the LAN one, and opening POP3 and SMTP packet filter ports (neither POP3 nor SMTP proxy seems willing to function).  But obviously, this is a less-than-adequate solution as I very much want to implement both the protections of DMZ and SMTP proxy.

Will someone please walk me thru what needs (and/or doesn't need) to be set up to make this function?  Assume I know nothing and you need to explain everything; you probably won't be far off. . . 

TIA,

Dan


This thread was automatically locked due to age.
Parents
  • 0
    [ QUOTE ]
    Although I can ping the Qube's 10.1.1.2 address from the LAN, I can't connect to it from a mail client.

    [/ QUOTE ]

    Ahh; but what happens when you ping by fully qualified domain name, as your mail clients will reference it? [server.yourdomain.com, .net .org...]
    Do we have the split-DNS problem here??

    (If we do, we fix it through DNS and/or mail client configuration...)
Reply
  • 0
    [ QUOTE ]
    Although I can ping the Qube's 10.1.1.2 address from the LAN, I can't connect to it from a mail client.

    [/ QUOTE ]

    Ahh; but what happens when you ping by fully qualified domain name, as your mail clients will reference it? [server.yourdomain.com, .net .org...]
    Do we have the split-DNS problem here??

    (If we do, we fix it through DNS and/or mail client configuration...)
Children
  • 0 in reply to SecApp
    Thanks to you both. . .fully-qualified domain name shouldn't have been a problem here since the mail clients were being given the IP address rather than the server name for server settings.

    I wound up having to contact Astaro support on this one (it's useful to buy a product occasionally, eh?    ) and the solution was a couple things:

    1)  As mentioned above, I did have to have an SNAT rule masquerading the mailserver on DMZ to the outside world, but as the alias IP (.228) not the main IP of the WAN card;

    2)  For the mailserver to break loose and talk to anyone at all, we had to enable the DNS proxy, which I had not enabled, and make sure both the internal and DMZ networks could access it.  Interestingly, it was opening this feature that permitted my POP3 clients to talk successfully to the mailserver. . .go figure. . . [:S]

    3)  Though this last shouldn't be necessary (I thought), outgoing mail from the mailserver was trying to go direct rather than thru the SMTP proxy and so I had to open a mailserver to Any port 25 rule on the packet filter.  I guess SMTP proxy isn't "transparent" the way POP3 proxy was, and this particular mailserver wouldn't let me specify a single IP for outgoing SMTP.  This showed (once the rest of the server was up and running) by having tons of dropped port 25 traffic from my mailserver to everywhere.  Opening port 25 outgoing cut loose a flood of backed-up outgoing mail on my server.

    Anyhow, with these three changes in place the new network is working swimmingly.! [:)]

    Thanks to all of you for your feedback.  .  .Problem Solved!

    Dan
Cookie Information Banner