topic Glad to hear that it is in Network Security

Firepower Management still says: Interface 'DataPlaneInterface0' is not receiving any traffic

roesch4alc — Tue, 12 Mar 2019 08:41:16 GMT

Hi,

Im still stuck with the message, that you can read in the topic. I think my setup should work, because I created an acl, that redirects traffic to the SFR Modul. But it looks like, that FMC is not receiving andthing. In the moment there is not much data traversing the firewall, but there is traffic.

Im wondering, that "sh service-policy sfr" doesn´t show any hits! Any ideas? What can I do? I already rebootet the sfr modules.

Global policy:+
Service-policy: global_policy
Class-map: sfr
SFR: card status Up, mode fail-open
packet input 0, packet output 0, drop 0, reset-drop 0

Another question: Is it a problem to activate "enable monitor only" mode in a routed firewall mode? I would like to start with this setting, to be sure, that no datastreams will be modified in the first step.

Best regards

Sebastian

Is your class-map sfr set to

Rahul Govindan — Wed, 21 Dec 2016 12:49:02 GMT

Is your class-map sfr set to match all traffic, i.e 'permit ip any any'? Can you get the outputs of the following to confirm:

show run class-map
show run policy-map
show run service-policy

If all of the above look right, one step you can take is to re-apply the service-policy again.

no service-policy global_policy global
service-policy global_policy global

Monitor mode is usually recommended in a non-production environment, but if you are setting it up for the first time, you can start start with that to ensure SFR is receiving the data from the ASA and then move it into fail-open/close.

Also, to note, if you are seeing this on a standby ASA in a failover pair, this is expected as there should ideally be no traffic across that unit.

Hi Govindan,

roesch4alc — Wed, 21 Dec 2016 13:41:28 GMT

Hi Govindan,

here the output:

asa# show run class-map
!
class-map sfr
match access-list sfr_redirect
class-map inspection_default
match default-inspection-traffic

asa# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
description sfr
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
class sfr
sfr fail-open

asa# show run service-policy
service-policy global_policy global

asa# sh access-list sfr_redirect
access-list sfr_redirect; 1 elements; name hash: 0x41ab5d0f
access-list sfr_redirect line 1 remark SFR ACL
access-list sfr_redirect line 2 extended permit ip any any (hitcnt=244857) 0x06d5ebec

Any ideas? Should I try to reapply the the service policy?

Regards

Sebastian

Hi,

roesch4alc — Wed, 21 Dec 2016 14:01:30 GMT

Hi,

I also tried to reapply the policy, in this way, but it doesn´t change anything.

no service-policy global_policy global
service-policy global_policy global

Yup, the config looks correct

Rahul Govindan — Wed, 21 Dec 2016 14:04:54 GMT

Yup, the config looks correct. Go ahead and re-apply the service-policy.

Another troubleshooting step you can take before re-applying the policy is to run a packet-tracer to see the packet processing steps that the ASA for traffic traversing through.

The command for that is

packet-tracer input <inside-interface-name> match tcp <internal-ip-address> 12345 4.2.2.2 80 detailed

Hi,

roesch4alc — Wed, 21 Dec 2016 14:28:10 GMT

Hi,

first I found, that in my case "same-security-traffic permit inter-interface" was missing. I have several interfaces with the same security level. I added this. So now, the traffic seems to flow as expected.

What do you think? Afterwards I reapplied the service policy ones more. Still no change.

asa(config)# packet-tracer input MyInterface tcp 10.10.10.1 12345 10.30.30.1 80 detailed

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.20.20.1 using egress ifc transfer

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group MyInterface_access_in in interface MyInterface
access-list MyInterface_access_in extended permit ip any any
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f393330b3f0, priority=13, domain=permit, deny=false
hits=83739, user_data=0x7f3926fe0980, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=MyInterface, output_ifc=any

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f39309d0260, priority=0, domain=nat-per-session, deny=false
hits=1464, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f3933246ca0, priority=0, domain=inspect-ip-options, deny=true
hits=83791, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=MyInterface, output_ifc=any

Phase: 5
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map sfr
match access-list sfr_redirect
policy-map global_policy
description sfr
class sfr
sfr fail-open monitor-only
service-policy global_policy global
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f3933326fe0, priority=71, domain=sfr, deny=false
hits=17, user_data=0x7f393311b940, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=MyInterface, output_ifc=any

Phase: 6
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f39332358b0, priority=21, domain=lu, deny=true
hits=3, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, tag=any, dscp=0x0
input_ifc=MyInterface, output_ifc=any

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x7f39309d0260, priority=0, domain=nat-per-session, deny=false
hits=1466, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x7f3931457ee0, priority=0, domain=inspect-ip-options, deny=true
hits=185221, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=transfer, output_ifc=any

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 655901, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_sfr
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_sfr
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: MyInterface
input-status: up
input-line-status: up
output-interface: transfer
output-status: up
output-line-status: up
Action: allow

That is really strange. The

Rahul Govindan — Thu, 22 Dec 2016 03:40:56 GMT

That is really strange. The packet-tracer even shows the packet hitting the SFR module. Did you see any stats change after moving it to monitor-only mode? Also is your SFR policies pushed to the device from the FMC? You could session into the SFR and take a look at if the access policies show up.

BTW what is your ASA and SFR version? Just to make sure everything is compatible.

can you run command "show

Pranay Prasoon — Thu, 22 Dec 2016 07:00:58 GMT

can you run command "show module sfr detail" and see control plane is up?

Of course.

roesch4alc — Thu, 22 Dec 2016 09:59:56 GMT

Of course.

asa# sh modu sfr det
Getting details from the Service Module, please wait...

Card Type: FirePOWER Services Software Module
Model: ASA5525
Hardware version: N/A
Serial Number: xxx
Firmware version: N/A
Software version: 6.1.0-330
MAC Address Range: 00f6.632d.3562 to 00f6.632d.3562
App. name: ASA FirePOWER
App. Status: Up
App. Status Desc: Normal Operation
App. version: 6.1.0-330
Data Plane Status: Up
Console session: Ready
Status: Up
DC addr: 172.16.34.2
Mgmt IP addr: 172.16.33.211
Mgmt Network mask: 255.255.255.240
Mgmt Gateway: 172.16.33.222
Mgmt web ports: 443
Mgmt TLS enabled: true

Hi,

roesch4alc — Thu, 22 Dec 2016 10:04:48 GMT

Hi,

I checked, that polices are applied and up to date, FMC says, that everything is ok, regarding the policies. " Deployment to device successful."

You could session into the SFR and take a look at if the access policies show up.

--> How do I do that? Whats the command/procedure?

ASA Software is 9.6(2) and Firepower is 6.1.0. Everything looks good, but I don´t know whats wrong!

Please perform a few more

Pranay Prasoon — Thu, 22 Dec 2016 11:25:30 GMT

Please perform a few more test.

a) Generate some traffic and issue command "sh conn | in X" immediately. This will show if traffic is being sent to module.

b) Go to policies->network discovery->Edit the Networks (Make sure both host and application is checked). Save and deploy this.

Hi,

roesch4alc — Thu, 22 Dec 2016 13:04:02 GMT

Hi,

traffic is ongoing, and the acl hitcount grows.

sh conn only shows a summary:

asa# sh conn
21 in use, 27 most used

I tried with sh conn det all, but no connection with X ( X - inspected by service module,) flag is shown.

b)--> was already in place, but i saved it again.

I feel there is issue with

Farhan Mohamed — Thu, 22 Dec 2016 21:39:49 GMT

I feel there is issue with the updated version of this stuff, I would recommend you go with the update for ASA and the believe that will help you out.

Hi,

roesch4alc — Fri, 23 Dec 2016 10:05:06 GMT

Hi,

today the firewall was placed inline as the gateway for different interfaces. Now the sfr policy redirects traffic to the sfr module and firesight shows up with data...

I think the redirection only works, if connections are going through the asa. Before, there were only broadcasts or multicasts and these won´t be tracked...

So in the moment everything seems to be fine...

Just one more question... In the Summary Dashboard I see "Unique Applications over Time". On the X Axis, there the time is applied. The timezone in user Preferences is set to our local timezone, Berlin. But in the "Unique Applications over Time" Section, the time, is the local time of the SFR Module, that is not correct. See the attachement. Is there a way to correct this?

In contrast to that, the time is correct in Analysis-->Content Explorer--> "Traffic and Intrusion Events over Time".

Thanks to all,

Regards

Sebastian

Glad to hear that it is

Rahul Govindan — Fri, 23 Dec 2016 15:36:13 GMT

Glad to hear that it is finally working for you 🙂

The timezone for "Unique Applications Over Time" can be changed by clicking on the small arrow to the left corner of the Widget and changing the timezone dropdown option.

Picture attached.

Happy new Year!

roesch4alc — Mon, 02 Jan 2017 11:39:01 GMT

Happy new Year!

Thanks a lot, that tip is absolutely correct! In general I would recommend, that the timezone refers to the current users setting... Make more sense than to adjust every gadget for itself....

Sebastian