Chris Low wrote:
Just got back to work today after a long weekend and ready to try tackling this prob again...
First off, was it okay for me to remove the $ from: INTERN_SERVERS="tcp_$192.168.1.2_smtp_10.10.10.200_smtp" or should I put it back in?
The $ should be left out...you want: INTERN_SERVERS="tcp_192.168.1.2_smtp_10.10.10.200_smtp"
It doesn't sound like you need to update any MX records. You should test external e-mail connectivity (which tests all port-forwarding and masquerading) by attempting to connect to the public IP (208.57.96.252) via the internet (ie not from a local machine).MX records are the DNS entries that tell remote systems how to contact your mail server (as opposed to A records, which match system names to IP addresses). If you don't have an MX record tying your domain name to the IP of your mail server, you won't get mail from the internet at large. Note that this doesn't mean you won't get mail...your MX records could point somewhere else (like your ISP or the registrar for your domain name), and that system could forward mail to you.Do I need to update them with the following setup: Actual mail server address: 208.57.96.252, controlled by the ISP, forwards mail from their server to ours through their router to 192.168.1.2 (what used to be our Exchange server, but is now eth 0 on the firewall)? Since the firewall is set to forward traffic received at port 25 of 192.168.1.2 through to 10.10.10.200 (new ip of our Exchange server) wouldn't it work without having to change the MX records with our ISP? Assuming of course that portforwarding is actually setup and working correctly.
Your routing looks OK. I can't comment on your IP address setup without the output of "ip addr list", although it looks like things are setup OK from some of the details extracted from your ipchains listing.Output from netstat -nr: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
############################################################################################################ Output from ipchains -nvL: Chain input (policy DENY: 0 packets, 0 bytes):
Looks OK, with a rule in place to accept inbound SMTP traffic.
Looks OK, with a reverse masquerade rule required for the SMTP port-forwading to work properly.Chain forward (policy DENY: 0 packets, 0 bytes):
Chain output (policy DENY: 0 packets, 0 bytes):
Looks OK.
Chain fairq (1 references):
Looks OK.
############################################################################################### Output from net ipfilter list:
IPChains rules snipped...see comments above.
Looks like you're setup to port-forward from 192.168.2 to your internal exchange box on 10.10.10.200.AutoFW: Type Prot Low High Vis Hid Where Last CPto CPrt Timer Flags MarkFW: fwmark rediraddr rport pcnt pref PortFW: prot localaddr rediraddr lport rport pcnt pref TCP 192.168.1.2 10.10.10.200 25 25 10 10
Let us know what happens. If memory serves, there could be potential problems with the exchange server setup. If things aren't working, provide the networking setup of the exchange box for reference (IIRC, the output of "route print" and "ipconfig /all", but I think this depends on your windows version).##########################################################################################
You should also verify exchange is properly listening to the 10.10.10.200 address by running "netstat -an". You want to see something like the following:
Proto Local Address Foreign Address State
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
