Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 3249 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.
  • 0
    It sounds like settings on the mailserver. I run nearly the same setup.
    What you describe sounds like it should work.
    Are you MASQing the DMZ traffic to the .228 address?
    Mail server in DMZ.
    I forward 110 and 465 (SMTP-SSL) directly to the mailserver.
    Incoming on port 25 is received by the ASL SMTP proxy for my domain and sent to the mailserver in the DMZ.
    The mailserver sends directly via DNS/MX record except to certain domains. It sends those mails to the ASL SMTP proxy which forwards them to my ISPs smarthost.
    I've screen-capped my SMTP proxy config if you want it. It's easier than describing everything. Where should I send them?
  • 0 in reply to JimmyM
    Jim,

    I can't masq DMZ to .228 'cause it's the secondary IP address of the same ethernet card.  The MASQ rule allows you to tell a defined network to masq only as a specified hardware card, not a specified interface.  This has created headaches for me before, and I fear it could result in some mail getting caught in spam filters.  Anyone have a workaround for that?

    It is very possible the rest was mailserver config, but that brings up one of my questions from the first post. . .when the mailserver (on DMZ) gets POP3 requests from inside the LAN, does it see their source address as LAN or DMZ?  If LAN, I shouldn't have had any problem at all since the server was getting requests from the exact same people as before. . .

    There was no packetfilter drop traffic so I'm really baffled what was causing this.

    Thanks

    Dan
  • 0 in reply to martindw
    Instead of MASQing, SNAT your mailserver's DMZ IP address to the external alias IP. I'm assuming the DMZ interface IP of ASL has been set up as the default gateway in the mailserver's IP settings?
    Unless you have some sort of SNAT set up for internal traffic on port 110 to the mailserver, the mailserver will see the internal network IP of the client.
  • 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...)
  • 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