Cannot Access Specific Website

Answered Question
Jun 30th, 2010
User Badges:

Hello guys,


My knowledge is very basic with Cisco Pix Firewall. We are behind a PIX firewall with PIX version 6.3 and recently we have not been able to access a specific website from our Workstations (all the other sites are fine). As far as I know Workstations use a PAT Global Address, but we have a Server which is also behind the PIX and has a different IP assigned in the PIX config and we can browse the site from the server.


From the workstations the connection to the site just times out, from the server we have no problems. It isn´t a DNS problem and according to the people from the site we are not banned. Like I said my knowledge is basic and I was wondering if this is could be related to the PIX and figure out a possible solution.


Any ideas?.


Thanks in advance.

Correct Answer by Kevin Redmon about 6 years 12 months ago

Moises,


Thanks for the update.  I've had cases where that is the case - the end-server does some sort of DNS record lookup or Blacklist lookup to verify the requesting IP.  I've also seen issues where ISPs have inadvertently, unintentionally misrouted traffic back to (or rather, away from) the source or destination.


I'm glad that you were able to find a viable workaround.  In either case, please be sure to mark this post as 'Answered' so others can also benefit from the troubleshooting steps that you took in resolving this issue.


Thanks for using the SupportForums!  Have a great weekend!


Best Regards,

Kevin

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Kevin Redmon Wed, 06/30/2010 - 13:56
User Badges:
  • Cisco Employee,

Moises,


I would start with watching the syslogs - preferably at the 'debug' level.  The other three items to consider with Cisco (and possibly other) firewalls are:


1.) Permission


Make sure that an access-list allows the traffic and/or the implicit permit for high-to-low security traffic.


2.) Translations


Make sure that a translation is present for the traffic.  If everyone is PATed to a single outside IP address, be sure that all of these translations (roughly 65k) are not consumed.  You can watch the output of 'show xlate debug' at the time of the traffic to ensure that a translation is happening.  You should see a source interface and IP address and a destination interface and IP address that matches.  If this information doesn't make sense based on what you were expecting, you may choose to clear the xlate for that particular connection ('clear xlate...').


3.) Routes


Ensure that the routes for the relevant host is indeed pointing out the correct interface in the direction of the server.


After you confirm #1-3 above, the other things to check would be the status of the connection and/or connection syslogs.  If your connection Teardown syslog says 'SYN Timeout', this implies that the SYN was sent from the Firewall via the destination interface (as in #2 above), but we never received a response (or maybe the server never received the SYN).  If you see 'Reset-O' (and the server exists off of the lower-security interface), this is some Layer-3 device (possibly the server) resetting the connection.  A 'Reset-I' indicates that the inside host reset the connection (for instance, if the web browser got sick of waiting for the server or user hits 'Stop' on the session).


If you get the syslogs and they don't point you to an obvious answer, send them our way and we'll take a look (mask any IP addresses as you see fit).


Hope that helps,

Kevin

xxxMOISESxxx Thu, 07/01/2010 - 14:07
User Badges:

Thanks for the reply Kevin.


My problem was solved by changing the PAT Global Address to another IP (same as the PIX interface). That did it, so I think we are probably banned for some reason and they don't know or can't tell us.


One thing I noticed in the syslog is that the connection was not being torndown after the browser timed out. That seemed a little weird, no RESET or SYN errors, no Teardown at all.

Correct Answer
Kevin Redmon Thu, 07/01/2010 - 14:39
User Badges:
  • Cisco Employee,

Moises,


Thanks for the update.  I've had cases where that is the case - the end-server does some sort of DNS record lookup or Blacklist lookup to verify the requesting IP.  I've also seen issues where ISPs have inadvertently, unintentionally misrouted traffic back to (or rather, away from) the source or destination.


I'm glad that you were able to find a viable workaround.  In either case, please be sure to mark this post as 'Answered' so others can also benefit from the troubleshooting steps that you took in resolving this issue.


Thanks for using the SupportForums!  Have a great weekend!


Best Regards,

Kevin

Actions

This Discussion