URL not opening ...via PIX

Answered Question
Aug 12th, 2010
User Badges:

Hi All,

we have one https ulr of one of our customer...which is not opening from office... This URL is hosted over internet...

Normally we open url in two way...via enabling proxy & other is disabling proxy (just to following diff paths).

Access using any of above method does the patting over PIX 535 firewall (different pat)

This https url is not opening from Windows 7 Machines using without proxy.... but using proxy it opens.

However doing without proxy we can able to telnet to destination over port 443. that confirms we have necessry access from our source --pix to destination..

but still web open is not opening...

Yes from Win XP you use any method this url opens....

Win 7 from outside office net / other office where we have ASA firewall it opens..

Is their anythig to do with PIX...../ any method to drill this issue.

Please guide..

Correct Answer by Kureli Sankar about 6 years 11 months ago


Follow this link and add the fix to allow mss-exceed.

No need to change the MTU on the firewall.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jennifer Halim Thu, 08/12/2010 - 00:57
User Badges:
  • Cisco Employee,

Reading the problem description, if you are able to telnet on port 443 without the proxy from windows 7 PC outbound via the PIX firewall, that proves that there is nothing within the PIX firewall that is causing the issue that you are experiencing.

I would suggest that you try different browser with your testing if you were using IE for testing (eg: Opera, Mozilla, Google Crome).

yogesh.suryawanshi Thu, 08/12/2010 - 01:24
User Badges:


thanks for reply...we tried with many other browers too...

but still the issue is same.

This is only happing with win 7 in our office...but in our other office this is not a issue.

only difference is they have asa instead of PIX...

Please guide...

Jennifer Halim Thu, 08/12/2010 - 01:33
User Badges:
  • Cisco Employee,

You might want to try disabling the http inspection on the PIX and see if you still have the issue. What version of PIX are you running?

yogesh.suryawanshi Thu, 08/12/2010 - 01:47
User Badges:


PIX Version is 6.3(5)....

destination site it https...

still will it help? can u provide url which will help to understand it.

Also in our pix i dont see fix up for https...fixup protocol https 443 will help?

fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69


Jennifer Halim Thu, 08/12/2010 - 01:55
User Badges:
  • Cisco Employee,

It sounds strange that it works through Proxy, but it doesn't work through browser directly.

No, there is no inspection for https, only for http, so it doesn't apply in your case.

What did you get when you are trying to browse the website directly (which error code)? and if you bring this very same Windows 7 host outside the network, it works fine?

Is the Windows 7 host in the same subnet/directly connected to the PIX interface?

yogesh.suryawanshi Thu, 08/12/2010 - 02:28
User Badges:


We tried connecting same win 7 system, outside of firewall & it worked very well..

Please find the attached screen...when it fails to open the web page..

error 1 . Internet connection has been lost   -  (it can not be because at same time telnet to destination keeps on)

         2   The Website is temperorily unavailable ...(at same time from another win 7 system with proxy it is working)

         3.  DNS not reachable   (but we are able to resovled the name)


Last option of TLS & SSL has been already tried.

Please advise how we can isolate this issue...

Jennifer Halim Thu, 08/12/2010 - 05:03
User Badges:
  • Cisco Employee,

You might want to take a packet capture on the PIX inside and outside interfaces when you are trying to browse that website, and download the packet capture in pcap format to further review where it's failing.

PIX version 6.3.5 is pretty old version of code and it's already EOL, so potentially there might be bug that cause that issue. Here is the EOL notification for your reference:


You might want to upgrade the PIX to the latest interim of 6.3.5 or even upgrade to higher version. Please also be advised that PIX hardware itself has also reached EOL, and the replacement is ASA firewall. Here is the list of all PIX related EOL notifications for your reference:


yogesh.suryawanshi Thu, 08/12/2010 - 06:06
User Badges:

Thanks  halijenn,

You are true , its older IOS , being win7 the new OS issue could not see anywhere & it could be bug with this IOS.

one more thing we are trying to isolate this issue , that is with DNS , in all test inside our network w/o proxy we were using internal DNS.

While using same machine from outside ,DNS settings were outside DNS....it could be the possibility that 1st level resoluation is happening but somewhere it is not responding..becuase TCP session is ok all the time...Will keep you posted on this test..

Anyways ,Can you please guide through packet capture in PIX & its downloading method...



Jennifer Halim Thu, 08/12/2010 - 06:20
User Badges:
  • Cisco Employee,

Here we go:


If you are going to configure ACL, then capture on the inside interface, the ACL should match the inside host ip address and the web server ip address, while capture on the outside interface would then match the PATed ip address towards the web server ip address.

yogesh.suryawanshi Fri, 08/13/2010 - 01:45
User Badges:


One more observation for this issue which is isolating the internet PIX.

we have one more site from where this link iw working w/o proxy....& it uses same internet PIX to throw traffic to Internet.

Topology we have  for both sites are

Inside LAN -->Corp ASA 5510 .---> Internet PIX ---> Interenet Routers ---> Internet.

From Site W ..url is working (ASA5510 ver 8.2 (1) )

From Site K url is not working ....(ASA Version 7.2(3)

we tried to reach microsoft & as per microsoft Corp ASA is blocking some TLS packets due which it is not opening..

advise how can we go ahead with this.

Jennifer Halim Sat, 08/14/2010 - 16:53
User Badges:
  • Cisco Employee,

I would suggest that you try lowering the MSS value to 1300.

Command: sysopt connection tcpmss 1300

yogesh.suryawanshi Sun, 08/15/2010 - 00:53
User Badges:

Tried  but still it is not working...

Following is output taken from system, command prompt..

C:\Users\194645>ping -f -l 1300 medimmune.mdsol.com

Pinging medimmune.mdsol.com [] with 1300 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for
    Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),

C:\Users\194645>ping -f -l 1260 medimmune.mdsol.com

Pinging medimmune.mdsol.com [] with 1260 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Tried with setting up 1260 still not worked..

where could be issue & how we can isolate the same.



Kureli Sankar Sun, 08/15/2010 - 06:42
User Badges:
  • Cisco Employee,

1260 seems ok. May be doesn't respond to icmp.

Pls. try to see if you can load the page with the mss set to 1260.

If you are unable to load, then post the syslogs for that connection.


yogesh.suryawanshi Mon, 08/16/2010 - 01:02
User Badges:

Tried mss 1260 but still unable to load page.

but i see following mtu on interfaces.

do i need to change the interface mtu?

mtu outside 1500
mtu inside 1500
mtu DMZ 1500



yogesh.suryawanshi Mon, 08/16/2010 - 02:32
User Badges:

Following log is recorded on sys log which says it is MTU fragmentation issue on firewall.

Aug 16 2010 13:05:45: %ASA-4-419001: Dropping TCP packet from inside: Yogesh/63831 to outside:, reason: MSS exceeded, MSS 256, data 536

As earlier posted , i have tried downgrading MSS to 1260 but still unable to upload page....

Also mention that physical interfaces are configured with 1500 MTU i think may be because of that MSS 1260 set by sysopt command is not taking effect...Please correct me if i am wrong here.

Now , we clear what issue is....Many Many thanks to this Forum..

I'll appreciate if you can guide how we can resolve this...

sysopt connection tcpmss 1300 & also tried sysopt connection tcpmss 1260 as well.

Do we need to use MPF here? Please guide...now we are very close to our resolution..



edadios Mon, 08/16/2010 - 03:33
User Badges:
  • Silver, 250 points or more

With pings of 1260 set for -f appearing to work, with no errors like "Packet needs  to be fragmented but DF set."  The mtu and mss settings should really be  close enough to that value.

set the following on the pix:

mtu inside 1260

Then your mss should be less and follow

sysopt connection tcpmss 1200

Actually, according to http://www.cisco.com/en/US/tech/tk870/tk877/tk880/technologies_tech_note09186a008011a218.shtml

should be an mss of around 1220, but just try lowering until you get what works.

Also continue monitoring your logs, as they give you further idea, as you have already indicated.

If lowering the value still does not take, I suggest saving the configuration and reloading the firewall. Ensuring that you have mtu of 1260 or lower, and mss accordingly showing up after the reboot.

Hopefully it help you  get the issue resolved.


edadios Mon, 08/16/2010 - 13:42
User Badges:
  • Silver, 250 points or more

Unfortunately, you can not do MPF on version 6.3 pix code.

But if you are interested in upgrading to later version of the pix code, then definitely you can consider doing that instead.


yogesh.suryawanshi Mon, 08/16/2010 - 22:24
User Badges:

Hello All,

Finally we reached to resolution by applying MPF on outside interface of ASA.

Many thanks to every one, for posting valuables inputs to reach the resolution.

Now we are able to upload page successfully.

I still have following queries; will appreciate if you can answer the same.

Q1. This behavior is observed only on ASA IOS 7.0 but not in Version 8.0.  Understand that the 7.0 release introduces several new security enhancements, one of which is a check for TCP endpoints which adhere to the advertised Maximum Segment Size (MSS). So does this mean version 8.0 IOS doesn’t have this behavior..or the MPF is already coded in version 8.

Q2. If it is coded on version 8, then it must be placed with ACL for source any & destination any. So applying any – any is harmful

Q3. In MPF we have entered the command set connection advanced-options mss-map. What does it mean?

What is difference between sysopt connection tcpmss & MPF


Yogesh S


This Discussion