Forward Ipset and Clear DNAT entry

Hi all,

I have a 2 part question. The first is how to do something, the second is how do I clear up my failed attempts to accomplish the first.

I would like to be able to forward an ipset tied to certain ports to a different machine. I know how to create an IPSet and bind that set to certain ports-- I would like to be able to forward that set to another machine instead of doing a straight reject. My aim in the testing is to have a machine I can ssh to, from which I can mail, and then later verify that the mail sent to my firewall gets routed properly.

To this end I created a set and a corresponding table-- dischash and DISCHASH

ipset -N disc nethash
ipset -A dischash xxx.xxx.xxx.xxx/xx
ipset -N discports portmap --from 1 --to 1024 ipset -A discports 25
ipset -B dischash :default: -b discports
(Here I am not clear if I need the table, but
created it anyway)
iptables -N DISCHASH
(With a straight LTREJECT I would create a
FORWARD and INPUT, but here, I'm not sure)
(Then I did this:)
iptables -t nat -A PREROUTING -m set --set dischash dst -j DNAT --to-destination --to yyy.yyy.yyy.yyy

Now, I can't ssh to the machine in the set, my ssh (verified by a traceroute) fails to yyy.yyy.yyy.yyy-- which is what I would expect if I didn't have the ipset bound to port 25. I tried several iterations of this last command (verifying my insanity) and now when I do:

iptables -L -t nat
I get entries at the end reading:
DNAT all -- anywhere anywhere
set dischash dst to:xxx.xxx.xxx.xxx

So,
Is there syntax to clear single DNAT entries without flushing ALL prerouting?

And is there syntax which will allow me to reroute traffic from a particular ipset going only to bound ports (i.e. mail) to a second address?

Thanks very much for any help.

Rob Carlson

Hi Rob,

I'm not completely sure I understand what you want to achieve, but anyway...

You mean the DISCHASH chain? As you don't use it, the chain is unnecessary.

The ipset is bound to the port, but you did not instruct the set matching to follow the bindings up to the level you want. You should have typed

iptables -t nat -A PREROUTING -m set --set \
dischash dst,dst -j DNAT --to-destination --to yyy.yyy.yyy.yyy

           ^^^^^^^

i.e instruct the set matching to follow one level of bindings and at that level apply destination matching. Without this, the set matching checked the dischash set alone and the NAT rule was applied according to the result.

You can delete any rule anytime. However, you cannot change the NAT-related parameters of the living connections known by conntrack. They must die out (or you can kill the corresponding conntrack entry by the new 'conntrack' tool.)

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics

          H-1525 Budapest 114, POB. 49, Hungary

Jozsef and group--

Jozsef Kadlecsik wrote:
<snip>

<snip>

The idea is (in the long term) to be able to send port 25 traffic from hotmail to a test mail server, where the spam could be discarded and we could forward legitimate mail that comes from clients who still use hotmail... Since 95% of hotmail is trash, it would make our populace here happy.

In the short term (in order to test our postfix/procmail configuration) I want to be able to ssh to my home machine and mail to myself at work (with the hope that the mail will be routed AWAY from our primary mailserver to the test mail server).

Here is where I stand now:

ipset -N disc nethash
ipset -A dischash xxx.xxx.xxx.xxx/xx
ipset -N discports portmap --from 1 --to 1024
ipset -A discports 25
ipset -B dischash :default: -b discports
<snip>

(I typed the following)

iptables -t nat -A PREROUTING -m set --set \

That didn't take, mail still goes to the main server, so I figured the cause was an existing PREROUTING chain forwarding to the primary mail server, so I inserted the chain at the beginning:

iptables -t nat -I PREROUTING -m set --set \
dischash dst,dst -j DNAT --to-destination
-yyy.yyy.yyy.yyy

So, I'm right now, I can ssh to my home machine, but any mail I send still goes to the primary server.

iptables output:

root@firewall:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source      destination
DNAT     all  --  anywhere     anywhere    set dischash dst,dst to:yyy.yyy.yyy.yyy

----
DNAT tcp -- anywhere anywhere tcp dpt:smtp to:yyy.yyyy.yyy.xxx:25

(where yyy.yyyy.yyy.xxx is the primary mail server)

and then many more entries, that all route properly...

Thanks for the help so far and any more...

Rob

Hmmm, I probably don't agree with this approach to the problem. Therefore most or all of this will be off-topic.

How did you identify the hotmail IP addresses? Their SPF? "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" I won't try to chase down all those includes.

When you say "procmail" I think you are going about this the wrong way. For spam reduction in Postfix, see here:
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
and the various README files, especially
http://www.postfix.org/SMTPD_ACCESS_README.html .
I also like greylisting at least for unknown clients and hosts which appear to be dynamic. sqlgrey has a good regex for identifying likely dynamic clients, which in most cases turn out to be Windows zombies.

You could use Postfix restriction classes and handle the mail from Hotmail differently within the same Postfix instance, too. While there is plenty of spam and abuse emanating from Hotmail.com clients, the *vast majority* of so-called "hotmail" spam comes from elsewhere:
Windows zombies pretending to send from hotmail users. The proper way to deal with that would be the from_freemail_hosts class described in the aforelinked Cheat Sheet.

How are you submitting this mail? You are not hotmail.com, I bet.

If your IP is in the set but you use a client which calls sendmail(1) for submission, you are not going to hit your port 25, thus no DNAT will take place. Also if this machine is the one you're DNAT'ing, you need your DNAT rules in OUTPUT, not PREROUTING.

Whew, at least THAT part of it was on topic. :)

    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header