static ip source nat and MS Exchange

[Kevin Dorrell]

I have remote access clients (MS Outlook) who are doing ip source nat before coming in to access Exchange 2003. Their NAT is a strictly 1-to-1 host mapping, and works fine at layer 3.

I am seeing some traffic from the Exchange server that is addressed to the pre-NAT addreses of these clients. It took me a long time to work out what was going on, because I had no idea what these addresses represented. I am absolutely sure that the client site is not sourcing these addresses at layer 3, because they would have been blocked by the input access list.

So the pre-NAT IP addresses must be embedded in the higher layer protocols, and not translated by the NAT. Has anyone else seen this, and does anyone know what to do to clean up this traffic?

Kevin Dorrell

Luxembourg

[mchin345]

I didnt face your problem , but you can check up with the access list configuration.Create an access list with port , source and destination must be exactly match your need. Find the ip address which unnecessarly Nated and do trace back to particular ip address and take action.

[Kevin Dorrell]

Mary,

Thanks for the suggestion. It is difficult to explain this problem - it is not an unnecessary NAT. In fact, the clients must be source NATted before they arrive on our site, and that is working. Which makes it surprising that our server is sending packets to their pre-NAT addresses, i.e. adddresses we should know nothing about.

In fact, the incoming access list would already block any traffic from these pre-NAT address, which makes it all the more surprising that we are sending packets to them. The packets we send to those pre-NAT addresses get lost, because we have no route to them, nor should we have. We should never see the pre-NAT addresses, let alone send to them.

As for the source and destination ports, we already track those on a Firewall, so I can already see the ports and traffic patterns, but that is not giving me any clues yet.

All the best for 2005.

Kevin Dorrell

Luxembourg

[paddyxdoyle]

Kevin,

Is there any chance that these clients are already registered at your Exchange site in WINS or DNS by their real IP addresses?

DHCP clients (on w2K +) can be set to use dynamic DNS to update the DNS server with the clients IP to hostname mapping.

The traffic your are seeing could be UDP based? and generated when Exchange sends a new mail notification message to the client, which normally means the client will see an envelope pop up in the sys tray. So the exchange server is creating a new connection to your client and potentially resolving its hostname via your local DNS server.

Rgds

Paddy

[Kevin Dorrell]

Paddy,

Thanks for the suggestions.

The clients belong to another company, so we don't have much control over their network setup - we just allow them access to Exchange on our site. They do the NAT before they come to us because we specify what source addresses they must come in from. But I have seen a copy of their router config, and it is a straight-forward 1-to-1 source NAT mapping.

If the clients are DHCP-based, then it is entirely within their organisation. I don't think they are doing dynamic DNS, at least not to our site anyway - I don't know what they do internally. I did try a reverse lookup of the addresses, and I didn't find any clues on our DNS. Similarly in WINS, but I am going to check again when I get back after the New Year.

I think the traffic is UDP, but I don't remember the ports off the top of my head. (The source port may turn out to be more interresting than the destination port.) I had an idea it might be a certain Exchange add-on that is generating this traffic, but I'm not sure yet how I am going to test that. Again, I'll look this up in the New Year.

Thanks again for the suggestion, and I'll post back next week. All the best for 2005.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

Paddy,

I have had a chance to take a closer look at the pattern of this strange traffic, and you seem to be on the right track with your suggestion that it is something to do with the new mail notification. Some pieces of the puzzle fit and some do not, so please bear with me while I talk these through.

Something I did not mention in my original posting - the Exchange server is running as a virtual server on an MS cluster. These packets, the ones addressed to the pre-NAT addresses of the clients, are all sourced from cluster node addresses rather than the virtual server address. It seems that whatever application is generating them is not cluster-aware. Now I know that parts of Exchange are not cluster-aware, e.g. the SMTP connectors, but I don't know if the new mail notification is cluster aware.

An observation that fits well to your hypothesis: the destination is UDP to a client port that is fixed all day, but changes from day-to-day, and is different for each client. Typical values are in the range about 1080 to about 3999. The source port on the server side is a different high-port for each access, suggesting it may well be the new mail notification.

Where the server is getting the pre-NAT address from? The pre-NAT address does not appear in our DNS, nor in our WINS, and we are not using DHCP. Maybe when Outlook starts up, it tells Exchange (in the application layer) an IP address and port number to send the new mail notifications. In which case, new mail notification can never work through NAT.

Do you happen to know the name of the process on the PC that listens for new mail notifications? What I could do is to observe the traffic, read the destination port, then go to the client and see if I can track down the process listening on that port.

Thanks for your suggestions, and any further thoughts would be welcome. Thanks also for being a sounding-board for my review of the problem.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

Paddy,

Progress. I found this article in the Micro$oft knowledge base:

http://support.microsoft.com/default.aspx?scid=kb;en-us;264035

The best bit about it is:

As part of the log on process to the information store, the client tells the server the IP address and port where it expects to receive new mail notification messages. This will be a UDP port in the 1024-65535 range.

When the server receives a mail message for a mailbox that a client is logged on to, it opens a UDP port dynamically, and sends a packet to the IP address and port registered by the client logged on to that mailbox.

Clearly, the IP address that the client suggests will be the pre-NAT address. So new mail notification cannot possibly work through NAT. I think the hypothsis is very strong, but it does not tell me yet how to fix it. I do not want to route the pre-NAT addresses, because that makes a mockery of using NAT in the first place. Any suggestions?

Kevin Dorrell

Luxembourg

[paddyxdoyle]

Hi Kevin,

I don't think there is a lot you can do in this situation.

Clients can still get their email, as i'm sure you know, they just don't get the new mail message envelope in their sys tray.

In my scenario, i could route to the pre NAT addresses as it was all internal, however, like you, i chose not to and at the time configured the checkpoint firewall to drop and not log UDP packets sourcing from the exchange server to the clients network range. This was purely to keep the logs as clean as poss!

Thanks

Paddy