Exchange SMTP routing

epssupport
epssupport used Ask the Experts™
on
I have a problem with routing SMTP traffic to my exchange server. We are moving from a software firewall setup to a hardware firewall.

Current Setup:
We use Symanted Hosted Mail Security to filter our mail.
We currently have 3 internet lines, 2 ADSL and 1 SDSL. All have diffferent modems, all can send SMTP traffic to the software firewall.
The software firewall routes SMTP traffic sent from Symantec to our exchange server using NAT.

I can telnet port 25 from my home PC to to the outside address of any of the modems, and I get a response from my exchange server.

New setup:
We are switching to a SonicWALL NSA 2400. I have setup the device and I can VPN successfully to the device.

Problem:
I do not seem to be able to get a telnet response from the exchange server when I add the mail rules to the SonicWALL.

What I've tried so far:
I have contacted the ISP i am using for testing the device and checked that no SMTP blocking is active.
I have setup a different service (Terminal Services) on the sonicwall to check that fraffic does get routed ok. Had no problems routing to the terminal server using the same setup wizard that does the mail rules. (just different service and destination in firewall/NAT)
Had an expert in sonicwall checkout the rules and setup of the sonicwall. He says it's OK.
All firmwares are latest versions on Modems, SonicWall and NIC.
Checked to make sure Perimeter IP setting are not being used in exchange (they are not, list is empty)

What works:
I can telnet from the local LAN to exhange from any server or workstation.
SMTP traffic is reaching exchange from Symantec server (Via software firewall).
If I add an external IP to the inbound rule in the Software firewall SMTP rule, that IP address can telnet exchange.

Help:
Is there something obvious I am missing here?
Can you give me any suggestions that might enable me to get mail services through my nice shiny new hardware (and not inexpensive) firewall.

Please let me know what additional information you need to help you help me.

Thanks,

Simon.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Expert of the Quarter 2009
Expert of the Year 2009

Commented:
The default gateway on the Exchange server needs to be pointing at the new firewall for any traffic to go back. If it is not then you will not get a response back, as the server will be trying to push the traffic back to the existing default gateway.

Windows doesn't cope well with multiple default gateways.

Simon.

Author

Commented:
I have tried pointing the default gateway at the SonicWALL.
That didn't make any difference.

Interestingly, we are currently usuing 2 software firewalls at the moment on different servers.
Obviously, the excahnge server can only be pointing to one of them as a default gateway. However, it doesn't matter which firewall I connect through, both allow me access to the exchange server.
Expert of the Quarter 2009
Expert of the Year 2009

Commented:
If you have two firewalls then the behaviour you are seeing should not be happening.
Windows can really only cope with one default gateway and that is where the traffic originates from. If you have multiple connections then those should be terminated on a single router so the router can do what it does - route traffic. Windows is a very poor router.

There has to be something else going on, maybe something was done with the network configuration on the machine to make the server work with two different firewalls.

Simon.
Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
Hi,
No, there is no special configuration on the exchange server for routing to multiple gateways.
The two firewalls are aware of each other. Maybe the routing setup between the firewalls allows the traffic to be routed correctly when traffic from the non-gateway firewall is recieved by exchange. Not sure, All I can tell you is it works with no special setup in exchange.

This just brings be back to "what do I need to check for the sonicwall to work" question?

I'm still stuck on why my software firewalls work and the hardware firewall doesn't.
Is there anything else in exchange I should be looking at?

Thanks again,

Simon.
Expert of the Quarter 2009
Expert of the Year 2009
Commented:
I can't answer questions on the sonicwall as I have never even seen one.
However the point i was making was that in my experience, you cannot expect Exchange to respond to traffic coming from two different firewalls because of the default gateway issue.
If the server is indeed responding to two different gateways then either there is something in between them that means the traffic appears to be coming from the same place, or the routing has been changed on the server to allow it to work, although it would be very complex to get it to work reliably.

From a firewall point of view - any firewall - all you need is port 25 open for SMTP traffic to flow. You should be able to telnet to port 25 and get a response. If you are not then the usual reason is that the default gateway is not pointing to the correct IP address. Nothing has to be changed on Exchange. I have dual connections on my own network and if I want to change which path the traffic goes out on, I switch the default gateway - nothing more. However I cannot receive email to the same server from both connections, I have to use a second server to receive the email then deliver it internally.

Your original network configuration is unusual, which means that something unusual was done to get it to work - or there is additional information that either a) you haven't said or b) don't know about.

Simon.

Author

Commented:
Thanks you very much for clarifying what I already knew.
I really thought that exchange needed something changing.
Turns out that for whatever reason, Windows 7 Telnet was the problem.
All along it seems that when i've been changing the configuration for testing, i've been testing with Windows 7 command prompt and telnet.

After your comments today, I tried connecting through a remote Windows Server 2003. Works fine.
Next I downloaded a Telnet GUI for my Windows 7. Guess what; also works fine.

Moral of this story. Don't use Beta software for testing your customer setup.

Many thanks again Simon (Mestha)

Regards,

Simon.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial