I think this is an arp issue, but I’ve been carvin on
it most of the day to no avail. We relocated out
office and had new ip’s assigned.
We have a Checkpoint firewall running on Widows that
does NAT for several servers. Two of the servers are
OS 10.2 boxes the rest are Windows of various vintage.
The Windows servers are not having issues, but for
instance one Linux box will not accept incoming IMAP
(from the external interface of the firewall), but it
will accept from from the internal side. It will not
accept http traffic from outside, but its okay from
inside.
There is split DNS, dns is working from the server,
you can browse, dig etc and appropriate responses are
received.
I have seen this exact behavior before, but I cannot
recall what I did to fix it… Any ideas that might
clear the fog?
It stinks that email is working fine, but we cannot
access it remotely from iPhones and such due to the
IMAP and HTTP problems.
I would try clearing the arp table on the Checkpoint firewall.
If you continue to have problems you should try running a packet trace on your problematic Linux box with tcpdump.
tcpdump -i eth0 -w packet_trace.pcap -s0
You can view the packet trace file with Wire Shark.
Assuming that nothing changes behind your Checkpoint firewall (it’s literally a forklift re-deployment to the new location), I’ve found that the <only> issue is updating public DNS.
So, in preparation for the office move at least 2 weeks in advance I do the following
Re-configure the DNS TTL to something short, like an hour or so. Excluding apps that ignore TTL like Caching Proxy servers and mail servers, that should ensure no stale records pointing to your old public IP addresses.
Depending on how complex your external interface is (multiple IP addresses, a multitude of services bound to external ports), I often copy all DNS records to be certain I have a copy of the prior setup and methodically plan all DNS changes days in advance of the actual changeover.
I sometimes keep an old Server running the old public IP addresses with re-directs to the new address for a period of time. If the DNS TTL is sufficiently short and well distributed, this temporary re-directing server might be needed only for a few hours but if I didn’t properly prepare then it might run for a few days. Thx almighty that today very “deep” private networks like AOL aren’t so popular, in the old days it might take a week for AOL to fully update.
Test your new public IP addresses by configuring temporary Host file modifications for testing so you’re not affected by any slow DNS updates. If all looks good, then just have patience and soon even your mobile users will connect properly (btw - of course your mobile users who are having problems can also run nslookup to verify their problems are DNS related).
Well there was also the issue that we had to re-ip the network.
In actuality the problem was a simple typo on the firewall which caused
the inbound connection to work but the return replies to fail which acted
as if there was no connection at all. However the firewall activity monitor
told a different story which is how I found the typo.
