PIX 515E will not connect to a certain portion of a Canadian Website 1

[shirelabs]

We are attempting to access

http://patents1.ic.gc.ca/intro-e.html

and are unable to display the page. We are able to access

http://www.gc.ca

which , as we understand, is the root of the site.

The rough framework of the network is (from outside -in):

Cisco 1720 to PIX515E To Bluecoat SG400 to Baracuda to Internal Switch Fabric.

Troubleshooting: We have eliminated everything past the 1720 and are able to reach the site. Adding the PIX515E results in inability to connect. We have hooked up a laptop to our Sprint dial-up service and are able to connect. All signs seem to point towards the PIX515E. At this point, we don't know where in the PIX515E to look when it appears that only a portion of a site is unable to be accessed. Ideas?

 

[lambent]

Your result of telnetting to port 80 appeared to me that actually the HTTP service of that host ic.gc.ca is active to you and it's accessible via the http protocol.

Are you using M$ IE or other browser? And what is the error code on the error page that displayed when you tried to access ic.gc.ca?

 

[shirelabs]

We use M$ IE6 with all updates or Firefox 1.4.

The error we get is:
Page can not be displayed.

An interesting development this weekend....
We again attempted to troubleshoot the issue by removing the Bluecoat device from the path. the interesting thing that we noticed was, when we attempted our troubleshooting we tried from a PC that we had not previously tested from and got connected. Further investigation revealed that this machine has a static route within the PIX515E that NAT's the PC's address to a different address than the one that the rest of our pool is tied to.

We were able to reproduce another working machine by adding a host to the PIX515E and Nat'ing that PC to an additional outside address in our range. This suggests to us that there must be something tied to the specific address that we NAT our pool to within the PIX515E.

The question remains, WHAT?

 

[lambent]

Let me summarize your testing a little bit. Please correct me if I'm wrong.

Scenario 1 with Bluecoat:
Testing PC: PC-A
NAT public IP of PC-A: IP-A
HTTP access to ic.gc.ca: FAILED

Scenario 2 without Bluecoat:
Testing PC: PC-B
NAT public IP of PC-B: IP-B
HTTP access to ic.gc.ca: SUCCESS
Testing PC: PC-C
NAT public IP of PC-C: IP-B
HTTP access to ic.gc.ca: SUCCESS

So did you test PC-A in Scenario 2 using both IP-A and IP-B?

 

[shirelabs]

Not quite right.

Scenario 2 without Bluecoat:
Testing PC: PC-B
NAT public IP of PC-B: IP-B
HTTP access to ic.gc.ca: SUCCESS
Testing PC: PC-C
NAT public IP of PC-C: IP-C
HTTP access to ic.gc.ca: SUCCESS

The PC-C was NAT'ed to a 3rd IP address in our external range. PC-A and the rest of the internal PC's report as IP-A. Therefore, The issue appears to be with the PIX515E and its treatment of IP-A.

 

[lambent]

Did you try to use IP-A on PC-B and PC-C to test in Scenario 2?

 

[shirelabs]

Yes, i tried IP-A on PC-b and PC-C. It did not work with or without the Bluecoat in place and active.

Developments:

I have spent some time on the phone with Bluecoat support and after a bit of tweaking to the config. we are now able to get PC-B and PC-C through to

http://ic.gc.ca

with the Bluecoat on and operating. That is one stopper removed.

We remain, however, at an impasse to get PC-A with IP-A through to the site regardless of whether the Bluecoat is present or not.

As a reminder, all inhouse PC's are Nat'ed to report IP-A as their address so, this issue effects all PC's in my network with the exception of PC-B and PC-C which are NAT'ed to IP-B and IP-C.

 

[lambent]

Did you try to clear the xlate table on your PIX and try PC-A with IP-A again?

On the other hand, I would suggest you to connect a hub or switch with port-mirror between the Cisco 1720 router and the PIX firewall and place a sniffer there. If you don't have a sniffer software, you can try Ethereal and it's free.

Capture the packet between the router and the PIX and analyse the HTTP traffic to and from a "normal" web site and the "ic.gc.ca" web site. Compare the results and see if there're any differences.

It's even better to place another sniffer between the bluecoat and the PIX.

 

[shirelabs]

I did a clear xlate against the PIX515E and attempted connection with PC-A with IP-A and had no success.

I will have to wait for this weekend to try to set up the sniffer.

Thanks for all your assistance to this point Lambent! I'll let ya know how things turn out.

 

[Stormflight]

Hi guys

Been following this post for a bit because we seem to have the exact same problem.

We get the same results when we try to get to 192.197.183.x

We use a PIX 515e as well with os 6.3.3. Behind we have a websence running off a windows server.

We turn off the websence, and still can not get to 192.197.183.x. We have a dialup account with the same provider, and that allows us to have access.

Let me know if you need any more info, since we have users that need access to those web sites, and no solution yet.

 

[shirelabs]

Hi all. Small update here.

We still have not hooked up the sniffer but hope to do so soon. The new news is, we've had a small brainstorming session in house and come up with a germ of an idea. Best as I can describe it, here goes.....

We do PAT'ing (Port Address Translation) on our PIX515E. What we have come up with is that in our scenario, IP-A is our Publically Nat'ed address that shows up to the outside world however, IP-A is NAt'd via PAT'ing which means that the requesting port is likely not in the acceptable range of port requests that

http://ic.gc.ca

accepts. This theory only seems to be further confirmed by the fact that when we statically configure IP-B and IP-C to go out, they successfully connect because they are likely requesting on port 80 as they do not need to PAT due to being single unique address'. This, if true, would also mean that none of our PC's connected to the pooled address (IP-A) would ever connect because the PAT'ing would almost without exception, never assign a port within

http://ic.gc.ca

limits.

So, all this said, what are our solutions here? Well...The quick and dirty solution is to just statically assign an address to the one PC in the building that has a need to get to this site and then Statically nat that address out to the free-world. Ugly, but yet workable. the only other suggestion that we could see would be to request that ic.gc.ca open up their acceptable port request range. Obviously, that ain't gonna happen.

With this idea in mind, does anyone else see validity to our thought and if so, does anyone have any other possible solutions in mind?

 

[Stormflight]

I calles up Industry canada, since my users say that they had access to the site 3 weeks ago, and they told me that there web site now does a reverse DNS lookup.

They told me to send them my IP address and some other info, and thay would look into it. Hopefully I'll get an answer soon. Will let you know on monday if that worked out or not.

 

[lambent]

Only the http server is listening to a fixed port which is the destination port of your http client and it will not be changed no matter you're doing static or dynamic inside source NAT/PAT.

The source port of your http clients should be a random port within the public range and it should be within the same range after NAT/PAT. If that web site only allows certain source ports within the public range, then no matter you're using 1-to-1 NAT or 1-to-many PAT, you may still be blocked if by chance you're using a port outside its allowable range or the PAT assign a port outside its allowable range.

 

[Stormflight]

This is what I got from Industry Canada Tech support. Hope it helps you out


It was brought to our attention that you are experiencing connection issues with one of the strategis websites.
Please be advise that most Industry Canada website perform a reverse lookup of the connecting IP. If the reverse DNS answer is different from the connecting IP (PTR record) the connection is blocked.

It appears that the connecting IP used to access the site has a conflicting PTR record. You will not be able to access the site until this is addressed.

Your ISP and/or DNS server administrator should be contacted to resolve the issue. A PTR record needs to be added for the connecting IP.