Link to home
Start Free TrialLog in
Avatar of steven_theck
steven_theckFlag for United States of America

asked on

Public Static IP Address Changes for Servers

We just upgraded our block of static IPs from our ISP, meaning changing all of our ANAME and DNS settings. I made all of the changes that I have made before when we switched ISPs, but something is still going wrong. Here is the chain of our network connection:

ISP (CBeyond) > Cisco IAD (hosted locally, controlled by CBeyond) > SonicWall Firewall > Servers, workstations, etc.

The changes to the IAD were made, as well as all of the necessary changes to the SonicWall. I updated all of the ANAMEs on our DNS provider for our internal servers (Doteasy), as well as the DNS settings on our servers. The two servers that we currently have static IPs assigned to are for Exchange 2007 running 2003 R2 and a server running 2008 R1 for other services.

Somewhere within our setup, it appears that the old static IPs are present, and it is preventing certain features to function. If I use a new static IP to access our TS Web App from my web browser, it will point to one of our old IPs. However, I can use RDC to connect to the server using the same new IP address. Also, doing an IP Traceroute for either of these servers will timeout after a few hops, and I cannot ping the servers either.

I apologize if I'm being too vague with descriptions, but I don't know how much information I should give out about our site on these boards.
Avatar of digitap
Flag of United States of America image

is this WAN > LAN access you are indicating is failing? how did you update the sonicwall? i assume you are running the enhanced OS, so did you just update the address objects representing the public IPs used by your servers within the NAT policies and firewall access rules?
Avatar of steven_theck


On the SonicWall, I updated the WAN to have its own static IP address (along with the gateway & subnet changes), changed the DNS server addresses, and changed the One-to-One NATs for the servers being accessed. No changes were made to the firewall access rules, because the public IPs are not used when assigning these services.
did you use the public server wizard initially to setup the access rules and nat policies. i'm thinking the answer here is going to be no.

i'm puzzled by your comment about the firewall access rules. if you allow traffic in through WAN > LAN, then i assume that you used the object Any instead of specifying a public IP tied to your WAN interface, right?
My apologies for not being clearer. The Any object is being used instead of public IPs. The SonicWall is one of the few devices in this network that I did not set up personally, but I do not think the wizard was used to do the initial setup.

A few more problems with our network that has come to my attention:
Using our ERP (Activant Prophet 21), we cannot print, fax, or email from the application. Printing from any other application works with no problem, and email from Outlook works fine. The Prophet 21 software uses a SQL database which is running off a different 2003 R2 server with SQL 2005. I'm not sure if this is in any way related to the other issues, but I figured any extra information could help.
ok...addressing things one at a time and in order, i'd deleted whatever firewall rules and nat policies are currently in place and rune the public server wizard. this will create the necessary nat policies and access rules. additionally, it ensures best practice when creating the access WAN > LAN. i believe that once you do that, things will run smoothly.

ERP issue, i'm not familiar with that app. if it's on the internal subnet, that should not have been affected by the ISP change. is this a server on the internal network? when you say Outlook is working, is this email internal only is functioning or email externally via the Exchange server is functional too?
I will try the SonicWall changes when I get into the office. I'm currently doing everything from a remote location.

All of the servers are on the same internal network, so I agree that there shouldn't have been any issues there, but stranger things have happened. Outlook is working internally and externally. We can send and receive messages within our organization and outside just fine. However at the same time, trying to ping or do a traceroute of our Exchange server's IP address results in timeouts. I will be getting to the location with these servers in about 30-45 minutes, which I will then make the changes to the SonicWall and see if that does anything.

In the meantime (just in case I forgot to make a change elsewhere), is there anywhere other than the DNS role on the server where these static IP addresses need to be changed?
i can't think of any. if you change ISPs, then you may have been using your ISPs DNS servers as fowarders on your internal DNS server. if you are using root hints, then that shouldn't be an issue. is your mail domain the same as your internal active directory domain? are you running SBS? other than the sonicwall, i can't think of anywhere else where your public IPs might make a different internally.

i'm honestly suprised exchange is working. if you're having the issues you are with the sonicwall, then exchange should be broken. did you get a PTR setup with your ISP for reverse dns of your mx record?
Our internal AD domain and our mail domain are different. I made the changes to the forward lookup zone for our mail domain, and the local AD domain is not using any public IPs; only device names and local IP addresses. We are not running SBS.

As for our MX record, we use Trend Micro Hosted Email Security for our email scanning. So our MX record for our ISP did not change, but I did make the change to the IP address within the Trend settings.

I am at the office now and I'm about to make the changes to the SonicWall.
cool...i'm sitting here working on a network diagram so let me know if you run into issues with that.  get a backup of the sonicwall settings first. sonicwall > system > settings.
I made the changes to the SonicWall (model TZ 180), ran the wizard, and now the SonicWall is restarting. However, it has been "restarting" for about 5 minutes now. I don't remember it ever taking this long for it to reboot.
hmm, is the wrench light still lit?
It is flashing
wait a couple more minutes, power off the sonicwall, wait one minute, then power it back on. if you apply power too soon after removing it, you run the risk of resetting to factory defaults.
Alright. It took a little bit to get it all done because we're having some other issues with our ISP, but they're not issues that have to do with this. I just re-entered all of the data into the SonicWall, and our new IP is still being routed to our old IP somewhere. Doing a traceroute of the IP address is giving the same results.
Avatar of digitap
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I'm using to run the traces. To know they are terminating to my old IP, I'm using my iPhone's 3G connection with the IP address of our TS Web Apps server. When entering the new static IP, the address immediately changes to the old IP and doesn't connect any further.
Forgot to address your last statement. I'm on the line with our ISP to check if there are any issues with the IAD right now.
ok...we'll wait to hear what the ISP says.
I'm still on the line with our ISP, but they said there is nothing within the IAD that is causing the issue. It almost appears as if something is still hanging onto the old IP within the TS Web Apps.
if i had the public ip i could help you trobleshoot. i have an account with
My ISP asked me to reboot the IAD (something they did not ask me to do when the IP block was updated), and that seems to have fixed the issue. Everything is connecting externally just fine, and it also resolved the issues with the printing, email, and fax in our ERP. I still have no clue how or why the IAD could have affected printing locally, but all is well. Thank you very much for all of your help!
It turned out that the issue was with our ISPs equipment and the solution led me to solve that problem.
it's always the very last thing you try, but i'm glad you got it. thanks for the points! good luck with the new ISP.