Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have inherited an environment where many things don't make sense and I am now in charge of making changes to it and for this I have to understand what the hell is going on before I modify.

Long story short - there is an email server on the LAN and a firewall on the WAN. The WAN IP of the firewall ends in .89. The A record for the email server ends in .90. (The IP pool we have is .89-.93 although only 1 address, .89, is actually plugged in - there is only one line that terminates in the server closet from the ISP).

I am trying to figure out how this is possible. By logic I can conjure, unless the ISP is doing something to redirect traffic from the .90 address (which is not physically plugged in) to the .89 address, nothing addressed to .90 should arrive at .89 - but it does.

I was told by the ISP that they were not doing anything of this kind, but I have run out of other ideas... I only need to know because the IP pool is getting changed (the ISP is switching to a different address pool) and I need to know about all the configuration points to make sure that once the IP change happens, there will be no stale configurations in place and email will flow to the new address correctly after the DNS modification propagates.

Please let me know if there are any other scenarios you can think of that could be happening here. I don't think the firewall could be doing the redirecting when its WAN IP is .89 and therefore shouldn't see any traffic directed to .90, should it?

Thanks in advance,


share|improve this question
Are you sure your firewall doesn't have more than one IP? – Chopper3 Aug 3 '11 at 17:59
There are only 2 ports active on it. One is the WAN port with .98 and the other is a LAN port with the internal IP. The other ports are listed as inactive. Any other place I should check? – Manca Weeks Aug 3 '11 at 18:07
well you don't mention any details about the firewall for us to help you with... – Chopper3 Aug 3 '11 at 18:12
Manca - it seems like you think "one physical RJ-45 plug = 1 IP address". This is not true, at all. – mfinni Aug 3 '11 at 19:26
I do realize that a single connection can provide multiple IPs. I am trying to figure out whether the traffic arriving to the firewall is only through the .89 address and rerouted by the ISP or if the firewall responds on more than one address. On the only active WAN port on the firewall, only the .89 address is configured. – Manca Weeks Aug 3 '11 at 20:50
up vote 0 down vote accepted

The firewall is most likely arping for traffic that is bound to 'things' behind it - it is configured as such. Doing a 'show ip arp' on the ISP's router would most likely indicate .89 and .90 have the same MAC address. Is the mail server on the LAN configured with .90, and if so, what does the internal LAN config on the port look like, and what are the firewall/nat/whatever commands on the firewall like?

share|improve this answer
The mail server only has a LAN (internal) IP. The firewall only has one active port on the WAN and it is set as static ending in .89 – Manca Weeks Aug 3 '11 at 21:07
Found a NAT policy on the firewall. Source - firewalled subnets; translated source .90; original destination .90; translated destination - email server's internal IP; original service - exchange server services, translated service - original. The names of the address objects are mislabeled, but the IPs correspond with the A record in DNS - .90. Still don't know if this policy is in use or not... – Manca Weeks Aug 3 '11 at 21:42
Can you show more of the config? Most likely it is, just with the wrong labels/descriptions. – Aaron Aug 3 '11 at 23:52
What do you need to know, and how would I reveal it? I am pretty sure the policy is in effect or this wouldn't be working, just still don't know whether it is required and what the thinking behind it was. Why not just set the A record to the actual IP of the firewall? – Manca Weeks Aug 3 '11 at 23:59
Because then the traffic would just go to the firewall and the firewall wouldn't handle it any further. The firewall does know the difference between packets arriving at it headed to .89 and arriving at it headed to .90, and it knows to handle them differently. – Aaron Aug 4 '11 at 10:53

Your ISP has configured their routing so that any traffic for your assigned netblock (.89-.93) is sent to .89.

share|improve this answer
Did you miss the statement - "I was told by the ISP that they were not doing anything of this kind,". – Zoredache Aug 3 '11 at 18:18
Nope, but by the awkward wording such as "redirect traffic" and "physically plugging" in ip addresses leads me to suspect the ISP couldn't understand what the person was talking about and didn't need to mention such a basic thing as "routing." – Mark Wagner Aug 3 '11 at 18:27
My exact question to the ISP (the building IT contact - there are enough businesses in the building that the building has their own IP pool) was: The A record for the email server points to .90. Our email server lives on .89. Is there anything about your system that would cause that to work properly even though it shouldn't? Their answer was that the previous IT team was strange and always had routing problems. – Manca Weeks Aug 3 '11 at 20:56
That doesn't preclude the possibility that the "building IT contact" doesn't know what the hell they're talking about. They do get points for recognising the oddities of your predecessor. – womble Aug 3 '11 at 23:01

Maybe your firewall is doing Transparent NAT for that IP? (though that would be pretty unlikely given the setup). Also, could just be simple NAT on the firewall sending the .90 traffic to your mail server.

Or maybe a VLAN over the LAN interface on the firewall that created a DMZ for the mail servers IP?

I'd look at the firewall, I suspect your answer is there.

share|improve this answer

How about the MX record? Is it possible that this one points to a host that instead has an A record of .89? Then everything is fine and you can forget about the A record of the domain.

share|improve this answer
The MX records point to SpamSoap. And their console has the .89 address as the email destination as well. – Manca Weeks Aug 3 '11 at 20:52
The A record for points to .89, the MX records point to 2 SpamSoap hostnames. – Manca Weeks Aug 3 '11 at 20:53

I don't buy that the ISP is not routing a block of addresses that they own to the customer that they've allocated the block to. I would run a tracert from outside the network to each of the ip addresses that you've been allocated and see what path the trace takes.

share|improve this answer
Traceroute returns exactly the same information for each of the IP addresses in our pool. Ends with asterisks, that probably means the firewall or ISP's router discards the packets at that point? – Manca Weeks Aug 3 '11 at 21:08
discards, ignores, or blocks. Can you see if there's a firewall rule denying inbound ICMP traffic and disable it so that you can run tracert again and see if the trace makes it to your firewall? – joeqwerty Aug 3 '11 at 23:03
Didn't see any such rule... I may not be looking in the right place. This is a SonicWall TZ210. I saw ICMP set up as a service but did not see it referenced in any of the Firewall rules... – Manca Weeks Aug 4 '11 at 0:28
There may not be an explicit rule denying inbound ICMP then, it may be an implicit rule. You may need to define an inbound ICMP Allow rule in order for tracert to work. It may also be an option somewhere so there may be a simple checkbox to enable or disable inbound ICMP traffic. – joeqwerty Aug 4 '11 at 2:52
OK - will take a look. I did see several rules explicitly allowing traffic so the possibility of having to explicitly allow certain traffic did occur to me. – Manca Weeks Aug 4 '11 at 20:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.