[SOLVED] Zimbra with NAT-FORWARD

[Nascimento]

Hya everyone.

I have a little problem back there with a miss configuration doing OPEN RELAY at Zimbra - and now I have crumbled in that again:.

First of all - My firewall it is doing NAT over Zimbra, just like that:

external.ip.160 --> firewall | forward port 25 --> 192.168.0.4 (zimbra LAN ip)

My smtp solves to my external.ip.160 with all mx records - it's everything okay with my DNS's.

I have some doubts about Forwarding that port 25 -

When the WORLD tries to send an e-mail to my server, if i don't put my FIREWALL internal ip (Ex:. 192.168.0.1 - remember that Zimbra is 192.168.0.4!) into the trusted networks, the WORLD can't send me e-mails.

Well, i've checked the logs and everything hits my server as the internal ip from Firewall.

Is this a "NAT job" going wrong? 'Cause it was supposed to hit that with external.ip.160 (firewall external forwarding port 25 to internal zimbra server)

Pasting my relevant firewall rules:

my.external.ip.160 --> ip on eth0 - FIREWALL
192.168.0.1 --> ip on eth1 - FIREWALL
192.168.0.4 --> zimbra MTA ip

EXT= eth0 #external iface
INT = eth1 #internal iface

iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 25 -j DNAT --to 192.168.0.4:25
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 80 -j DNAT --to 192.168.0.4:80
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 110 -j DNAT --to 192.168.0.4:110
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 143 -j DNAT --to 192.168.0.4:143
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 465 -j DNAT --to 192.168.0.4:465
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 993 -j DNAT --to 192.168.0.4:993
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 995 -j DNAT --to 192.168.0.4:995
iptables -t nat -A PREROUTING -p tcp -i $EXT -d my.external.ip.160 --dport 7025 -j DNAT --to 192.168.0.4:7025

and some rulez so the FIREWALL itself can connect to the zimbra services.


iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 25 -j DNAT --to 192.168.0.4:25
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 80 -j DNAT --to 192.168.0.4:80
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 110 -j DNAT --to 192.168.0.4:110
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 143 -j DNAT --to 192.168.0.4:143
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 465 -j DNAT --to 192.168.0.4:465
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 993 -j DNAT --to 192.168.0.4:993
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 995 -j DNAT --to 192.168.0.4:995
iptables -t nat -A OUTPUT -p tcp -d my.external.ip.160--dport 7025 -j DNAT --to 192.168.0.4:7025


and of course, my POSTROUTING is working perfectly. no problems with that.

But how is that, closing the "trusted networks" with only '127.0.0.1 192.168.0.4/32'; my MTA stops receiving EMAIL? - no problem sending it.

Well - no log to show 'cause no email arrives. Only if I manage to put firewall internal ip (192.168.0.1) into trusted network, and with that open my relay again and going under that nightmare all night long.. .-.-'

PLz.. help?
Do I have to set up a bridge or something? - to get only valid ip addresses into my MTA?

Thnkx for the help!!!

Daniel Nascimento

[Dirk]

This should be a lot simpler than you are finding it, and it's been covered a few times before.

Basically, set the MX record to the external IP, port forward port 25 to your internal IP and that's all there is to it.

World DNS will resolve your server name to your external IP and you should set your local DNS to resolve the same name to your internal IP.

[phoenix]

Let me start this by saying that I'm not an expert with iptables, I use Endian Firewall in front of my LAN and I do not see the problem you're describing of having the Zimbra server acting as an open relay because it has the whole LAN subnet in the Trusted Networks. I do have the LAN subnet in the Trusted Networks configuration and I pass every open relay test.

Originally Posted by Nascimento

and of course, my POSTROUTING is working perfectly. no problems with that.

I think there's a misconfiguration in your POSTROUTING rules that's causing it to be the source of the 'open relay' problem, see the following quote from this tutorial:

Remember that the POSTROUTING chain is processed last of the chains, and hence the packet will already be DNAT'ed once it reaches that specific chain. This is the reason that we match the packets based on the internal address.

Warning

This last rule will seriously harm your logging, so it is really advisable not to use this method, but the whole example is still a valid one. What will happen is this, packet comes from the Internet, gets SNAT'ed and DNAT'ed, and finally hits the HTTP server (for example). The HTTP server now only sees the request as if it was coming from the firewall, and hence logs all requests from the internet as if they came from the firewall.

This can also have even more severe implications. Take an SMTP server on the LAN, that allows requests from the internal network, and you have your firewall set up to forward SMTP traffic to it. You have now effectively created an open relay SMTP server, with horrendously bad logging!

One solution to this problem is to simply make the SNAT rule even more specific in the match part, and to only work on packets that come in from our LAN interface. In other words, add a --src $LAN_IP_RANGE to the whole command as well. This will make the rule only work on streams that come in from the LAN, and hence will not affect the Source IP, so the logs will look correct, except for streams coming from our LAN.

You will, in other words, be better off solving these problems by either setting up a separate DNS server for your LAN, or to actually set up a separate DMZ, the latter being preferred if you have the money.

I'd suggest that you investigate that configuration some more.

[Nascimento]

Originally Posted by Dirk

This should be a lot simpler than you are finding it, and it's been covered a few times before.

Basically, set the MX record to the external IP, port forward port 25 to your internal IP and that's all there is to it.

World DNS will resolve your server name to your external IP and you should set your local DNS to resolve the same name to your internal IP.

That's already set up just like that, but anyway thnkx for the info, my friend!
As this network isn't mine, and it is not documented at all, I'm a little bit lost and that set up that u've highlighted shows me at least something that is right and should not be touched. ;-)

BIll, I will review my Postroute configs 'cause since from begining I was thinking of some wrong Post route settings passing some way'back packets just like has been described in that example by yours.

Thnk u for the info. I will have to try them latter - 'cause that company still working on Saturday's.

-----------------------
Many thnkx


Daniel Nascimento

[Nascimento]

OKay guys; the problem was a MASQUERADE at my postroute config.
I've used the SNAT insteed and works perfectly - everyone hits my MTA with they on IP. Great! Now I can put my LAN_IP range into my trusted networks withou a single problem with that!

- BUT - (There's always a catch)

Now ALL the world are incapable of send me emails. Every one crash at the - RELAY ACCESS DENIED.

Lol

Any tips?

My Trusted Networks:. '127.0.0.0/8 MY.LAN.IP.RANGE/24 MY.EXTERNAL.VALID.RANGE/24'

[phoenix]

Originally Posted by Nascimento

Now ALL the world are incapable of send me emails. Every one crash at the - RELAY ACCESS DENIED.

Is this for inbound email or users trying to send mail via a client? Are you saying that you're getting no inbound mail? I would guess this is another problem with your IPTABLES rules.

Originally Posted by Nascimento

My Trusted Networks:. '127.0.0.0/8 MY.LAN.IP.RANGE/24'

You do not need any other entries than those two. External users that connect via a client (such as Thunderbird, Outlook etc.) should be able to connect via port 587( you'll need to open that port) and authenticate and then send mail either to a LAN user or relay to another mail server.

[Nascimento]

Okay Bill, I have removed the external ip range.

But I'm not getting any inbound e-mails. But i guess this is not firewall, maybe DNS problems (I haven't checked the MX records closelly)

Weird things:

* When I do a telnet at port 25 to my FQDN, everuthing goes okay -

* But when I do a telnet at port 25 to my FIREWALL EXTENRAL IP - that must forward to Zimbra MTA LAN IP, I have no response till time out.

I'm on it, and I will post further results.

-------------------

Thnkx a lot!

[phoenix]

Originally Posted by Nascimento

* But when I do a telnet at port 25 to my FIREWALL EXTENRAL IP - that must forward to Zimbra MTA LAN IP, I have no response till time out.

Do you mean from your LAN or from an external IP address? A firewall doesn't normally allow you to go to the public IP (I'm sure you know that it's called 'loopback') from your LAN unless you've specifically allowed it via a rule. You can test your server from this site: MX Lookup Tool - Check your DNS MX Records online - MxToolbox - it will do a port scan for you (on the 'more' tab) and mx record checks, open relay test etc.

[Nascimento]

Originally Posted by phoenix

Do you mean from your LAN or from an external IP address? A firewall doesn't normally allow you to go to the public IP (I'm sure you know that it's called 'loopback') from your LAN unless you've specifically allowed it via a rule. You can test your server from this site: MX Lookup Tool - Check your DNS MX Records online - MxToolbox - it will do a port scan for you (on the 'more' tab) and mx record checks, open relay test etc.

Results are:
220 smtp.mydomain.com.br ESMTP Postfix


Not an open relay.
0 seconds - Good on Connection time
0.655 seconds - Good on Transaction time
OK - ***.***.***.*** resolves to smtp.mydomain.com.br
OK - Reverse DNS matches SMTP Banner

Session Transcript:
HELO please-read-policy.mxtoolbox.com
250 smtp.mydomain.com.br [156 ms]
MAIL FROM: <supertool@mxtoolbox.com>
250 2.1.0 Ok [172 ms]
RCPT TO: <test@example.com>
554 5.7.1 <test@example.com>: Relay access denied [156 ms]
QUIT
221 2.0.0 Bye [172 ms]
reverse lookup smtp diag port scan blacklist

Reported by mxtoolbox.com on Saturday, January 30, 2010 at 3:18:31 PM

-- port scan relevant --
[green] 25 smtp Success 156 ms
[green] 110 smtp Success 156 ms

[phoenix]

That would indicate that you should receive email, are you seeing mail in the Inbox? You said earlier the 'everyone' is getting relay access denied, I asked if these are users connecting via a client - is that the case? You should also check the log files and see what errors you're getting.