Hi Gordon,
Tks for the reply.
I agree this is a NAT/DNS prob. Tks for the tips - I'll try them but really was
hoping for a courier specific answer.
The issue isn't quite as you expanded upon however - check the logs I originally
included again. Courier initiated the connection to send email. The other
internal box replied with a SYN/ACK and then my courier box reset the
connection! The boxes are talking - just my courier box won't play nicely. I
think the problem is with my courier box and DNS. I wanted to know if there was
a place in Courier that you can configure to overcome the issue of couriertcpd
having a brainfart over already having sent a request to the internal server and
receiving a reply from it but then rejecting it because it checked the IP
address from DNS and its resolving to a different address, and only configure
this in a limited fashion to still maintain security.
Any ideas on this?
Cheers,
Jamie
-----Original Message-----
From: cour...@lists.sourceforge.net
[mailto:cour...@lists.sourceforge.net]On Behalf Of Gordon
Messmer
Sent: 12 August 2003 02:11
Cc: Courier-Users (E-mail)
Subject: Re: [courier-users] Courier behind a NAT FW - no comms with
other internal MX servers
Jamie French wrote:
I've got courier set-up behind a NAT firewall. Things work
well except when
sending email to another internal domain. DNS resolves
this to the external
address of the FW and then couriertcpd rejects the inbound
reply from the
internal mail server.
Sounds like you have a common NAT problem... If any
application looks
up a name in DNS that resolves to the external interface
address on your
NAT firewall, then it's going to send packets to that interface. The
NAT box is going to mangle the packet so that the destination
address is
different, and send it on to the box it's forwarding to. That box is
going to get the packet and reply to the original source, which is in
the local network. Because the reply is going to a machine
in the local
network, it doesn't go through the NAT box, and so it doesn't
have the
source IP that the original SYN was sent to. Hence, the
connection is RST.
You have a number of options:
1: Use "views" in DNS so that your internal network gets a private
number as a response for your DNS lookups, and the rest of the world
gets the NAT box's address.
2: Fix the NAT box by prefixing your MASQ rules with rules
that simply
forward packets if the source and destination are both internal.
3: Use a user space tunnel, like xinetd's redirect feature,
rather than NAT.
4 messages in net.sourceforge.lists.courier-usersRE: [courier-users] Courier behind a ...
