Hi,
Let's say -- hypothetically -- I have this public IP address:
1.1.1.1 (home)
and I want to run an SMTP server there. However, my ISP filters
SMTP's port 25 to reduce spam from their Windows customers. [Insert
rant about monopolies here.] My goal is to get around the port 25
filtering, and also to see incoming SMTP connections as coming from the
original client's IP address (so I can use greylisting).
I also (hypothetically) have this public IP address at a data
center, where there is no filtering:
2.2.2.2 (data center)
What I would like to do is send all the SMTP traffic to the address
2.2.2.2 (by setting that as my MX record in DNS), but then have iptables
on 2.2.2.2 forward all port 25 traffic to 1.1.1.1 on a high port number
(to get around the port 25 filtering). I'll use 2522 as my high port
number.
I have half of this working in my test lab. The following iptables
command forwards the packets, using NAT. Instead of using NAT the
traditional way, and forwarding to an internal server like 192.168.1.5,
this command forwards the packets to my public "home" ip address 1.1.1.1:
# Command to run on 2.2.2.2:
iptables -t nat -A PREROUTING -p tcp -d 2.2.2.2 --dport 25 -j DNAT
--to-destination 1.1.1.1:2522
You can see that port 25 gets redirected to port 2522 on my home
computer, 1.1.1.1. This part works. 1.1.1.1 sees the incoming packets.
My problem is that the response packets from 1.1.1.1 are being sent
directly to the source IP; that is, all of the ACKs, etc. from 1.1.1.1
(NAT'd to me via 2.2.2.2) go directly to the 3rd party SMTP client that
initiated the connection, instead of being NAT'd back through 2.2.2.2.
Since the 3rd party SMTP client establishes a connection to 2.2.2.2, it
ignores the response packets from 1.1.1.1 because it doesn't know
anything about any connections to 1.1.1.1. (This is generally not a
problem with NAT because internal IPs like 192.168.1.5 use the NAT'ing
box as their default gateway, and thus, the response packets go out from
the correct public IP address.)
I thought I could fix this by rewriting the source address of
packets from 1.1.1.1 to be 2.2.2.2, so that the SMTP clients would see
those response packets as being valid, as part of their established
connection to 2.2.2.2. Here is the command I tried:
# Attempted command on 1.1.1.1:
iptables -t nat -A POSTROUTING -p tcp -j SNAT --to-source 2.2.2.2
I was hoping this would rewrite the outgoing packets to look like
they came from 1.1.1.1, thus allowing the 3rd party SMTP clients to
recognize the packets. Unfortunately, it doesn't work. This SNAT
command only works for NEW connections established by 1.1.1.1. It does
not apply to connections established by the 3rd party SMTP clients.
I also tried this:
# Attempted command on 1.1.1.1:
iptables -t nat -A POSTROUTING -p tcp ! --syn -j SNAT --to-source 2.2.2.2
...to try to tell iptables to apply the rule to non-new connections,
but it didn't work. As far as I can tell, SNAT only works for new
connections. I haven't found a way to arbitrarily munge outgoing
packets for connections established by the other side. (I've tried the
munge and masquerade chains also, with no luck.)
Any suggestions?
Note, I've used an SSH tunnel to forward the packets to 1.1.1.1,
however, the SSH tunnel shows all SMTP connections as coming from the
remote SSH server where the tunnel is listening. That means I can't use
greylisting. I know I could accomplish this by setting up OpenVPN from
1.1.1.1 to the 2.2.2.2 network and using regular NAT, but I don't need
the encryption and I'm trying to do this with just iptables. I can't
use netcat for the same reason; in order to use greylisting, I need the
connections to 1.1.1.1 to be from the original 3rd party SMTP client,
and not from 2.2.2.2 (which would be running netcat or SSH).
Thanks,
Derek
