Port Forwarding for port 25 (again...)

I have a firewall set up with an internal (192.168.1.20) and an external ip-address (x.x.x.49). The former mailserver for this domain has been placed on the LAN, and given the address 192.168.1.101. MX for the domain still points to its old ip-address (x.x.x.34). The firewall is behind the router for the external domain.

I'm can't seem to be able to forward smtp-traffic from x.x.x.34 to 192.168.1.101 via the firewall. I _am_ able to forward port 25 from the firewalls external interface to the mailserver behind, but as mentioned - not from the former ip-address of the mailserver, and to the new internal address.

I have tried numerous versions of:
$IPTABLES -t nat -A PREROUTING -i $INET_NCARD -d x.x.x.34 -p tcp \
--dport 25 -j DNAT --to-destination 192.168.1.101:25

But a telnet to the old, external ip-address of the mailserver just hangs (untill it returns a "No route to host".

Unfortunatly, I have copied parts from various firewall-scripts around the net, but I think I'm understanding most of it now.

Below are different output from iptables -L
I could ask them to change MX to point to the firewall, but I'm hoping to avoid it, if possible.

- M

# iptables -v -L -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere           tcp dpt:http to:192.168.1.101
    0     0 DNAT       tcp  --  eth1   any     anywhere             193.69.71.49       tcp dpt:smtp to:192.168.1.101

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any any 192.168.1.0/24 anywhere
0 0 SNAT all -- any eth0 anywhere anywhere to:193.69.71.49

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

# iptables -v -L FORWARD
Chain FORWARD (policy ACCEPT 259 packets, 16059 bytes)
 pkts bytes target     prot opt in     out     source               destination
  486 29545 bad_tcp_packets tcp -- any any     anywhere       anywhere
    0     0 ACCEPT     tcp  --  eth1   eth0    anywhere             192.168.1.101      state NEW,RELATED,ESTABLISHED tcp dpt:smtp
  325 23403 ACCEPT     all  --  eth0   eth1    anywhere             anywhere
    4   355 LOG        all  --  any    any     anywhere             anywhere           limit: avg 3/min burst 3 LOG level debug prefix `IPT FORWARD packet died: '

# iptables -v -L INPUT
Chain INPUT (policy ACCEPT 6 packets, 759 bytes)
 pkts bytes target     prot opt in     out     source               destination
   99  7212 bad_tcp_packets  tcp  --  any    any     anywhere       anywhere
    2   318 ACCEPT     all  --  eth0   any     192.168.1.0/24       anywhere
    0     0 ACCEPT     all  --  lo     any     localhost.localdomain anywhere
    0     0 ACCEPT     all  --  lo     any     192.168.1.20         anywhere
   19  1444 ACCEPT     all  --  lo     any     x.x.x.49             anywhere
    0     0 ACCEPT     all  --  eth0   any     anywhere             192.168.1.255
    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere           udp spt:bootpc dpt:bootps
  103  7797 ACCEPT     all  --  any    any     anywhere             x.x.x.49            state RELATED,ESTABLISHED
    0     0 tcp_packets  tcp  --  eth1   any     anywhere           anywhere
    2   292 udp_packets  udp  --  eth1   any     anywhere           anywhere
    0     0 icmp_packets  icmp --  eth1   any    anywhere           anywhere
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere           state NEW,ESTABLISHED tcp dpt:smtp
    6   759 LOG        all  --  any    any     anywhere             anywhere           limit: avg 3/min burst 3 LOG level debug prefix `IPT INPUT packet died: '

# iptables -v -L OUTPUT
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   94 13672 bad_tcp_packets  tcp  --  any    any     anywhere       anywhere
    0     0 ACCEPT     all  --  any    any     localhost.localdomain anywhere
    0     0 ACCEPT     all  --  any    any     192.168.1.20         anywhere
  128 16212 ACCEPT     all  --  any    any     x.x.x.49             anywhere
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere           state RELATED,ESTABLISHED tcp spt:smtp
    0     0 LOG        all  --  any    any     anywhere             anywhere           limit: avg 3/min burst 3 LOG level debug prefix `IPT OUTPUT packet died: '

Which sums it up pretty accurately, I suspect. If the firewall has an external IP x.y.z.49, then it will handle traffic to that IP. If the MX (or your telnet test) points to x.y.z.34, then the upstream router will be looking for something that responds to _that_ IP. If it cannot find anything using that IP, then there is no route. Presuming that x.y.z are the same in both cases, you may get the results you want with:

ifconfig eth0:1 add x.y.z.34

Where eth0 would be the interface with x.y.z.49 on it, $INET_NCARD in your rule above. This will create a second 'virtual' interface that responds to this second IP, in addition to the main eth0 responding to the present firewall IP. The interface will still be referred to as eth0 in iptables rules, but it will now handle both IPs. DNAT will be reversed properly, so return traffic will appear to come from x.y.z.34 without further work, but if you need the mailserver to initiate connections that appear to come from that IP then you will need to explicitly SNAT those connections, otherwise it will appear as x.y.z.49 if it makes a new connection.

j

Quoting Joel Newkirk ([email protected]):
[...]

| > But a telnet to the old, external ip-address of the mailserver
| > just hangs (untill it returns a "No route to host".
| 
| Which sums it up pretty accurately, I suspect.  If the firewall has an 
| external IP x.y.z.49, then it will handle traffic to that IP.  If the MX 
| (or your telnet test) points to x.y.z.34, then the upstream router will 
| be looking for something that responds to _that_ IP.  If it cannot find 
| anything using that IP, then there is no route.

Hm... A logical error, in other words. *must* *get* *sleep* *now*... Somehow I thought that the firewall would notice the connection attempt from the router, and would be able to redirect the query from there.

| Presuming that x.y.z 
| are the same in both cases, you may get the results you want with:
| 
| ifconfig eth0:1 add x.y.z.34

I have it working now, thanks to you :)

- M

A handy tool for debugging firewalls is tcpdump.
You can check traffic on all interfaces, or independantly from each other. You may want to check your routing tables too.

HTH,
Willem