/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! 
/* ALSO: Don't quote this header. It makes you look lame :-) */


MIS - Ben Murphy wrote:

> Hi All,
> 
> Although the problems described below fall in both categories of
> networking/firewalling & qmail,
> I posted here, in the hope that someone could cast a qmail perspective on
> this, in case there
> is an obvious way around the problem.
> 
> 
> Got an issue with NAT, maybe someone could advise...
> 
> I have two small networks both running Qmail.
> 
> The first...
> 
> ...has a single linux firewall. It has a bunch of ip addresses aliased on
> the outside interface.
> Each of the ip addresses has a service assigned to it, such as qmail-smtp or
> qmail-pop on ports 25 and 110
> respectively, and using ipmasqadm portfw, they are forwarded to the machines
> behind the firewall.
> 
> The qmail box behind the firewall talks to the local dns server on the
> network and generall works fine.
> It receives mail, allows relaying for users etc.
> 
> The second...
> 
> ...has twin RedHat LVS clustering firewall/routers, these provide clustering
> services to the network.
> Again in a similar fashion to the first network, all ip addresses get bound
> to the the current lvs router.
> This then uses ipvs to again forward the packets to the relevant internal
> hosts.
> 
> 
> The problem arises when the qmail box attempts to forward mail to itself.
> It does the dns lookup, and resolves the real internet ip which is bound to
> the firewall or cluster router,
> which is correct. However it is unable to connect to the external ip, as it
> is behind the NAT firewall or cluster router.
> 
> And unfortunately NAT in RH 6.2 (and others) it would appear does not appear
> to allow effectively a NAT'd box to maquerade
> out of the NAT router, and then connect to the NAT router port 25, and then
> forward back internally.
> 
> 
> As such, I need a workaround. Anyone?
> 
> 
> I have thought possibly these would be solutions, but none of them exactly
> nice...
> 
> a) a qmail box outside the nat would do the trick, and have all mail from
> the NAT'd qmail box relay through there.
> b) put a dns server within the NAT'd network, and set all mx records to the
> internal ip.
> c) use the program 'redir' to re-forward the packets back still using
> ipmasqadm portfw as well.... (tried that didn't work)
> 
> 
> Any help would be appreciated.
> 
> 
> Thanks,
> 
> 
> Ben Murphy,
> murphx Innovative Solutions

this is a well known problem. the linux kernel doesn't
support internally initiated port forwarding. one solution
is to setup split zones so internal dns requests for local
names return private ip addresses but external requests return
the public ip addresses. this solution can be implemented
without a reboot. another solution is to apply michael
best's kernel patch that fixes the problem. it can be found
at: http://www.com.org/~michael/masq-demasq.zip

raf

_______________________________________________
Masq maillist  -  [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- 
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]

PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.

Reply via email to