Solved: webvpn client SFR module drops http packets

Nele Valjak · ‎08-05-2016

Hi, I have configured WEBVPN access to ASA 5512 with SFR module long time ago and internal http links were worked just fine.

After upgrade ASA to 9.5 (2), FirePower module to 6.0.0-1005 and DefenseCentar to 6.0.0 (build 1005) I am unable to open internal http links (also CIFS is working fine at same time).

After I connect to WEBVPN, try to open "http://192.168.4.3" and then go to ASA monitoring, I can see these logs:

6   Aug 05 2016   19:11:32   302014   192.168.4.3   80   172.16.1.2   13215   Teardown TCP connection 5709589 for Internal:192.168.4.3/80 to identity:172.16.1.2/13215 duration 0:00:21 bytes 0 TCP Reset-O
4   Aug 05 2016   19:11:19   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
4   Aug 05 2016   19:11:19   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
4   Aug 05 2016   19:11:13   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
4   Aug 05 2016   19:11:13   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
4   Aug 05 2016   19:11:10   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
4   Aug 05 2016   19:11:10   434002                   SFR requested to drop TCP packet from identity:172.16.1.2/13215 to Internal:192.168.4.3/80
6   Aug 05 2016   19:11:10   302013   172.16.1.2   13215   192.168.4.3   80   Built outbound TCP connection 5709589 for Internal:192.168.4.3/80 (192.168.4.3/80) to identity:172.16.1.2/13215 (172.16.1.2/13215)

172.16.1.2 is ASA's internal IP and 192.168.4.3 is internal web server.

If I stop with traffic redirection to SFR module everything work fine. I have checked Access Policy on DefenseCenter, traffic is allowed as I can see in Connection Events.

Does any one have any idea what could be a problem here?

Is there a option to debug more detailed why SFR drops these packets?

Thanks!

Pujita Patni · ‎08-05-2016

Hi Nele,

I think you might be hitting a bug.

I understand that you have an allow rule for this traffic. But can you please create a trust rule from the ASA IP address to the internal services that should be accessible in your Access Control Policy.

Now, check if the traffic still gets dropped.

Thanks,

Pujita

Rate if it helps.

View solution in original post

Pujita Patni · ‎08-05-2016

Hi Nele,

I think you might be hitting a bug.

I understand that you have an allow rule for this traffic. But can you please create a trust rule from the ASA IP address to the internal services that should be accessible in your Access Control Policy.

Now, check if the traffic still gets dropped.

Thanks,

Pujita

Rate if it helps.

Nele Valjak · ‎08-05-2016

Hi, it works now! :)

Probably some IPS issue or rule...

Do you know how can I track or debug IPS or SFR rules which match and block this connection?

Thanks!

Pujita Patni · ‎08-05-2016

Hi Nele,

It was the below bug that you were hitting:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw38561/?reffering_site=dumpcr

Make sure you have logging enabled on this rule. You should then be able to see the traffic being matched in the Connection events. You can use this rule as a filter.

Thanks,

Pujita

Rate if it helps !