I formerly asked the question "Anyone experience in Windows 2007 where certain websites will not open?" I received replies but nothing resolved the issue that our agency's webpage will not open in the four new Windows 2007 computers our agency recently purchased. It can be opened on any of the agency's windows XP computers. I can open the website on a Window 07 laptop on my home network but once I bring the laptop to work and connect to the local network it cannot open the webiste. I've connected a windows 07 computer directly to the gateway by passing the firewall and switches and it can open the website.
I have boiled it down to possibly the issue originating from the configuration of our CISCO Pix 506e firewall. It has been in service for over ten years with very little or no updates. I have no experience with this hardware. It seems you need a CISCO service contract to be able to download utilites or firmware for hardware you own. Our agency does not have a current contract.
Is there a configuration or setting that could cause our agency's website from opening in a window 2007 PC?
- Follow via:
- RSS
- Email Alert
Question
Clarifications
I didn't see your previous question, but are you (behind the PIX) able to open any websites or most but not your companies? What error is the browser throwing up when you try to access your agency's website?
dmritchie2
18th Jul
Answers (16)
0
Votes
Lots more information needed...
That is correct on the Cisco hardware requiring a contract to download the new IOS. And, something that old is getting close to EOL (end of life)-- http://www.cisco .com/en/US/prod/collateral/vpndevc/ps5708/ps5709/ps2030/ps4336/prod_eol_notice0900aecd80731dfa.html
But, how are we to help unless we can see the configuration of the PIX?? Strip out all static IP's on the net, username/passwords, sensitive or identifying information. etc.
Just a thought, but is DNS working OK on the internal network? XP may be using WINS or NetBIOS to resolve names... Can you ping the address on the Win7 Machine from the internal network?
But, how are we to help unless we can see the configuration of the PIX?? Strip out all static IP's on the net, username/passwords, sensitive or identifying information. etc.
Just a thought, but is DNS working OK on the internal network? XP may be using WINS or NetBIOS to resolve names... Can you ping the address on the Win7 Machine from the internal network?
13th Jul
Replies
The DNS is working OK on the internal network. WINS is disabled on the XP boxes. I can ping the website from a windows 07 box successfully.
I will attempt to copy config file and post. I will not be in the office again until Monday evening.
I will attempt to copy config file and post. I will not be in the office again until Monday evening.
VCHD_IT
14th Jul
0
Votes
port blocking
Out of curiosity, does the link that will not open have a port at the end?
Like http://www.the-web-site.com:8080/the-page.htm
If so, you will need to open that port outbound.
Post your config like cmiller says and check the link for a port and let us know.
Like http://www.the-web-site.com:8080/the-page.htm
If so, you will need to open that port outbound.
Post your config like cmiller says and check the link for a port and let us know.
13th Jul
Replies
There is no port on the end of the link. I will need to research how to copy the config and will post. Will not be back at work until Monday evening. Going in late so I can remove CISCO Pix from the network and see if the Window 07 box can then open the webiste.
Thanks for the response.
Thanks for the response.
VCHD_IT
14th Jul
1
Vote
I doubt it's the PIX unless the web site is external.
The PIX firewall filters traffic going into and out of the PIX. That's basically all it does. So if the web site is hosted inside of the PIX, it's not the PIX. If the web site is hosted outside of the PIX, then I would say yes, it's the PIX.
side note: "updates" to Cisco's IOS would not be the issue. The issue would be ACLs, extended ACLs, which are Cisco's IOS method of filtering traffic. Cisco ACLs have an implicit deny at the end of it and is not viewable in the ACL configuration. That implicit deny means that if an ACL is used, traffic that is not specifically allowed, is denied. ACLs can be configured to filter traffic in a multitude of ways from ip address to a range of addresses to specific content type, to MAC addresses, and can be implimented on either the internal interface, or external interface. If you know nothing about Cisco or very little, hire a consultant or hire Cisco to fix it.
side note: "updates" to Cisco's IOS would not be the issue. The issue would be ACLs, extended ACLs, which are Cisco's IOS method of filtering traffic. Cisco ACLs have an implicit deny at the end of it and is not viewable in the ACL configuration. That implicit deny means that if an ACL is used, traffic that is not specifically allowed, is denied. ACLs can be configured to filter traffic in a multitude of ways from ip address to a range of addresses to specific content type, to MAC addresses, and can be implimented on either the internal interface, or external interface. If you know nothing about Cisco or very little, hire a consultant or hire Cisco to fix it.
Updated - 14th Jul
Replies
I agree with your last statement, however how do you locate a CISCO consultant. I contacted CISCO and they could not direct me to a directory just mention I should locate forums.
VCHD_IT
14th Jul
I've also have spoken one of our agency vendors to get quote for purchasing a service contract. The vendor needed to know what specific hardware I was needing the contract.
Are their service contract hardware specific?
Are their service contract hardware specific?
VCHD_IT
14th Jul
I'm surprised Cisco representatives didn't point you to their directory of Cisco partners in your area. See this link: http://www.cisco.com/web/partners/index.html
I'm also surprised Cisco didn't quote you a price for TACS support
http://www.cisco.com/web/services/ordering/contracts/index.html
I'm also surprised Cisco didn't quote you a price for TACS support
http://www.cisco.com/web/services/ordering/contracts/index.html
CG IT
14th Jul
Yes Cisco support is hardware specific. Your PIX firewall is a discontinued item. The ASA series is Cisco's new firewall. But that should not mean Cisco won't help, or that you could not find a Cisco partner that could help.
CG IT
14th Jul
0
Votes
more ideas
I reread your post. I'll throw a few more questions to you. So inside from xp is good, inside from win07 no good. Depending on how your network is configured, (i.e. your pix is between the 07 device and the site, or something else is in the mix), you can troubleshoot from there. That layout is important, and the config will help rule the pix in or out. You mentioned bypassing pix and switches, so there is some gray area in there as to where the issue lies. If your server lies in a dmz somewhere behind the pix or another device, you can dig there. Is the server internal, or external? I'd be curious to know if your xp and 07 pc's are in the same network, and if they are resolving an internal or external address (if you ping the server by name, what address do you get). cmiller mentioned netbios and wins which makes sense, but we do need a little more to go on. Sometimes, the dialog will help find the answer or places to look, which is even better than someone pointing it out.
So, a couple more questions to help sort this out.
server inside or outside, or dmz
if inside in dmz, where is that compared to pix?
07 and xp on same network and ip range?
dns working internally?
Have the xp machines been rebooted recently?
Name, ip or network change recently on server?
A ping from xp and 07 to name of server yields what address (inside or outside) even if this fails, this is good information to have. If you get an inside address on the xp and outside address on the 07, that is a clue.
Lastly, when you say from home it works, is that over a vpn or directly over the internet?
So, a couple more questions to help sort this out.
server inside or outside, or dmz
if inside in dmz, where is that compared to pix?
07 and xp on same network and ip range?
dns working internally?
Have the xp machines been rebooted recently?
Name, ip or network change recently on server?
A ping from xp and 07 to name of server yields what address (inside or outside) even if this fails, this is good information to have. If you get an inside address on the xp and outside address on the 07, that is a clue.
Lastly, when you say from home it works, is that over a vpn or directly over the internet?
14th Jul
Replies
The server is inside. O7 & XP (all dynamic IP/ipv4 addresses) are on the same network. IP is the protocol used on the workgroup network. The XP computer for the most part rebooted each work day. The server is a new HP server running Window server 2008. Prior to the server we had been a Novell network. It was discovered shortly after the new server was placed into service that it had not been assigned a static address. For the past 2 months it has been assigned a static address. Other than that the server name was changed when the new server was placed into service apprx. 6 month ago. Ping the server and the website in question from an XP and from a 07 yields the same IP address. Both XP and 07 successfully ping the website and yield the same outside ip address. The home network is directly over the internet through a wireless router.
Our network setup starting a Comcast gateway to the CISCO pix then to 3 - 24 port 3COM switches that all workstations, network printers and electronic door locks communicate.
I won't be in the office until this evening to submit the CISCO Pix configuration and to try eliminate CISCO from network (connect gateway directly to switches) then attempt to connect to the agency's website through a window 07 box.
Our network setup starting a Comcast gateway to the CISCO pix then to 3 - 24 port 3COM switches that all workstations, network printers and electronic door locks communicate.
I won't be in the office until this evening to submit the CISCO Pix configuration and to try eliminate CISCO from network (connect gateway directly to switches) then attempt to connect to the agency's website through a window 07 box.
VCHD_IT
16th Jul
Here is the PIX configuration:
PIX versison 6.1
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable passwd
hostname pixfirewall
domain-name cisco.com
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list inbound permit icmp any any echo-reply
pager lines 24
interface ethernet0 auto
interface ethernet1 auto
icmp permit any unreachable outside
mtu outside 1500
mtu inside 1500
ip audit info action alarm
ip audit attack action alarm
pdm history enale
arp timeout 14400
global 1 interface
nat 1 0.0.0.0 0.0.0.0 00
access-group inbound in interface outside
route outside
route inside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:0
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet 0.0.0.0. 0.0.0.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 60
dhcpd address inside
dhcpd dns
dhcpd lease 604800
dhcpd ping_timeout 1500
dhcpd domain Mcleodusa.net
dhcpd enable inside
terminal width 80
The item that catches my eye is "dhcpd domain mcleodusa.net" This is a company we used years ago when we go our first high speed internet connection. We have since switched to a local company Soltec which was eventually bought by Iserv. Late last year we dropped Iserv and moved to Compcast for our high speed internet connection. I have notice when I do a ipconfig /all at any of the agency's computers the following is listed "DNS
Suffix Search List.........mcleodusa.net.
I removed the PIx from the network and connect the Comcast Gateway directly to the switch inwhich the PIX was connected. I booted our server and one of the windows 07 computers. The 07 computer could not connect to the server but did have an internet connection. It could open the agency's website. Since the PIX was the dhcp server, all the ip addresses were a dfferent range therefore the window 07 could not connect to the agency's server that has a static IP in a dfferent range. The subnet were the same.
Does this conclude that the PIX is the issue. What is the next step?
PIX versison 6.1
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable passwd
hostname pixfirewall
domain-name cisco.com
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list inbound permit icmp any any echo-reply
pager lines 24
interface ethernet0 auto
interface ethernet1 auto
icmp permit any unreachable outside
mtu outside 1500
mtu inside 1500
ip audit info action alarm
ip audit attack action alarm
pdm history enale
arp timeout 14400
global 1 interface
nat 1 0.0.0.0 0.0.0.0 00
access-group inbound in interface outside
route outside
route inside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:0
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet 0.0.0.0. 0.0.0.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 60
dhcpd address inside
dhcpd dns
dhcpd lease 604800
dhcpd ping_timeout 1500
dhcpd domain Mcleodusa.net
dhcpd enable inside
terminal width 80
The item that catches my eye is "dhcpd domain mcleodusa.net" This is a company we used years ago when we go our first high speed internet connection. We have since switched to a local company Soltec which was eventually bought by Iserv. Late last year we dropped Iserv and moved to Compcast for our high speed internet connection. I have notice when I do a ipconfig /all at any of the agency's computers the following is listed "DNS
Suffix Search List.........mcleodusa.net.
I removed the PIx from the network and connect the Comcast Gateway directly to the switch inwhich the PIX was connected. I booted our server and one of the windows 07 computers. The 07 computer could not connect to the server but did have an internet connection. It could open the agency's website. Since the PIX was the dhcp server, all the ip addresses were a dfferent range therefore the window 07 could not connect to the agency's server that has a static IP in a dfferent range. The subnet were the same.
Does this conclude that the PIX is the issue. What is the next step?
VCHD_IT
16th Jul
0
Votes
to reach a web site by name, you need DNS to resolve the name to an address
DNS server addresses are provided to clients as DNS options or are statically defined on the client machines.
If the DNS server does not have a record for the name and the address associated with the name, DNS will forward unresolved queries to root hint DNS servers. They the root hint servers don't resolve the name, the error is returned to the client in the browser as page and not be displayed.
you still haven't said where the web site is hosted. If it's hosted internally, then an internal DNS server should resolve the name to the correct address and send the query to the web server which then returns the web site in the users browser. If DNS does not resolve the name or if the users are using the incorrect DNS to resolve names, the user will get the page can not be displayed.
If the DNS server does not have a record for the name and the address associated with the name, DNS will forward unresolved queries to root hint DNS servers. They the root hint servers don't resolve the name, the error is returned to the client in the browser as page and not be displayed.
you still haven't said where the web site is hosted. If it's hosted internally, then an internal DNS server should resolve the name to the correct address and send the query to the web server which then returns the web site in the users browser. If DNS does not resolve the name or if the users are using the incorrect DNS to resolve names, the user will get the page can not be displayed.
17th Jul
Replies
Our website is hosted at godaddy.
VCHD_IT
18th Jul
The windows 2007 boxes cannot browse to the agency website when the Url address is used or when the IP address is used. I have tried on Chrome and Firefox with the same results. What is Windows 2007 boxes doing different than the Windows XP boxes?
VCHD_IT
18th Jul
0
Votes
hmm
I'm not convinced that the pix is it just yet. Although I don't see an outbound access list in what you posted. I don't see any dhcp ip range or dns or anything like that either in this config, so I am a little confused as to whether or not the pix is actually acting as the dhcp server. Is it possible that the pix was booted recently and the config was partially lost, having not been saved? Might explain some of the holes.
Have you tried manually assigning an ip address to the 07 machine? Also, do you have access to your internal dns servers to see how the server is listed in there?
Couple other things to try. Have you tried another browser on the 07?
When you access the server from inside, are you using the full dns name,? or just http://servername? If your thought on the mcleodusa.net is true, it could be trying to resolve your server at that domain, rather than your own. You definitely have a head scratcher here.
Have you tried manually assigning an ip address to the 07 machine? Also, do you have access to your internal dns servers to see how the server is listed in there?
Couple other things to try. Have you tried another browser on the 07?
When you access the server from inside, are you using the full dns name,? or just http://servername? If your thought on the mcleodusa.net is true, it could be trying to resolve your server at that domain, rather than your own. You definitely have a head scratcher here.
17th Jul
Replies
The PIX is over 10 years old and has been rebooted many times but anything is possible.
This morning I set static IP address for a windows 07 box and set the DNS server addresses. I attempted to connect to the agency website with no success. I rebooted the computer and tried to connect to the agency website, again, with no success.
I must admit upfront I do not have a lot of experience dealing with DNS servers. So any information I may provide on this subject is not being provided with 100% confidence. When doing a ipconfig /all at a command prompt it show that the preferred DNS are ip addresses belonging to Comcast our internet & email provider. I called them one day to see if the issue could be on their side. The tech had me connect a windows 07 box directly to their Comcast gateway and see if it could connect to the website. I did and the computer was able to connect to the agency website. The Comcast tech indicated since it could connect to the website the issue is not due to comcast.
I have tried to connect to the agency website using Chrome and Foxfire with no success. Having said that on a couple occassions when attempting to connect to the website using Chrome once the initial opening failed the browser offers a "reload" option. When I've selected it the website would open. I've researched to see if it may be possible to load IE 8.0 on a windows 07 box and see if I could open the webite but I've not found info showing how to do that when IE v. 9.0 is OEM on the computer.
When trying to open the agency website I have tried both the url address and the ip address with both failing in IE9, Chrome and Firefox.
This morning I set static IP address for a windows 07 box and set the DNS server addresses. I attempted to connect to the agency website with no success. I rebooted the computer and tried to connect to the agency website, again, with no success.
I must admit upfront I do not have a lot of experience dealing with DNS servers. So any information I may provide on this subject is not being provided with 100% confidence. When doing a ipconfig /all at a command prompt it show that the preferred DNS are ip addresses belonging to Comcast our internet & email provider. I called them one day to see if the issue could be on their side. The tech had me connect a windows 07 box directly to their Comcast gateway and see if it could connect to the website. I did and the computer was able to connect to the agency website. The Comcast tech indicated since it could connect to the website the issue is not due to comcast.
I have tried to connect to the agency website using Chrome and Foxfire with no success. Having said that on a couple occassions when attempting to connect to the website using Chrome once the initial opening failed the browser offers a "reload" option. When I've selected it the website would open. I've researched to see if it may be possible to load IE 8.0 on a windows 07 box and see if I could open the webite but I've not found info showing how to do that when IE v. 9.0 is OEM on the computer.
When trying to open the agency website I have tried both the url address and the ip address with both failing in IE9, Chrome and Firefox.
VCHD_IT
18th Jul
0
Votes
My 2 cents
Here is my understanding of your network:
http://www.gliffy.com/pubdoc/3741740/M.png
My Suggestions:
Here is my understanding:
Assumption A : If Webserver is outside the local network.
Assumption B: If webserver is inside the local network
It is safe to post entire PIX configuration provided you mask public IP, passwords (even if it is encrypted),domain names, or any other object name referencing your domain/company.
http://www.gliffy.com/pubdoc/3741740/M.png
My Suggestions:
Here is my understanding:
Assumption A : If Webserver is outside the local network.
1. If domain name is accessible by XP workstations then it should be accessible by WIN7 as well. PIX does not care about the client OS.
2. Manually assign local IP address + DNS to one of the WIN7 computer and try if it works.
3. Note down the IP/DNS configuration of one of the working XP computer , turn it off and assign the same IP/DNS config to the WIN7 computer see it works.
4. Make sure do not launch the website from the shortcut. Open up the browser and type the domain name directly in the browser.
5. Try with different browser if required.
6. Try to ping the domain name as well as your dns server.
7. Open up the command prompt and type nslookup www.your-domain.com and see if your DNS server is able to resolve the domain name to an ip address.
8. Try changing the DNS to 8.8.8.8 and run ipconfig /flushdns and try again.
Assumption B: If webserver is inside the local network
1. In order to reach the webserver behind the PIX using the public domain from the local network, one of the following has to be true:
i. DNS doctrine has been done on the PIX.
ii. You have hosted local DNS with the local network and your clients have been configured for local DNS.
iii. Client host file has of local IP address with the public domain name, such as:
192.168.2.4 www.your-domain-name.com your-domain-name.com
2. Check the contents of the host file on XP clients:
3. Try reaching the website using the local IP address of the server such as http://192.168.2.4
It is safe to post entire PIX configuration provided you mask public IP, passwords (even if it is encrypted),domain names, or any other object name referencing your domain/company.
Updated - 18th Jul
Replies
Your understanding of the network is correct with the webserver on the outside.
I've tried assigning a ip and DNS to the Windows 07 boxes and using an alternative DNS with the same results that the website cannot be opened.
I followed items 1 - 8 with no success, however after running ipconfig /dnsflush I used Chrome to attempt to open the agency's website once the ERR_TIMED_OUT error was shown, I immediately selected the "reload" option and the home page opened. I then clicked a link to another website page and it opened. When I then selected a pdf file link I received the ERR_TIMED_OUT error. I tried again to open the website in Chrome, got the same error, selected "reload" but this time it failed. I ran the ipconfig /dnsflush command again and tried to open the agency website in Chrome with the expectation of it failing but hoping that once select "reload' option it would open the agency website. It did not. It seems that the domain is not responding fast enough for the browser and time out is occurring.
My knowledge of the PIX is pretty much what I have learned trying to resolve this issue. I believe what I have previously posted is the complete PIX config. I obtain this information by starting a telnet session. "Open" using PIX IP address. I then enter password and then typed "enable" and typed password again. Finally, I used "sh config" to get to the config information. Is there another command that would show more config info?
I've tried assigning a ip and DNS to the Windows 07 boxes and using an alternative DNS with the same results that the website cannot be opened.
I followed items 1 - 8 with no success, however after running ipconfig /dnsflush I used Chrome to attempt to open the agency's website once the ERR_TIMED_OUT error was shown, I immediately selected the "reload" option and the home page opened. I then clicked a link to another website page and it opened. When I then selected a pdf file link I received the ERR_TIMED_OUT error. I tried again to open the website in Chrome, got the same error, selected "reload" but this time it failed. I ran the ipconfig /dnsflush command again and tried to open the agency website in Chrome with the expectation of it failing but hoping that once select "reload' option it would open the agency website. It did not. It seems that the domain is not responding fast enough for the browser and time out is occurring.
My knowledge of the PIX is pretty much what I have learned trying to resolve this issue. I believe what I have previously posted is the complete PIX config. I obtain this information by starting a telnet session. "Open" using PIX IP address. I then enter password and then typed "enable" and typed password again. Finally, I used "sh config" to get to the config information. Is there another command that would show more config info?
VCHD_IT
19th Jul
I failed to include in my reply that in item 7. the DNS was successful in resolving the domain name to an IP address.
Item 6. Pinging the website and domain server were successful.
Item 6. Pinging the website and domain server were successful.
VCHD_IT
19th Jul
0
Votes
My 2 Cents
Here is my understanding of your network:
http://www.gliffy.com/pubdoc/3741740/M.png
My Suggestions:
Here is my understanding:
Assumption A : If Webserver is outside the local network.
Assumption B: If webserver is inside the local network
It is safe to post entire PIX configuration provided you mask public IP, passwords (even if it is encrypted),domain names, or any other object name referencing your domain/company.
http://www.gliffy.com/pubdoc/3741740/M.png
My Suggestions:
Here is my understanding:
Assumption A : If Webserver is outside the local network.
1. If domain name is accessible by XP workstations then it should be accessible by WIN7 as well. PIX does not care about the client OS.
2. Manually assign local IP address + DNS to one of the WIN7 computer and try if it works.
3. Note down the IP/DNS configuration of one of the working XP computer , turn it off and assign the same IP/DNS config to the WIN7 computer see it works.
4. Make sure do not launch the website from the shortcut. Open up the browser and type the domain name directly in the browser.
5. Try with different browser if required.
6. Try to ping the domain name as well as your dns server.
7. Open up the command prompt and type nslookup www.your-domain.com and see if your DNS server is able to resolve the domain name to an ip address.
8. Try changing the DNS to 8.8.8.8 and run ipconfig /flushdns and try again.
Assumption B: If webserver is inside the local network
1. In order to reach the webserver behind the PIX using the public domain from the local network, one of the following has to be true:
i. DNS doctrine has been done on the PIX.
ii. You have hosted local DNS with the local network and your clients have been configured for local DNS.
iii. Client host file has of local IP address with the public domain name, such as:
192.168.2.4 www.your-domain-name.com your-domain-name.com
2. Check the contents of the host file on XP clients:
3. Try reaching the website using the local IP address of the server such as http://192.168.2.4
It is safe to post entire PIX configuration provided you mask public IP, passwords (even if it is encrypted),domain names, or any other object name referencing your domain/company.
18th Jul
0
Votes
Is this still a problem that needs looking at?
VCHD_IT - is this still an issue that needs dealing with? If so, I'd like to help. I have been running a pair of PIX 515E units on different IOS levels up until this year and did the old CSFPA course some years back. While I wouldn't say I'm an expert I certainly know my way around some of the foibles of the PIX, particularly pre-7.0 (when bits the configuration changed).
If the fine gentlemen before me haven't already sorted this for you please feel free to contact me. If I can have your PIX config and some clarification on your network topology for this scenario I'd be happy to review the situation.
I see from the bits of the config you've posted you have SSH access to the PIX from the outside enabled so please use the service encryption on the PIX or simply make sure any passwords are blanked from the config. The previous poster's suggestion about blanking domain names is also a good idea. Depending on the exact problem I may need to see all the IP addressing but you could use a find/replace on the config file to replace real public IPs with fake alternatives (just make sure any rules changed are consistent with the rest of the config or it will get confusing REALLY quickly :)).
*** It's worth noting that DNS is certainly the place to start if the workstations attempting to visit the website cannot reach it by name, but can by it's public IP address (as sanjiv2 suggests, above). ***
Cheers
If the fine gentlemen before me haven't already sorted this for you please feel free to contact me. If I can have your PIX config and some clarification on your network topology for this scenario I'd be happy to review the situation.
I see from the bits of the config you've posted you have SSH access to the PIX from the outside enabled so please use the service encryption on the PIX or simply make sure any passwords are blanked from the config. The previous poster's suggestion about blanking domain names is also a good idea. Depending on the exact problem I may need to see all the IP addressing but you could use a find/replace on the config file to replace real public IPs with fake alternatives (just make sure any rules changed are consistent with the rest of the config or it will get confusing REALLY quickly :)).
*** It's worth noting that DNS is certainly the place to start if the workstations attempting to visit the website cannot reach it by name, but can by it's public IP address (as sanjiv2 suggests, above). ***
Cheers
19th Jul
Replies
Thanks for the offier any additional wisdom is appreciated. The issue has not been resolved, no thanks to the appreciated advice and recommendations from all who have responded.
I've submitted a purchase requisite, yesterday, to purchase an extended service agreement with CISCO for the PIX. Can't get any assistance without one. We are a small government agency that like many are barely keeping the doors open, financially. I was hesitant to make the purchase not 100% confident that it is the PIX causing the issue.
As I mention in a previous response, my knowledge of PIX is limited to what I have learned since trying to resolve this issue. The config info I posted previously is the entire file minus password, domain name and ip addesses.
I'd be happy to post further information but will need procedural guidance.
I've submitted a purchase requisite, yesterday, to purchase an extended service agreement with CISCO for the PIX. Can't get any assistance without one. We are a small government agency that like many are barely keeping the doors open, financially. I was hesitant to make the purchase not 100% confident that it is the PIX causing the issue.
As I mention in a previous response, my knowledge of PIX is limited to what I have learned since trying to resolve this issue. The config info I posted previously is the entire file minus password, domain name and ip addesses.
I'd be happy to post further information but will need procedural guidance.
VCHD_IT
19th Jul
2 things come to mind now I've read some more details here about your issue.
I am assuming that the win XP and Win7 PCs are on the inside of the firewall, on the same subnet, connected to the same switch and are sharing the same DNS resolver. I am also assuming that the webserver you are having difficulty accessing is on the PIX's outside port, beyond the comcast gateway and that routing is fine between the PCs and your webserver (traceroute from the windows PCs to the webservers IP address).
1) have you tried clearing your translations on the PIX when the issue occurs? (Telnet to the pix, 'enable' and type your passsword, 'configure terminal' and 'clear xlate' - beware - this action kills all currently held translations across the PIX so connections may need to re-establish)
If this works the issue could be with the XLATE configuration you have. Try reducing the xlate timers.
2) If the XP machines can always access fine but the Win7 PCs can't the issue may not be with xlates, routing or (assumptions holding) the DNS resolution. Try adding a DNS fixup using a large value (1024 should do to start - again: telnet, enable, configure terminal, 'fixup protocol dns maximum-length 1024' ).
I notice you aren't using a fixup on your DNS protocol, hence the suggestion. I must admit though, if your DNS queries aren't traversing the PIX this fix wouldn't have any impact so I have to ask - where is the device that resolves your DNS queries? Ouside the PIX, Inside the PIX or in a DMZ?
I could be very wrong with these ideas as I can't get at my test PIX to test this theory (it's in use). Just thinking on the fly.
I am assuming that the win XP and Win7 PCs are on the inside of the firewall, on the same subnet, connected to the same switch and are sharing the same DNS resolver. I am also assuming that the webserver you are having difficulty accessing is on the PIX's outside port, beyond the comcast gateway and that routing is fine between the PCs and your webserver (traceroute from the windows PCs to the webservers IP address).
1) have you tried clearing your translations on the PIX when the issue occurs? (Telnet to the pix, 'enable' and type your passsword, 'configure terminal' and 'clear xlate' - beware - this action kills all currently held translations across the PIX so connections may need to re-establish)
If this works the issue could be with the XLATE configuration you have. Try reducing the xlate timers.
2) If the XP machines can always access fine but the Win7 PCs can't the issue may not be with xlates, routing or (assumptions holding) the DNS resolution. Try adding a DNS fixup using a large value (1024 should do to start - again: telnet, enable, configure terminal, 'fixup protocol dns maximum-length 1024' ).
I notice you aren't using a fixup on your DNS protocol, hence the suggestion. I must admit though, if your DNS queries aren't traversing the PIX this fix wouldn't have any impact so I have to ask - where is the device that resolves your DNS queries? Ouside the PIX, Inside the PIX or in a DMZ?
I could be very wrong with these ideas as I can't get at my test PIX to test this theory (it's in use). Just thinking on the fly.
dl_wraith
20th Jul
Your assumptions are accurate accept that the individual computers could be connected to any of three 3COM switches, which are all interconnected to the same network, same workgroup.
Your two suggestions on commands to try on the CISCO are well beyond my comprehension on what they do. I feel that I might want to try them at a time when no one is connected to the network (after hours). I might come in this weekend or try Monday evening. Is there any severe repercussions on doing these commands? Is there commands to undo in case of an emergency?
Your question "where is the device that resolves your DNS queries? ". Here is the best answer I can give you. At any of the agency's PC the ipconfig /all command shows the DNS server address as those that belong to Comcast our internet and email provider. So I assume it is the Comcast Gateway box to the outside of the PIX. When I removed the PIX from the network and connected the Comcast Gateway directly to the 3COM switches the XP and 07 boxers had internet connection and the 07 boxes could connect to the agency's website. However neither boxes could connect to the agency network because they were assigned IP address (10.1...) outside the series used by our network (192.168...).
Your two suggestions on commands to try on the CISCO are well beyond my comprehension on what they do. I feel that I might want to try them at a time when no one is connected to the network (after hours). I might come in this weekend or try Monday evening. Is there any severe repercussions on doing these commands? Is there commands to undo in case of an emergency?
Your question "where is the device that resolves your DNS queries? ". Here is the best answer I can give you. At any of the agency's PC the ipconfig /all command shows the DNS server address as those that belong to Comcast our internet and email provider. So I assume it is the Comcast Gateway box to the outside of the PIX. When I removed the PIX from the network and connected the Comcast Gateway directly to the 3COM switches the XP and 07 boxers had internet connection and the 07 boxes could connect to the agency's website. However neither boxes could connect to the agency network because they were assigned IP address (10.1...) outside the series used by our network (192.168...).
VCHD_IT
20th Jul
I forgot to mention, you mentioned running tracert between web server IP address and an agency's PC. I did that with an XP and with a 07 PC. Both went 17 tries of "request timed out" then on the 18th try the results were 90ms, 91ms 91 ms.
VCHD_IT
20th Jul
Thanks for the replies - that's a little clearer now.
A third question that did occur:
3) Is the Comcast simply routing layer 3 or is it NATting the traffic to another address range? If you don't know but have access to the Comcast router you should be able to tell reasonably easily.
The two commands I gave you sound scarier than they are. A quick 'n' dirty explanation is:
Xlate is simply a 'translation' that the PIX holds in memory to facilitate traffic across the PIX's various interfaces. Once you've ENABLEd in the PIX, use SHOW XLATE to see what I mean. Once the PIX knows an address for a connection on each interface it holds it in memory and re-uses it as long as one side or the other is continuing to try and communicate. Using CLEAR XLATE empties the PIX of all these remembered translations essentially meaning each new connection has to be re-learned as it's requested. Any established connections are dropped and have to be retried to get through.
As for the FIXUP, now I know your DNS is going out past the comcast I can tell you that it may help you. The fixup command I gave you essentially tries to 'fix' DNS protocol packets to a size of 1024. This is in case overlarge DNS queries (which Win7 can easily create!) are not making it across the PIX properly.
I hope that makes things a little clearer.
BTW, if you aren't getting ICMP responses via traceroute until really later in the hops then you aren't getting echo replies from a lot of intervening items. On the PIX you could try setting up an access-list associated with the inside interface and use the rule:
access-list acl_inside permit icmp any any
where 'acl_inside' is the name of the rule you create. That will allow the PIX to respond to ICMP packets.
One word of warning - while 'permit ICMP any any' is a handy troubleshooting step, it's not a great idea to leave this open on OUTSIDE interfaces - leaves the PIX vulnerable to ping of death and similar DDoS attacks.
A third question that did occur:
3) Is the Comcast simply routing layer 3 or is it NATting the traffic to another address range? If you don't know but have access to the Comcast router you should be able to tell reasonably easily.
The two commands I gave you sound scarier than they are. A quick 'n' dirty explanation is:
Xlate is simply a 'translation' that the PIX holds in memory to facilitate traffic across the PIX's various interfaces. Once you've ENABLEd in the PIX, use SHOW XLATE to see what I mean. Once the PIX knows an address for a connection on each interface it holds it in memory and re-uses it as long as one side or the other is continuing to try and communicate. Using CLEAR XLATE empties the PIX of all these remembered translations essentially meaning each new connection has to be re-learned as it's requested. Any established connections are dropped and have to be retried to get through.
As for the FIXUP, now I know your DNS is going out past the comcast I can tell you that it may help you. The fixup command I gave you essentially tries to 'fix' DNS protocol packets to a size of 1024. This is in case overlarge DNS queries (which Win7 can easily create!) are not making it across the PIX properly.
I hope that makes things a little clearer.
BTW, if you aren't getting ICMP responses via traceroute until really later in the hops then you aren't getting echo replies from a lot of intervening items. On the PIX you could try setting up an access-list associated with the inside interface and use the rule:
access-list acl_inside permit icmp any any
where 'acl_inside' is the name of the rule you create. That will allow the PIX to respond to ICMP packets.
One word of warning - while 'permit ICMP any any' is a handy troubleshooting step, it's not a great idea to leave this open on OUTSIDE interfaces - leaves the PIX vulnerable to ping of death and similar DDoS attacks.
dl_wraith
23rd Jul
your item 3. in your last response was way over my head. The Comcast gateway is in house but I don't know what access I have.
I did the XLATE command but it seemed to fail to clear out all remembered translations. After completeing a CLEAR XLATE I would do a SHOW XLATE and it would still display a list of translations.
I haven't tied the FIXUP hope to as soon as possible. Would it be safe to do this during business day while users are connected to the network?
I have a question on your suggestion touse access-list acl_inside permit icmp any any" command. You recommend not to leave this open. What is the command to close?
I did the XLATE command but it seemed to fail to clear out all remembered translations. After completeing a CLEAR XLATE I would do a SHOW XLATE and it would still display a list of translations.
I haven't tied the FIXUP hope to as soon as possible. Would it be safe to do this during business day while users are connected to the network?
I have a question on your suggestion touse access-list acl_inside permit icmp any any" command. You recommend not to leave this open. What is the command to close?
VCHD_IT
24th Jul
On the CLEAR XLATE, translations are re-establised the moment computers request a connection so before you can type SHOW XLATE you'll sometimes find there are indeed lots of translations. Gotta be quick and on a quiet network to see this clear out properly
On my question about the Comvcast, sorry - I over complicated that . The key point is whether the Comcast router is NATting connections outbound. If you don't know, don't worry for now while we have other things to do.
On FIXUP, yes, that's safe to enter during a working day. DON'T save it to the startup-config until you know it's working right. If it causes issues for you either:
a) telnet and 'enable' on the PIX, type configure terminal [enter], and type 'no fixup protocol dns maximum-length 1024' [enter]
b) telnet and 'enable' on the PIX, type 'reload' [enter]. This will restart the PIX firewall and revert it to your saved startup-config file. ONLY DO THIS IF YOU KNOW YOUR STARTUP-CONFIG HAS ALL THE SETTINGS IN IT YOU NEED.
I only emphasise that as I once knew a cisco newbie who didn't realise that settings changes weren't stored by default on a Cisco device. he made changes month after month only ever editing the running-config of the device. When a power cut hit, he was at a loss as to why none of his routers worked any more (the running-configs cleared and the routers reverted to the startup-config files which were, obviously, default!).
On the access_list, as long as you don't mind internal systems pinging the firewall, the command I gave you is safe. Just remember to associate the access-list with an access-group with an interface. Damned PIX. never logical
To remove an access-list, access-group or pretty much any other config in the PIX simply retype the command again but put 'NO' in front of the command. So in this case:
'no access-list acl_inside permit icmp any any'
Easy enough when you've had a bit of time with it
On my question about the Comvcast, sorry - I over complicated that . The key point is whether the Comcast router is NATting connections outbound. If you don't know, don't worry for now while we have other things to do.
On FIXUP, yes, that's safe to enter during a working day. DON'T save it to the startup-config until you know it's working right. If it causes issues for you either:
a) telnet and 'enable' on the PIX, type configure terminal [enter], and type 'no fixup protocol dns maximum-length 1024' [enter]
b) telnet and 'enable' on the PIX, type 'reload' [enter]. This will restart the PIX firewall and revert it to your saved startup-config file. ONLY DO THIS IF YOU KNOW YOUR STARTUP-CONFIG HAS ALL THE SETTINGS IN IT YOU NEED.
I only emphasise that as I once knew a cisco newbie who didn't realise that settings changes weren't stored by default on a Cisco device. he made changes month after month only ever editing the running-config of the device. When a power cut hit, he was at a loss as to why none of his routers worked any more (the running-configs cleared and the routers reverted to the startup-config files which were, obviously, default!).
On the access_list, as long as you don't mind internal systems pinging the firewall, the command I gave you is safe. Just remember to associate the access-list with an access-group with an interface. Damned PIX. never logical
To remove an access-list, access-group or pretty much any other config in the PIX simply retype the command again but put 'NO' in front of the command. So in this case:
'no access-list acl_inside permit icmp any any'
Easy enough when you've had a bit of time with it
dl_wraith
25th Jul
Er....hang fire on the FIXUP command. I may have made a mistake in there thinking of a different command. You do need to apply it - I just want to check my old notes to ensure I have it's purpose correct.
If I have mixed that up with something else, I'll be MOST put out!
If I have mixed that up with something else, I'll be MOST put out!
dl_wraith
25th Jul
Yep - I gave you the right command for the right reasons. Go ahead and use that when you're ready.
Sorry - crisis of confidence for a moment there
Sorry - crisis of confidence for a moment there
dl_wraith
25th Jul
I ran the FIXUP command and received a "bad protocol dns" message. I type it with dns lower case and upper case with same results.
I ran the access-list and tried connecting to agency website on a windows 2007 box still unsuccessful. I did run the no access-list later.
I ran the access-list and tried connecting to agency website on a windows 2007 box still unsuccessful. I did run the no access-list later.
VCHD_IT
25th Jul
Just read your response 7/25/12 "Just remember to associate the access-list with an access-group with an interface."
I honestly don't know how to do this. When I ran the access-list command I just typed it as you showed in one of your response. (access-list acl_inside permit icmp any any).
I honestly don't know how to do this. When I ran the access-list command I just typed it as you showed in one of your response. (access-list acl_inside permit icmp any any).
VCHD_IT
25th Jul
Access-lists don't work for an interface until you associate them with an interface. This is done via the access-group command.
In your ICMP case all you need is to telnet, enable and conf t (as usual), then:
access-group acl_inside in interface inside
You have one already, associatd with the outside interface. See your existing access-group command? What that says is you've associated the access-list called 'outside' with the interface called 'outside'.
Only one access-group can be associated with an interface at any time but you can have lots of access-list statements under the same name all bundled together using the access-group command. All you've got to do is keep the naming consistent.
I hope that helps.
In your ICMP case all you need is to telnet, enable and conf t (as usual), then:
access-group acl_inside in interface inside
You have one already, associatd with the outside interface. See your existing access-group command? What that says is you've associated the access-list called 'outside' with the interface called 'outside'.
Only one access-group can be associated with an interface at any time but you can have lots of access-list statements under the same name all bundled together using the access-group command. All you've got to do is keep the naming consistent.
I hope that helps.
dl_wraith
30th Jul
I tried the access-group and access-list commands. We lost internet completely after i ran the commands. Due to my lack of expertise with the PIX I did not type the command in correctly. After some research I realized I fail to type our agency's interface name. I could not get the "no" access-list command to work to undo the damage I had created. I didn't know we had lost connection until I received a call from a user informing me that they could not access the internet. I remembered reading that changes made in the PIX are not automatically saved. I powered down the PIX and that reestablished our internet connection.
I ran the commands, again, using the correct acl-inside and the correct interface name. Still not able to connect to the agency's website. However, when the connection failed the Windows Network Diagnosis reported "Your computer appears to be correctly configured but the device or resource (agency's webite name) is not responding. I've not gotten that before. The diagnosis does not offer any corrective action.
I ran the commands, again, using the correct acl-inside and the correct interface name. Still not able to connect to the agency's website. However, when the connection failed the Windows Network Diagnosis reported "Your computer appears to be correctly configured but the device or resource (agency's webite name) is not responding. I've not gotten that before. The diagnosis does not offer any corrective action.
VCHD_IT
31st Jul
0
Votes
I see an error in a statment
first windows XP does not look at DNS the same as windows 7 I have trouble with 2 windows 7 machines that can't resolved DNS on one of my domains I bypass the problem by putting a router in between the network and the windows 7 machine new routers handle DNS resolution and it works so I could connect to the network server I add a USB network adaptor windows 7 does not do well with old hardware ie routers you may have to update the network hardware but test first, Ubuntu 12.4 has this problem too however you are going to love this I have xp in virtualBox on the same machine and 7 can't go put on the web nor ubuntu but my virtual XP does
19th Jul
0
Votes
One last idea from me
How about adding a host file entry for your website directly on the win 07 machine?
go to the c:\windows\system32\drivers\etc and edit the hosts file using notepad.
Leave everything in the file and at the bottom, after the ## comments, add the ip address and hostname of the server exactly as it would resolve on the internet and exactly as the remarks show it. dont add number symbol to your line. This will bypass dns for the web site.
If this works, it will buy you some time to look into the dns and pix issues. These 07 machines have the windows firewall turned on or off? If on, you can try switching that off as well, to rule it out.
I'm still confused with the dns part of this. I assume you have internal dns servers (maybe not) and they should use external helpers. When you did your ipconfig /all are you getting internal or external dns server ip addresses?
go to the c:\windows\system32\drivers\etc and edit the hosts file using notepad.
Leave everything in the file and at the bottom, after the ## comments, add the ip address and hostname of the server exactly as it would resolve on the internet and exactly as the remarks show it. dont add number symbol to your line. This will bypass dns for the web site.
If this works, it will buy you some time to look into the dns and pix issues. These 07 machines have the windows firewall turned on or off? If on, you can try switching that off as well, to rule it out.
I'm still confused with the dns part of this. I assume you have internal dns servers (maybe not) and they should use external helpers. When you did your ipconfig /all are you getting internal or external dns server ip addresses?
20th Jul
Replies
Thanks for the suggestion. Tried but no change.
VCHD_IT
25th Jul
0
Votes
If you've purchases a Cisco service contract with TACS support
then use one of your service support calls to solve your issue.
There are to many "could be this" to solve the problem your having reaching an external web site from within your local network through the PIX firewall. As sinjiv2 mentioned, if your XP machines can reach the external web site without problems, your Windows 7 machines should as well, provided both are using the same addressing and DNS schemes.
There are to many "could be this" to solve the problem your having reaching an external web site from within your local network through the PIX firewall. As sinjiv2 mentioned, if your XP machines can reach the external web site without problems, your Windows 7 machines should as well, provided both are using the same addressing and DNS schemes.
21st Jul
0
Votes
Is the Comcast Gateway a DSL/Cable Modem or Router?
Your question "where is the device that resolves your DNS queries? ". Here is the best answer I can give you. At any of the agency's PC the ipconfig /all command shows the DNS server address as those that belong to Comcast our internet and email provider. So I assume it is the Comcast Gateway box to the outside of the PIX. When I removed the PIX from the network and connected the Comcast Gateway directly to the 3COM switches the XP and 07 boxers had internet connection and the 07 boxes could connect to the agency's website. However neither boxes could connect to the agency network because they were assigned IP address (10.1...) outside the series used by our network (192.168...).
If you connect the comcast gateway to your switches, computers should NOT pull DHCP addresses if Comcast Gateway is just a DSL/Cable modem and if your assigned only 1 routable internet address. If your assigned a block of routable internet address, and the Comcast Gateway is in bridged mode, then computers could pull those public addresses.
If ithe Comcast Gateway is a DSL/Cable router and has DHCP enabled on it's LAN port, then computers could pull addresses, and could be assigned the private 10.X.X.X 255.0.0.0 subnet IF that is the default LAN addressing [which typically for consumer and small business routers, isn't not]
If that's the case, then one needs to question why the PIX is in there in the first place, as the Comcast "router" [if the device is a router] is handling NAT and firewall duties. You could configure the Comcast router, if that's what it is, to handle what the PIX was doing, and remove the PIX from the network configuration.
Check the model of the Comcast device and see if it's a DSL/Cable modem or DSL/Cable router.
25th Jul
Replies
The gateway is a SMC commercial cable modem.
VCHD_IT
26th Jul
0
Votes
What browser?
One obvious but sometimes also subtle difference is they come with different versions of browsers and at this point xp's is near EOL. If you are running IE8 on all that's one thing, but is that actually the case?
IE9 handles non fully qualified domain names differently than any of it's predecessors so that brings about some potential gotchas...
Some people will type my portal.company.com while others may be using just myportal ... Per ie9 it made no difference but in ie9 the string may actually convert to a bing/google search. You can turn off this setting of course.
But along those same lines... A programmer on your site could be referencing the non-FQDN explicitly in code too which is not advisable ... If they programmed images to load from simply myportal/foo.jpg for instance you can be in a situation where some parts of site work and not others... But in this example the issue would more relate to improper dns suffix completion vs the prior where it's the browser thinking what you typed is a search string (BUT... The reasons it revert to search string vs knowing it was an intranet site can relate to improper DNA suffix configuration).
Also does the site use Only http protocol or is it using any others? any Direct links to files? That may present other potential issues such as whether it is using smb vs smb2.
As a test i would uninstall ie9 from a win7 machine to go back to ie8 to eliminate that issue first and foremost...
IE9 handles non fully qualified domain names differently than any of it's predecessors so that brings about some potential gotchas...
Some people will type my portal.company.com while others may be using just myportal ... Per ie9 it made no difference but in ie9 the string may actually convert to a bing/google search. You can turn off this setting of course.
But along those same lines... A programmer on your site could be referencing the non-FQDN explicitly in code too which is not advisable ... If they programmed images to load from simply myportal/foo.jpg for instance you can be in a situation where some parts of site work and not others... But in this example the issue would more relate to improper dns suffix completion vs the prior where it's the browser thinking what you typed is a search string (BUT... The reasons it revert to search string vs knowing it was an intranet site can relate to improper DNA suffix configuration).
Also does the site use Only http protocol or is it using any others? any Direct links to files? That may present other potential issues such as whether it is using smb vs smb2.
As a test i would uninstall ie9 from a win7 machine to go back to ie8 to eliminate that issue first and foremost...
25th Jul
Replies
Thank you for the response. The win 07 boxes came with IE 9 installed. I've not see any way of removing ie 9. I can turn it off but then cannot install any previous version. Issue occurs in other browsers, Firefox and Chrome
WIth your explanation about the Comcast Gateway I'm going to contact Comcast and ask a few questions. I've contacted them before but didn't ask the right questions or inform them that we had a PIX between their gateway and our network.
WIth your explanation about the Comcast Gateway I'm going to contact Comcast and ask a few questions. I've contacted them before but didn't ask the right questions or inform them that we had a PIX between their gateway and our network.
VCHD_IT
26th Jul
0
Votes
on the subject of DNS Suffixs
DNS suffix options in the advanced option/DNS in the nic card properties, for Windows 7 machine, come into play in a Microsoft Active Directory environment. unlike Windows XP, Windows 7 machines really need the Active Directory domain name listed in the DNS suffix options in the nic card properties page to be able to find domain controllers to authenticate with and by inclusion, the Active Directory DNS server in which to resolve domain name queries.
In your PIX config, you have
It's possible, but maybe not probable, clients are being told the DNS server is mcleodusa.net by the PIX firewall in which to resolved DNS queries. If mcleodusa.net is not your DNS servers then this might be the reason Windows 7 clients can't reach your external web site, as the DNS listed in the PIX cant resolve the query and doesn't forward the unresolved query, by virtual of rejecting queries.
BUT, if you have statically assigned DNS servers in clients, with another DNS server address, such as your ISP's DNS servers then this DNS option in DHCP on the PIX this shouldn't matter. The client computers will use the DNS servers that are configured.
BUT, the other difference with Windows 7 than Windows XP is Windows 7 supports IPv6 [and the PIX 506 doesn't] so, it's possible, but not probable, that Windows 7 is using IPv6, which is on by default, and using information obtained from the PIX such as DNS servers, which may be the wrong ones. A test is to turn off IPv6 on the Windows 7 boxes and only use IPv4 see if that makes a difference. It may or may not.
Lots of good information from all posters here and armed with that, you'll get a good idea of the information you need to discover, to narrow down the potential cause of the problem of your external web site, not displaying in Windows 7 machines.
In your PIX config, you have
as the dhcp domain name. A whois lookup of mcleodusa.net produces this:dhcpd domain Mcleodusa.net
Registrant:
WINDSTREAM COMMUNICATIONS, INC.
6400 C Street SW
PO Box 3177
Cedar Rapids, IA 52406
US
Domain name: MCLEODUSA.NET
Administrative Contact:
Inc., McLeodUSA
6400 C Street SW
PO Box 3177
Cedar Rapids, IA 52406
US
281.465.1200
Technical Contact:
Inc., McLeodUSA
6400 C Street SW
PO Box 3177
Cedar Rapids, IA 52406
US
281.465.1200
Registration Service Provider:
PAETEC,
800-340-2555
http://www.paetec.com
This company may be contacted for domain login/passwords,
DNS/Nameserver changes, and general domain support questions.
Registrar of Record: TUCOWS, INC.
Record last updated on 11-Apr-2012.
Record expires on 20-Oct-2012.
Record created on 21-Oct-1996.
Registrar Domain Name Help Center:
http://tucowsdomains.com
Domain servers in listed order:
NS2.MCLEODUSA.NET 209.253.113.11
NS3.MCLEODUSA.NET 209.253.113.
It's possible, but maybe not probable, clients are being told the DNS server is mcleodusa.net by the PIX firewall in which to resolved DNS queries. If mcleodusa.net is not your DNS servers then this might be the reason Windows 7 clients can't reach your external web site, as the DNS listed in the PIX cant resolve the query and doesn't forward the unresolved query, by virtual of rejecting queries.
BUT, if you have statically assigned DNS servers in clients, with another DNS server address, such as your ISP's DNS servers then this DNS option in DHCP on the PIX this shouldn't matter. The client computers will use the DNS servers that are configured.
BUT, the other difference with Windows 7 than Windows XP is Windows 7 supports IPv6 [and the PIX 506 doesn't] so, it's possible, but not probable, that Windows 7 is using IPv6, which is on by default, and using information obtained from the PIX such as DNS servers, which may be the wrong ones. A test is to turn off IPv6 on the Windows 7 boxes and only use IPv4 see if that makes a difference. It may or may not.
Lots of good information from all posters here and armed with that, you'll get a good idea of the information you need to discover, to narrow down the potential cause of the problem of your external web site, not displaying in Windows 7 machines.
Updated - 26th Jul
Replies
The reason DNS suffixs and registration of the network adapter in Windows 7 plays a role in Microsoft's Active Directory domain environment is in Windows 7 network and sharing center. this really is the biggest difference between Windows XP and Window 7. The Network and Sharing Center is a security enhancement that Windows XP doesn't have and can cause problems with Windows 7 finding DNS servers in Active Directory domains with Windows 7. Without going into a log diatribe of why, The Network and Sharing Center handles how Windows 7 works on a TPC/IP network. So to find and join a Windows 7 computer to an Active Directory environment, DNS suffix is almost a requirement to be able to join the Windows 7 comp to a domain as the DNS suffix is used to locate the DNS server that handles the domain being joined to, thus the domain controller to authenticate to for joining the Active Directory domain.
CG IT
26th Jul
IPv6 has been turned off on the Window 07 boxes and they're still not able to open the agency's website.
Our agency's network is a workgroup, no domain.
Our agency's network is a workgroup, no domain.
VCHD_IT
27th Jul
0
Votes
My 2 Cents
First I want to make sure I understand the situation.
With PIX in the path:
Windows XP box can access a website over the Internet by typing "http://ip address of website"
Windows 7 box cannot access same website over the Internet by typing "http://ip address of website"
Without PIX in the path:
Both Win7 and Win XP boxes can access this website
If the above is correct, here is what I suggest trying:
On the PIX, run the following commands:
conf t
access-list inbound permit tcp any eq 80 any
access-list inbound permit tcp any eq 443 any
no fixup protocol http 80
exit
This has the effect of turning of http inspection while allowing responses from web servers through the outside interface. Now try accessing the website from Windows 7 and see if it makes a difference.
To return to the previous config run the following commands:
conf t
no access-list inbound permit tcp any eq 80 any
no access-list inbound permit tcp any eq 443 any
fixup protocol http 80
exit
With PIX in the path:
Windows XP box can access a website over the Internet by typing "http://ip address of website"
Windows 7 box cannot access same website over the Internet by typing "http://ip address of website"
Without PIX in the path:
Both Win7 and Win XP boxes can access this website
If the above is correct, here is what I suggest trying:
On the PIX, run the following commands:
conf t
access-list inbound permit tcp any eq 80 any
access-list inbound permit tcp any eq 443 any
no fixup protocol http 80
exit
This has the effect of turning of http inspection while allowing responses from web servers through the outside interface. Now try accessing the website from Windows 7 and see if it makes a difference.
To return to the previous config run the following commands:
conf t
no access-list inbound permit tcp any eq 80 any
no access-list inbound permit tcp any eq 443 any
fixup protocol http 80
exit
Updated - 26th Jul
Replies
Thanks for the suggestions. I'm out of the office Friday. I will try the no "access-list" suggestions on Monday.
Looking forward to the day that i try one of these, much appreciated, suggestions and the Windows 07 will open the website. This issue really shouldn't be that big a deal but seem important that an agency's computers can open their own website. We haven't had any other issues with the Window 07 computers that couldn't be resolved quickly.
Looking forward to the day that i try one of these, much appreciated, suggestions and the Windows 07 will open the website. This issue really shouldn't be that big a deal but seem important that an agency's computers can open their own website. We haven't had any other issues with the Window 07 computers that couldn't be resolved quickly.
VCHD_IT
27th Jul
Did you ever try my suggestion?
NetMan1958
1st Aug
Sorry, this discussion has gotten lengthy and I ran a couple other recommended commands yesterday after business hours. See response to dl.wraith above.
I ran the three commands, you recommened, and lost all internet connection. Windows Network Diagnosis reported "Wndows can't communicate with the device or resource (primary DNS server)."
Running the three commands again with the "no": in front of the first two and removing the "no" from the third command did not work to reestablish the internet connection. I power downed the PIX to reestablish internet.
I ran the three commands, you recommened, and lost all internet connection. Windows Network Diagnosis reported "Wndows can't communicate with the device or resource (primary DNS server)."
Running the three commands again with the "no": in front of the first two and removing the "no" from the third command did not work to reestablish the internet connection. I power downed the PIX to reestablish internet.
VCHD_IT
1st Aug
