You Cannot Control the Source IP Address on the External Interface of the ISA Server
You Cannot Control the Source IP Address on the External Interface of the ISA Server
By Thomas W Shinder, M.D.
It's time for yours truly to eat some crow . Why? Because of an error I’ve made repeatedly over the last year or so. Each time a question came up regarding this subject, I would report the same false solution. The solution I thought should work in fact does not work. Its time to correct that error.
What was the error? It has to do with the problem of binding a specific IP address on the external interface of the ISA Server to a specific server on the internal network. As you know, when you publish a Server on the internal network using a Server Publishing Rule, both an internal and external IP address is used to create the Rule. The internal address is the address of the internal network server that’s being published, and the external address is the address on the external interface of the ISA Server that will receive requests for the published server.
So far, so good. But problems crop up with outbound messages. For example, suppose I want to publish an Exchange 2000 Server on the internal network. The IP address of the Exchange Server is 192.168.1.1. The ISA Server has several IP addresses bound to its external interface. These are 188.8.131.52, 184.108.40.206 and 220.127.116.11 from top to bottom. You use IP address 18.104.22.168 in your Server Publishing Rule.
External network SMTP clients can send mail to 22.214.171.124 on the ISA Server and the ISA Server forwards that mail to the internal network Exchange Server SMTP service. Now, what happens when the Exchange Server on the internal network needs to send outbound mail? What IP address will be used as the source IP address in the outbound message as it leaves the ISA Server external interface and goes to the destination SMTP server?
The primary IP address bound to the external interface of the ISA Server is always used. That’s right, its always used and there’s nothing you can do about it! That’s where I’ve made my mistake. I'd assumed we could leverage the settings in the wspcfg.ini file to bind a particular IP address on the external interface of the ISA Server so that IP address would be used to receive mail for a specific internal network’s SMTP service and that IP address would also be used as the source IP address on outbound messages from that same internal network SMTP server.
This is an important issue because many benighted network admins will use reverse lookups on their SMTP servers as a very crude and ineffective method of spam control. This can be a problem for you if you have SMTP servers behind the ISA Server. For example, suppose you have three SMTP Servers listening on:
Those servers go by the names
Mail for mail domains mydomain.com, mystuff.com and yourstuff.com is sent to the appropriate address on the external interface of the ISA Server.
What happens when mail is send out? The source IP address will always be the primary address -- 126.96.36.199 which resolves to mail.mydomain.com. This is going to be a real problem if the mystuff.com or the yourstuff.com servers on the internal network need to send outbound mail. The server name will be from one domain the source IP address in the outbound message will resolve to another domain. The reverse lookup will fail and your very legitimate, non-spam messages get rejected.
The best solution to this problem is to get all mail admins to turn off reverse lookup on their SMTP servers, as it’s a waste of electricity and processor cycles. But you’re never going to get that to happen because there are a lot of "true believers" in this form of spam whacking. Hey! At least it’s better than sleazy services like SpamCop, but that’s a story for another time.
The solution I thought would work involved using a wspcfg.ini file to bind an IP address on the external interface of the ISA Server to an SMTP server on the internal network. This would take care of both the Server Publishing Rule and fix a specific address to the external interface of the ISA Server to the particular server on the internal network and thus allow me to control what IP address is used for the source address on outbound packets. I used procedures very similar to those described with publishing an FTP server using a wspcfg.ini file (http://www.isaserver.org/pages/article.asp?id=196)
Unfortunately, it doesn’t work. Let’s begin with the diagram below:
There are four servers:
The External Exchange Server. This server will accept mail send outbound from the internal network SMTP Server.
The Domain Controller. All servers on network ID 10.0.0.0/24 belong to the same domain. The ISA Server, the SMTP Server and the Domain Controller belong to the same domain. The domain controller is configured as a SecureNAT client. Outlook Express is on the domain controller and we’ll use it as the mail client in our tests.
The SMTP Server
. The SMTP server is configured as a Firewall client and a wspcfg.ini is placed in the same directory as the inetinfo.exe file. That’s the application responsible for the IIS SMTP service, and the wspcfg.ini file needs to be placed in the same directory as the application responsible for the service you’re trying to control by using that file. The SMTP Server is a Firewall client only. There is no default gateway configured on the this machine.
The ISA Server
. The ISA Server has two interfaces (internal and external) and an "all open" Site and Content and Protocol Rule is configured on the ISA Server. No Publishing Rules are configured on the ISA Server since the wspcfg.ini file takes the job of the Publishing Rule. The ISA Server has two IP addresses bound to its external interface:
The 192.168.1.33 address is primary. You can tell that its primary because its on top of the list of addresses as seen in the figure below.
The figure below shows the contents of the wspcfg.ini file placed on the SMTP Server. These settings bind TCP port 25 on IP address 192.168.1.34 on the external interface of the ISA Server to the SMTP server on the internal network. This setting is supposed to allow us to match all of our goals:
- Publishing the SMTP server on 192.168.1.34 and
- Have 192.168.1.34 as the source address for outgoing packets from this server.
Adverse Side-Effects of the Wspcfg.ini Publishing Configuration
What is a side effect of making the SMTP server a Firewall client and configuring these settings in the wspcfg.ini file? The first thing I noticed is that you cannot configure the SMTP service to listen on a particular address on the internal network. The SMTP service must be configured to listen on all IP addresses. This isn’t a big deal, but its something that might catch you off guard if you’re in the habit of configuring SMTP servers to use a particular IP address.
The next problem was much more disturbing. When I configured the Outlook Express email client on the Domain Controller to use the SMTP service on the SMTP Server for outbound mail, I received error messages. Outlook Express notified me that it could not communicate with TCP port 25 at IP address 10.0.0.3, which is the IP address of the SMTP server on the internal network. What’s up with that?
I tested the connection using Telnet. You can see the results of my telnet session directly to the internal SMTP server in the figure below. The failed telnet session confirmed what was seen when Outlook Expressed failed to connected to the SMTP service. I tried it from the ISA Server and even tried to telnet from the SMTP server itself! None of the attempts worked.
The next step is to see if its possible to Telnet from an external network client. First I did a netstat –na to make sure the ISA Server was listening for requests on the right port and IP address. I made sure the SMTP service on the ISA Server was disabled (you should always disable all IIS services on the ISA Server). I ran the netstat command with the find to speed up my search for TCP 25. The wspcfg.ini file is indeed working, as you can confirm in the figure below.
Now that the port is confirmed to be open for business, I telnetted into the internal SMTP server from an external client, as seen in the figure below. I was also able to send mail from an external SMTP server, so I know the wspcfg.ini configuration worked to publish this server. Note that the name of the SMTP server on the internal network is included in the banner (blah.internal.net).
So there’s no way to directly communicate with the SMTP service on the internal network SMTP server, but we can reach it by going through the external interface of the ISA Server after its been published using the wspcfg.ini file. I configured Outlook Express to loop back through the external interface of the ISA Server to send SMTP mail to the internal network SMTP Server and it worked fine.
Let’s look at the path for the mail with our current configuration:
Yes, I know that looping back through the external interface of the ISA Server is usually a bad thing, but the publishing server is a Firewall client, so that changes the rules a bit. When the publishing server is a Firewall client, you don’t have the same problems you do when both the requesting host and the responding server are SecureNAT clients. I’ll include a bunch of information on this situation in the ISA Server and Beyond book, but take my word for it right now that this configuration is technically "good".
Mail is sent by Outlook Express on the domain controller to the IP address 192.168.1.34 on the external interface of the ISA Server . The ISA Server forwards the mail to the internal network SMTP server (because of the wspcfg.ini file on the SMTP server). The SMTP server is configured with a Smart Host and forwards the mail directly to the Exchange/SMTP service on an external network location .
So what happens? Check this out:
The taca-1.august.net mail server is the Exchange/SMTP server on the external network. Note this line:
Received from blah.internal.net ([192.168.1.33]) by taca-1.august.net with Microsoft SMTPSVC (5.0.2195.2966)
This indicates that internal network SMTP server (which has the name blah.internal.net) is being identified by the primary IP address of the external interface of the ISA Server and not the IP address we configured in our wspcfg.ini file. I also checked this out with Network Monitor on the Exchange Server/SMTP server and confirmed that the source IP address is the external interface of the ISA Server.
What’s sort of interesting is that the 192.168.1.34 address used by the internal network SMTP server does show up in the email header. Check out this line:
Received: from SMTP ([192.168.1.34]) by blah.internal.net with Microsoft SMTPSVC(5.0.2195.2966)
What's going on here? What it’s saying is that blah.internal.net received the message from SMTP. Now, SMTP is indicated as the IP address used by the internal network server for the Server Publishing configuration. So, 192.168.1.34 received the message, sent it to the internal network server, and then the internal network server is identified as the primary IP address on the external interface of the ISA Server!
It was fun to work with the wspcfg.ini file to publish the SMTP server on the internal network, but it was disappointing to find out it did not work to bind the IP address so that it would be used as the source address for outgoing packet from the internal network SMTP server. The most instructive part of this exercise was discovering that you had to access the service published by the wspcfg.ini file via the external interface address on the ISA Server.
From all I can tell, it is impossible to control what IP address on the external interface of the ISA is used as the source address for specific servers on the internal network. It would be a nice feature to be able to have this kind of control, if only to help with SMTP servers on the internal network.
One thing I have noticed is that when you have a VPN Server installed on the ISA Server, some strange things can happen with the source IP address for outbound requests. Sometimes a secondary IP address on the external interface of the ISA Server will show up as the source address for internal network client outbound requests. Why? You guess is as good as mine. But I’ve only noticed this on ISA/VPN Server will multiple addresses bound to the external interface. I have not seen this happen on ISA Servers that are not VPN servers.
If you have a solution to this problem, let me know! I’m more than willing to be wrong again. I encourage you to test this configuration and come up with an answer. If you write up your results, I’ll publish your article. If you want me to write the article, we can co-author it! Whatever works for you – I would just like to see if I’ve messed something.
Write to me at [email protected] for more information and questions on this article. If you have an answer to this problem, write to me at [email protected] and I’ll give your message top priority! Thanks!!! –Tom.