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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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. > > > > > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
