IPTables redirect back to internal IP

[adcburke]

Hi,

I have a gateway acting as the firewall for my network and i am trying to do somethign that seems simple but i cannot seem to work it out.

Behind our firewall is a outlook web access server. from the internet it is accessed by dns name webmail.xxx.xxx and points to a virtual ip 141.xxx on the external Nic.

However if you are connected to the internal network and try to access webmail.xxx or 141.xxx it fails

Is there some obvious rule to allow internal clients to access a port hosted on an external ip.

Cheers


IPTABLES FILE if that helps (eth0 is the external interface)

# Generated by iptables-save v1.4.12 on Mon Aug 13 15:09:41 2012
*nat
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
REROUTING ACCEPT [0:0]
OSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A PREROUTING -p tcp -m tcp -i eth0 --dport 443 -j DNAT --to-destination 192.168.1.250:443
-A PREROUTING -p tcp -m tcp -i eth0 --dport 993 -j DNAT --to-destination 192.168.1.250:993
-A PREROUTING -p tcp -m tcp -i eth0 --dport 25 -j DNAT --to-destination 192.168.1.250:25
-A PREROUTING -p tcp -m tcp -i eth0 --dport 26 -j DNAT --to-destination 192.168.1.250:25
-A PREROUTING -p tcp -m tcp -i eth0 --dport 587 -j DNAT --to-destination 192.168.1.250:587
-A PREROUTING -p tcp -m tcp -i eth0 --dport 1723 -j DNAT --to-destination 192.168.1.28:1723
-A PREROUTING -p gre -i eth0 -j DNAT --to-destination 192.168.1.28

# Completed on Mon Aug 13 15:09:41 2012
# Generated by iptables-save v1.4.12 on Mon Aug 13 15:09:41 2012
*mangle
REROUTING ACCEPT [13:1873]
:INPUT ACCEPT [13:1873]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11:2369]
OSTROUTING ACCEPT [11:2369]
COMMIT
# Completed on Mon Aug 13 15:09:41 2012
# Generated by iptables-save v1.4.12 on Mon Aug 13 15:09:41 2012
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -m state -i eth0 -o eth1 --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp -i eth1 --dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp -i eth1 --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp -i eth1 --dport 53 -j ACCEPT
-A INPUT -p udp -m udp -i eth1 --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp -i eth1 --dport 80 -j ACCEPT
-A INPUT -p icmp -m icmp -i eth1 --icmp-type any -j ACCEPT
-A INPUT -p tcp -m tcp -i eth1 --dport 3128 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 443 -j ACCEPT
-A INPUT -p icmp -m icmp -d 141.xx -i eth0 --icmp-type any -j ACCEPT
-A INPUT -p icmp -m icmp -d 141.xx -i eth0 --icmp-type any -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 993 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 26 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 25 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 1723 -j ACCEPT
-A FORWARD -p tcp -m tcp -i eth0 --dport 80 -j ACCEPT
-A FORWARD -p gre -i eth0 -j ACCEPT
COMMIT
# Completed on Mon Aug 13 15:09:41 2012

[darkod]

Not all routers can send the connection back to your LAN once it goes out. That's why using a public IP or public domain record is not always possible.

For machines on the internal LAN, you can use the private IP of the server to open the webmail.

Another option is to make a host webmail.xxx.xxx with the private IP of the server in the hosts file on each machine. Or if you are using your own DNS server on the LAN which is primary for the workstations, create the entry there and when they type webmail.xxx.xxx on the workstation your DNS will resolve that to the private IP of the server and send the request there.

[adcburke]

Thanks for the reply

I had thought of the internal dns for the 'static' internal clients, unfortunatly we also have some sales reps that float in and out and need to be able to use the webmail. I cannot change the ttl of the external dns record so if their laptop uses a cached record it will fail.

Frustrating as my cheapy old netgear router will do it by default..

[darkod]

In that case I think using dnsmasq as a simple DNS for the internal network will solve it for you.

The steps are easy and here is a short description from the debian wiki:
http://wiki.debian.org/HowTo/dnsmasq

Basically the idea would be:
1. On your ubuntu server install dnsmasq unless already instaled (I think 12.04 comes with dnsmasq).
2. Choose dnsmasq only to listen to the internal interface as explained in that link.
3. Open the /etc/hosts on the server and create the entry, something like:
webmail.xxx.xxx 192.168.x.x

(this is very cool in dnsmasq that I only recently learned on this forum, it will check the local /etc/hosts file before anything else)
4. On your DHCP server set to send to the clients the internal server IP as primary DNS, and the router IP or some public DNS as a secondary DNS.

That way inside the office they use your internal server as DNS (dnsmasq) and outside they use public DNS servers that resolve your public webmail.xxx.xxx to your server.

I hope this explanation doesn't sound too complicated. Does it look like it can help you?

[SeijiSensei]

I cannot change the ttl of the external dns record so if their laptop uses a cached record it will fail.

Setting a short TTL is clearly the best solution. Why can you not change it? Is it somehow restricted by the hosting provider, or do you not have sufficient rank in your organization?

How many external IP addresses do you have? If your ISP gave you a six- or fourteen-host subnet, you might be able to put the server on a different external address from the router and still connect to it from inside. The router might not like redirecting traffic to its own external IP but have no problem sending it to another external IP in the same subnet. If you don't want to put the server outside the firewall, you could stick an old box out there running Linux with an OpenVPN tunnel back to the mail server.

[adcburke]

Setting a short TTL is clearly the best solution. Why can you not change it? Is it somehow restricted by the hosting provider, or do you not have sufficient rank in your organization?

How many external IP addresses do you have? If your ISP gave you a six- or fourteen-host subnet, you might be able to put the server on a different external address from the router and still connect to it from inside. The router might not like redirecting traffic to its own external IP but have no problem sending it to another external IP in the same subnet. If you don't want to put the server outside the firewall, you could stick an old box out there running Linux with an OpenVPN tunnel back to the mail server.

Unfortunately the TTL is set by our isp and they wont let me change it.

I have 4 external ip's but setting the target ip to be different to the outgoing IP seems to make no difference. (outgoing x.x.x.74, incoming x.x.x.78)

I am stunned this is seemingly so complicated

[darkod]

What didn't you like about my idea?

Set up a simple local DNS with dnsmasq for example, and for clients inside your network it will resolve webmail.xxx.xxx to the local IP.

For clients outside your network, they will not use the local DNS (since they are out of the office), they will use some global DNS which will resolve webmail.xxx.xxx to the public IP.

[adcburke]

Aha!, think i have it cracked.

By putting in a prerouting rule that does a dnat to the actual server internal ip and port it seems to work (well for port 443 anyway)

So heres the details

default outgoing ip of router x.x.x.74
IP of incoming requests: x.x.x.78
Interface: eth0

IP of server 192.168.100.250 (on a virtual lan but i don't think that makes a difference) Listening on port 443 (ssl)
interface: eth1


Rule in iptables

-A PREROUTING -p tcp -m tcp -d x.x.x.78 -i eth1 --dport 443 -j DNAT --to-destination 192.168.100.250:443

Basically saying if destination is x.78 port 443 AND only on internal interface (eth1) then DNAT to the internal ip of the server. I do think this might only work though if you have the server on a different subnet though. not too difficult can just use a virtual interface and a couple of rules to allow routing.
(I know most reading it here will understand but I thought I would explain it in the way us none Linux geniuses would understand)

Cheers Guys

[adcburke]

Sorry darkod forgot to reply, i tried the dns route and it worked fine for most but not for our roaming sales reps.

for example, a sales rep in the morning say picks up his email at home, the dns record is cached with the long unchangeable ttl time in his local dns cache.
hour or so later he comes into the office and connects to our wireless network, goes to get his email again and his computer tries to connect to the record stored in his cache, this leads to a failed connection as it is still trying to get the the outside IP. At that point you or I would flush the dns cache and try again, thus picking up the internal dns record. But trying to get a sales rep to do that every time he comes in will just end up in numerous calls, entailing "my email isnt working".."have you run that flush dns command".."oh no i forgot, what was it again"..

If i could change the ttl that would be the perfect solution but i cannot as our isp are rubbish.

[SeijiSensei]

I'd consider bringing your DNS server in house if you have such an unprofessional and uncooperative provider.