iptables, DNAT, and SMTP

Hello,

I've been reading for a couple days now and my mind has gone numb.
I'm hoping to get some help from the community, and I'm sure I'm just
overlooking something very simple. My goal is to forward smtp traffic
destined for one machine to another based on source.

I have done this: echo 1 > /proc/sys/net/ipv4/ip_forward

I've enabled the loading of iptable_nat in the iptables config file.

This is the base of what I'm using in my /etc/sysconfig/iptables file.
Any direction on what I'm missing would be greatly appreciated.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [52442:19228811]
COMMIT
*mangle
:PREROUTING ACCEPT [60986:54771131]
:INPUT ACCEPT [60982:54770891]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [52445:19228943]
:POSTROUTING ACCEPT [52445:19228943]
COMMIT
*nat
:PREROUTING ACCEPT [1581:83538]
-A PREROUTING -s xxx.xxx.66.0/24 -i eth0 -p tcp -d xxx.xxx.64.3 --
dport 25 -j DNAT --to-destination xxx.xxx.65.15:25
:POSTROUTING ACCEPT [74:4438]
:OUTPUT ACCEPT [525:34512]
COMMIT

Brandon <(E-Mail Removed)> wrote:
> Hello,

> I've been reading for a couple days now and my mind has gone numb.
> I'm hoping to get some help from the community, and I'm sure I'm just
> overlooking something very simple. My goal is to forward smtp traffic
> destined for one machine to another based on source.

> I have done this: echo 1 > /proc/sys/net/ipv4/ip_forward

> I've enabled the loading of iptable_nat in the iptables config file.

> This is the base of what I'm using in my /etc/sysconfig/iptables file.
> Any direction on what I'm missing would be greatly appreciated.

> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [52442:19228811]
> COMMIT
> *mangle
> :PREROUTING ACCEPT [60986:54771131]
> :INPUT ACCEPT [60982:54770891]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [52445:19228943]
> :POSTROUTING ACCEPT [52445:19228943]
> COMMIT
> *nat
> :PREROUTING ACCEPT [1581:83538]
> -A PREROUTING -s xxx.xxx.66.0/24 -i eth0 -p tcp -d xxx.xxx.64.3 --
> dport 25 -j DNAT --to-destination xxx.xxx.65.15:25

Don't replies from xxx.xxx.65.15 need to be SNATed to xxx.xxx.64.3?

> :POSTROUTING ACCEPT [74:4438]
> :OUTPUT ACCEPT [525:34512]
> COMMIT

--
Clifford Kite

Hello,

Clifford Kite a écrit :
> Brandon <(E-Mail Removed)> wrote:
>
>> I've been reading for a couple days now and my mind has gone numb.
>>I'm hoping to get some help from the community, and I'm sure I'm just
>>overlooking something very simple. My goal is to forward smtp traffic
>>destined for one machine to another based on source.

What's the problem ?
A description of the network layout, addressing, routes, interfaces may
help too.

>>*nat
>>:PREROUTING ACCEPT [1581:83538]
>>-A PREROUTING -s xxx.xxx.66.0/24 -i eth0 -p tcp -d xxx.xxx.64.3 --
>>dport 25 -j DNAT --to-destination xxx.xxx.65.15:25
>
> Don't replies from xxx.xxx.65.15 need to be SNATed to xxx.xxx.64.3?

That's implicit in any iptables NAT operation, at least as long as the
replies travel back through the NAT box (routing must be symmetric).

Sorry for the lack of detail. What I'm trying to do is this:

I have a publicly addresses mail server handling smtp and pop/imap
services. That's the xxx.184.64.3 box. I have recently installed a
publicly addresses Barracuda for my spam filtering. That's the xxx.
184.65.15 box. One problem is that many networks are not seeing my MX
change and are still sending straight to xxx.184.64.3. Another problem
is that my helpdesk has been setting up our customer's client software
with mail.domain.com for both the pop and the smtp server addresses,
and I also want to filter outbound mail with the Barracuda. I've set
smtp.domain.com to the IP of the Cuda, but the problem is that most
people have mail.domain.com set for their incoming and outbound server
settings. My goal is to be able to only accept smtp traffic to the
main mail server (xxx.184.64.3) from the Barracuda (xxx.184.65.15) and
if smtp traffic comes from anywhere else, I would like to reroute it
to the Barracuda.

Again, sorry for the lack of detail, as my iptables experience is very
limited. I've read through the MAN page for it and have also been
looking around on forums; but no one seems to be doing anything like
this. Most everything I'm finding is a situation in which people are
forwarding to a privately addresses destination from their iptables
based gateway/firewall machine.

Thanks again!
Brandon

Brandon a écrit :
>
> Again, sorry for the lack of detail, as my iptables experience is very
> limited. [...]

This does not matter. What matters it that you did not answer my
questions. Maybe I was not clear enough, so I'll rephrase.

What is the problem ? In other words, what is the result that you
observe instead of what you expected ?

You need to tell more about your network setup : where is the mail
server, where is the Barracuda, where are the clients, where are the
routers/firewalls/gateways ?

On which host is the iptables rule ? On the mail server (xxx.184.64.3)
itself or on another box acting as a router/gateway/firewall/whatever ?
What are the interfaces and routes on this box and on the Barracuda ?

What is xxx.xxx.66.0/24 ?
You said that SMTP traffic from anything but the Barracuda
(xxx.184.65.15) should be redirected, but xxx.xxx.66.0/24 does not look
like "anything but the Barracuda".

Assuming that the rule is on the mail server, what about theses rules :

iptables -t nat -A PREROUTING -i eth0 -s ! xx.xx.65.15 -d xx.xx.64.3 \
-p tcp --dport 25 -j DNAT --to-destination xx.xx.65.15
iptables -t nat -A POSTROUTING -o eth0 -s ! xx.xx.64.3 -d xx.xx.65.15 \
-p tcp --dport 25 -j SNAT --to-source xx.xx.64.3

(I slightly modified the DNAT rule and added the SNAT rule)

Be aware that if this solves the problem it does not mean that it is an
adequate solution. The SNAT rule hides the real source address from the
Barracuda, and this may be a problem.

> What is the problem ? In other words, what is the result that you
> observe instead of what you expected ?
What I'm observing are failed connections to xxx.184.64.3 when the
rules are in place.


> You need to tell more about your network setup : where is the mail
> server, where is the Barracuda, where are the clients, where are the
> routers/firewalls/gateways ?
The mail server and the Barracuda are connected to a Cisco switch. The
only filtering done here is an ACL that is allowing anything the
desired outcome would require. There are no other firewalls/gateways/
routers other than what the clients are connecting back on. They are
also permitted to get there.


> On which host is the iptables rule ? On the mail server (xxx.184.64.3)
> itself or on another box acting as a router/gateway/firewall/whatever ?
> What are the interfaces and routes on this box and on the Barracuda ?
The iptables rules I'm trying to create are on the mail server itself.
There is not another box acting as a gateway. The only equipment
involved are the Barracuda and the mail server.

> What is xxx.xxx.66.0/24 ?
> You said that SMTP traffic from anything but the Barracuda
> (xxx.184.65.15) should be redirected, but xxx.xxx.66.0/24 does not look
> like "anything but the Barracuda".
xxx.184.66.0/24 is the network I was testing from. This would have
changed to what you have below when in production.

> Assuming that the rule is on the mail server, what about theses rules :
>
> iptables -t nat -A PREROUTING -i eth0 -s ! xx.xx.65.15 -d xx.xx.64.3 \
> -p tcp --dport 25 -j DNAT --to-destination xx.xx.65.15
> iptables -t nat -A POSTROUTING -o eth0 -s ! xx.xx.64.3 -d xx.xx.65.15 \
> -p tcp --dport 25 -j SNAT --to-source xx.xx.64.3
This produces the same results as what I had before. When these rules
are in place, connections to xxx.184.64.3 act as if there is nothing
listening on port 25.

> (I slightly modified the DNAT rule and added the SNAT rule)
>
> Be aware that if this solves the problem it does not mean that it is an
> adequate solution. The SNAT rule hides the real source address from the
> Barracuda, and this may be a problem.
This will be a huge problem. I need the packets to look as though they
came from their original source and not from the mail server. Is this
possible with what I'm trying to do, or am I out of luck?


Thanks again!

Brandon a écrit :
>>What is the problem ? In other words, what is the result that you
>>observe instead of what you expected ?
>
> What I'm observing are failed connections to xxx.184.64.3 when the
> rules are in place.

How exactly do connections fail ? Are they immediately rejected or do
they hang until they eventually time out ? Did you sniff traffic on the
client, the mail server and the barracuda to watch what's going on ?

>>Assuming that the rule is on the mail server, what about theses rules :
>>
>>iptables -t nat -A PREROUTING -i eth0 -s ! xx.xx.65.15 -d xx.xx.64.3 \
>> -p tcp --dport 25 -j DNAT --to-destination xx.xx.65.15
>>iptables -t nat -A POSTROUTING -o eth0 -s ! xx.xx.64.3 -d xx.xx.65.15 \
>> -p tcp --dport 25 -j SNAT --to-source xx.xx.64.3
>
> This produces the same results as what I had before. When these rules
> are in place, connections to xxx.184.64.3 act as if there is nothing
> listening on port 25.

When nothing listens on a TCP port (port closed), connection attempts
are immediately rejected. Is this what happens ? Do you see the packet
count increment for the rules in the output of iptables-save -t nat -c ?

>>Be aware that if this solves the problem it does not mean that it is an
>>adequate solution. The SNAT rule hides the real source address from the
>>Barracuda, and this may be a problem.
>
> This will be a huge problem. I need the packets to look as though they
> came from their original source and not from the mail server. Is this
> possible with what I'm trying to do, or am I out of luck?

Actually the SNAT rule is just an easy way to make the barracuda's
replies go back to the NATing box (mail server) without using special
routing tricks. But it's fine if you can route the barracuda's replies
to the mail server without SNAT.