Current suspect is the Watchguard Firewall. Most likely I am to blame as the person who edited the firewall rules.
At a recent point in the past my company was on a different external IP address. I switched providers and thus changed external IPs. Prior to the change I could ping from the mailserver and get the responses without fail.
When I changed the firewall the only changes I made were to rules that specifically mentioned an external address. The physical connections for the internal network didn't change. The structure of the firewall rules didn't change (or so I thought).
After changing the firewall and plugging into the new T1s I don't receive ping replies from 192.168.0.4 which is the mailserver's internal address. I noticed that outgoing mail was queuing up. Eventually I setup a second network interface on 192.168.0.25 and as soon as I enabled that interface all outgoing mail left the queues and ping responses came back to the mailserver.
The new external IP addresses were listed on one of SORBS lists. I got an exclusion from the blacklist through an automated form for the individual external address of the mailserver. I found that getting the exclusion worked for some configurations but some recipient servers would still track the packet back to the firewall address which is still on the blacklist.
I've found now that if I change the firewall rule to allow SMTP out from 192.168.0.4 instead of using the "filtered SMTP" rule that worked previously my outgoing mail is seen on the excluded external address and the recipient servers that use SORBS don't block the mail.
Given that mail from 192.168.x.4 is what I'm allowing out on the external IP that isn't blacklisted I disabled the interface related to 192.168.0.25.
Mail works now but ping replies are lost. Watching the firewall logs shows the outgoing ping as allowed and any IP in the 192.168.0.* range other than 192.168.0.4 receives the ping responses.
Enabling the 192.168.0.25 interface ends up with pings working but mail being blacklisted by SORBS users. I can just enable it temporarily to ping and then disable it again but I'd rather solve the issue than just work around it all the time.
Edit: To be clear the only issue I need help with is why Ping replies don't make it back to 192.168.0.4 or why the server is dropping those responses. I do not need help with the SORBS or general mailserver issues. All issues relating to mail were resolved in the past I'm just looking for a solution to being able to ping from that server to an external address as needed.
Example behaviour:
C:\>ping www.google.com
Pinging www.l.google.com [74.125.65.147] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Expected behaviour:
C:\>ping www.google.com
Pinging www.l.google.com [74.125.65.99] with 32 bytes of data:
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Ping statistics for 74.125.65.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 22ms, Average = 22ms
I haven't gotten a chance to sniff the packets but I did notice this
Routes:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.199 - 255.255.255.255 !H 0 - 0 -
192.168.0.200 - 255.255.255.255 !H 0 - 668 -
The PC at IP 0.200 couldn't browse the web, get windows updates, or ping. I changed it's IP and now it can. I'm not sure how to clear these entries or why they were added in the first place. I don't see a similar route statement blocking traffic to/from 0.4
OK, I used NTOP to monitor the pings going to and from and I get this
296 bytes sent 0 bytes received 4 echo requests sent / 0 echo replies received.
I guess that means it's a firewall issue.
Did you check the NAT configuration on the firewall to account for the new ip addresses? It sounds like a NAT or an ARP issue to me. Look at the NAT rules and the ARP table on the firewall and see if there's an entry that corresponds to the MAC address of the NIC in the server with the .4 ip address.
74.125.65.99 is a Google IP according to whois. So this is not a DNS problem.
Are you sure you have proper NAT rules configured on your gateway/firewall? It may not be translating the ping requests from the mailserver.