fwsm stateful inspection

Unanswered Question
Jan 29th, 2010

It is clear that the FWSM is a stateful firewall but I'm confused when it comes to the inspect statements.  Is the FWSM still a stateful device if there are no inspect statements in the global inspection policy?  I'm confused as to why you cannot inspect https traffic.

Basically is there any reason for the response HTTPS traffic to be blocked

REQUEST

server (inside) makes https(443) request to outside---> permit ip any any outbound --> server (ouside) responds (random port) ---> no acl needed inbound because FW is stateful....right???

Thanks in advance for clarification on this as I'm having trouble finding a straight answer on this.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Ganesh Hariharan Sun, 01/31/2010 - 07:18

It is clear that the FWSM is a stateful firewall but I'm confused when it comes to the inspect statements.  Is the FWSM still a stateful device if there are no inspect statements in the global inspection policy?  I'm confused as to why you cannot inspect https traffic.

Basically is there any reason for the response HTTPS traffic to be blocked

REQUEST

server (inside) makes https(443) request to outside---> permit ip any any outbound --> server (ouside) responds (random port) ---> no acl needed inbound because FW is stateful....right???

Thanks in advance for clarification on this as I'm having trouble finding a straight answer on this.

Hi,

Multiple vulnerabilities exist in the Cisco Firewall Services Module       (FWSM). These vulnerabilities occur in the processing of specific Hypertext       Transfer Protocol (HTTP), Secure HTTP (HTTPS), Session Initiation Protocol       (SIP), and Simple Network Management Protocol (SNMP) traffic. All of these vulnerabilities may result       in a reload of the device.

Check out the belwo link hope that clears out your query !!

http://www.cisco.com/warp/public/707/cisco-sa-20070214-fwsm.shtml

If helpful do rate

Ganesh.H

Panos Kampanakis Sun, 01/31/2010 - 08:18

Http inspection check protocol conformance and also can block urls etc.

Response from http/s server should be to you clients source port, not random port. Then the inspection, as long as it has seen the intial packets should not drop the response.

Check you logs to see if it dropped why it is dropped.

Also a "sh service-policy" will show you if the inspection is dropping something for http.

PK

Actions

This Discussion