1 of 1 people found this helpful
I noticed that you don't have NAT enabled in your rule. Is the IP address of the DMZ server a private or publicly routable address? If it is a private address then try enabling NAT (localhost). If NAT is not needed, then check the audit on the firewall while attempting to send mail. From CLI, run 'showaudit -k > /var/log/audit.txt'. Execute the command and attempt to send an email.
When the email fails, stop the showaudit command. Analyze the audit capture with 'cat', 'more', 'less', etc. and search for the DMZ servers IP address. Post the audit entry that you find in the forum.
You're right that it should have been NAT'ed. I changed to NAT like it is supposed to but am still running into the same issue. I'm going to look at the logs as you suggested and will report back.
Thanks for your help!
Can anything be established by looking at the Postfix logs?
Aside from the NAT observation, there isn't anything fundamentally wrong with your access control rule. I would then check to if it could be one of the following issues:-
- The outbound SMTP connections from the Postfix server aren't getting as far as the Firewall.
- The Postfix server is somehow not conforming to the basic SMTP protocol standard and the Firewall is rejecting the connections.
A tcpdump against the DMZ interface of the Firewall should answer the first point. In the case of the second, the Firewall audit should tell you what's going on. The connections are getting as far as the Firewall but are being rejected in some way if you look at the Audit Viewer screen in the Firewall GUI while trying to initiate an SMTP connection from the Postfix server, you should see "Protocol Violation" entries in the audit.
From the mail server machine on the DMZ can you telnet (on port 25) to a known mail host on the Internet?
Is DNS resolving on this network? If the Postfix server isn't forwarding outbound mail to a specific IP address, or it is explicitly forwarding to a mail host using a DNS hostname, is it possible to resolve that hostname?
In PostFix, I'm seeing the error below when trying to send an email outside the network (sending inside the network works fine):
Feb 24 13:55:09 media postfix/smtpd: 2F06E3202D0: client=localhost.localdomain[127.0.0.1]
Feb 24 13:55:14 media postfix/cleanup: 2F06E3202D0: message-id=<20120224185509.2F06E3202D0@server.domain.com>
Feb 24 13:55:14 media postfix/qmgr: 2F06E3202D0: from=<firstname.lastname@example.org>, size=375, nrcpt=1 (queue active)
Feb 24 13:55:14 media postfix/smtp: 2F06E3202D0: lost connection with gmail-smtp-in.l.google.com[126.96.36.199] while receiving the initial server greeting
Feb 24 13:55:14 media postfix/smtp: 2F06E3202D0: lost connection with alt1.gmail-smtp-in.l.google.com[188.8.131.52] while receiving the initial server greeting
Feb 24 13:55:14 media postfix/smtp: 2F06E3202D0: lost connection with alt2.gmail-smtp-in.l.google.com[184.108.40.206] while receiving the initial server greeting
Feb 24 13:55:14 media postfix/smtp: 2F06E3202D0: lost connection with alt3.gmail-smtp-in.l.google.com[220.127.116.11] while receiving the initial server greeting
Feb 24 13:55:14 media postfix/smtp: 2F06E3202D0: to=<email@example.com>, relay=alt4.gmail-smtp-in.l.google.com[18.104.22.168]:25, delay=10, delays=10/0/0.02/0, dsn=4.4.2, status=deferred (lost connection with alt4.gmail-smtp-in.l.google.com[22.214.171.124] while receiving the initial server greeting)
What does the firewall's audit say?
acat -k on the command-line.
DNS is clearly working.
Which version of McAfee Firewall Enterprise are you using?
Also, take that endpoint out of your rule, whatever that smtpserver.domain.com object is. See if that's the problem.
I've logged in as an administrator to the firewall via SSH. However, when I try to run acat -k on the command-line it says: "Operation Not Permitted"
Type 'srole' and hit Enter.