Official USAF websites are blocked on the NIPR


If you are experiencing this, we received a fix from Mr. Rob Walls at Hill AFB and Mr. Kevin Pope at Tinker AFB that we’d like to share with you.


Their contact info is included below in case you have questions or need assistance.



The cause seems to be that AFPW public sites use "" but don't really live in's domain (they are not local sites). Basename is of course the real base name for any particular base.


Browsers are set up to NOT send requests to local sites out through the base's proxy server for several good reasons; it breaks integrated windows authentication and it places unnecessary load on the proxy servers. Up until a few months ago (ever since was migrated to AFPW) , this situation was handled by giving a local internal IP address so the browser "thinks" it's going to a local address. That local IP address points to the internal interface of the base boundary which had a rule to forward (proxy) requests out to the real IP address of That way we could "except" "*" names from using the proxy while still allowing to go through the proxy using that "spoofed" local IP address and firewall rule. This was all implemented way back when we had full control over our network, so this may have been a unique solution and may not apply to other bases.


Well, (again in Hill's case at least) the firewall rule that did the forwarding was removed by the NOSC about three months ago apparently to standardize rules as we began our migration to AFNET. Tinker migrated just before us and that's when their problem began as I understand, but I don't know if this is what is causing any other base's problem or not.



We solved the problem by updating the proxy exceptions in Internet Explorer to prevent all * names except specifically from using the proxy. We did this by adding "a*", "b*", "c*", plus "wa*", "wb*", etc to the proxy exception list such that the only "*" name that is not matched by any rule is specifically "" so requests for that site are sent out through the proxy. We had to do this again once our AFNET migration started. AFNET exceptions had the opposite problem in our case though, where it had no "w*" rules so every "w*" site tried to use the proxy (the rules were a snap shot of our exception settings taken before the firewall rule was removed). So, in this case ONLY worked but no other w* server worked properly.


We also had the firewall rule restored eventually, but by that time we had come up with the proxy exception solution and had changed the DNS resolution of to point to the real Akamai address of the site, so that firewall rule is probably no longer necessary.


This proxy exception solution is working well for us now.


There were a lot of different agencies involved in this due to AFNET network management policies so it took a while to nail this down and implement. We no longer control most of the pieces of the solution! And, since we were sort of "driving" this issue from the bottom up instead of the top down, there may be a better solution than what we came up with. Every base will need different proxy exceptions, but they probably have those anyway, so this might be a fix for them too.


For those bases having the problem, a simple test to see if this solution might work is to just have a user remove all browser proxy exceptions from IE temporarily but keep the proxy enabled and then try to hit their AFPW site. If it works, then this proxy exception solution may be the way to go.




Rob Walls

Rylex Consulting, LLC.


Hill AFB, UT 84056

DSN: 777-2230

Commercial: (801) 777-2230