On Sun, 2003-12-28 at 15:05, Drain Fade wrote:
> I setup a NAT firewall that happens to have 2 machines behind it with
> public services (smtp and dns). My problem is that when I do a DNS query
> to my email server behind the NAT I'm unable to connect.
First, do not confuse DNS with SMTP. You don't do a "DNS query" to an
e-mail server, unless that server is also running BIND, djbdns, etc...
In that case, it's not doing a "DNS query to ... email server" it's "do
a DNS query to my nameserver".
There are two parts that could be failing. You could be failing to
lookup the external IP address of your e-mail server (i.e. the IP that
it's NAT'd to), or you could be getting the right IP, but not able to
establish an SMTP connection (you can test this by doing a telnet to
port 25).
Please clarify which of these is not working.
> I can connect to
> the private IP direct which leads me to believe that it's firewall. I know
> that I'll be using the external IP from the DNS query but what should the
> rule look like to redirect queries to my external IP from my LAN ? My
> firewall experience is in transparent bridges so this is all new to me ;)
> Thanks in advance for any feedback.
You need an rdr rules to redirect port 25/tcp from outside to inside
(unless you're using binat, you didn't say which).
Assuming you're NAT'ing all inside IPs to one outside IP, you would use
something like:
rdr on $INET proto tcp from any to $ext_ip port smtp -> $email_server
port smtp
The above makes the following assumptions: $INET is the name of your
external interface; $ext_ip is your Internet IP, "smtp" is defined in
/etc/services on the firewall as port 25, and $email_server is defined
as the private IP address of your email server.
You'll also need a pass rule to allow the traffic through
pass in on $INET proto tcp from any to $email_server port smtp keep
state
By the way, the above is just for SMTP. If the DNS lookup is failing,
then you'll need to add similar rules only the port is "domain" and you
need proto { tcp, udp } because DNS uses both.
HTH.
--
Brian Keefer, CISSP
Senior Field Engineer, Professional Services
CipherTrust Inc, www.CipherTrust.com
