Cisco Pix 506e firewall blocking Win07 from accessing a specific website?

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?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

Reponse To Answer

by VCHD_IT In reply to My 2 cents

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.

Collapse -

My 2 Cents

by sanjiv2 In reply to Cisco Pix 506e firewall b ...

Here is my understanding of your network:

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.
      Collapse -

      Is this still a problem that needs looking at?

      by dl_wraith In reply to Cisco Pix 506e firewall b ...

      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). ***


      Collapse -

      Reponse To Answer

      by VCHD_IT In reply to Is this still a problem t ...

      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.

      Collapse -

      Reponse To Answer

      by dl_wraith In reply to Is this still a problem t ...

      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.

      Collapse -

      Reponse To Answer

      by VCHD_IT In reply to Is this still a problem t ...

      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...).

      Collapse -

      Reponse To Answer

      by VCHD_IT In reply to Is this still a problem t ...

      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 ** ms.

      Collapse -

      Reponse To Answer

      by dl_wraith In reply to Is this still a problem t ...

      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.


      Collapse -

      Reponse To Answer

      by VCHD_IT In reply to Is this still a problem t ...

      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?

      Collapse -

      Reponse To Answer

      by dl_wraith In reply to Is this still a problem t ...

      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 :)

      Related Discussions

      Related Forums