Firewall ASA Rule

[sshishi1234]

Hi All

I ve enabled snmp on asa to allow dmz server access the monitoring server.

Its saying cant "UNKNOWN: Get https://10.56.130.114:18443/query/check_nscp_version: dial tcp 10.56.130.114:18443: connect: connection refused " But the rule is actually there

access-list DMZ-VMK-MGMT-IN line 1 extended permit tcp host 10.56.8.95 host 10.56.130.114 eq 18443 (hitcnt=0) 0x7a100304

access-list DMZ-VMK-MGMT-IN line 6 extended permit tcp host 10.56.130.114 host 10.56.8.95 eq 18443 (hitcnt=15) 0xf76c04e2

IE-FW01/pri/act# packet-tracer input DMZ-VMK-MGMT tcp 10.56.8.95 18443 10.56.130.114 18443 detailed

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.56.130.114 using egress ifc DMZ-VMK-MGMT

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffcb5cff10, priority=111, domain=permit, deny=true
hits=9, user_data=0x0, cs_id=0x0, flags=0x4000, 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=DMZ-VMK-MGMT, output_ifc=DMZ-VMK-MGMT

Result:
input-interface: DMZ-VMK-MGMT
input-status: up
input-line-status: up
output-interface: DMZ-VMK-MGMT
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Could there be an issue with priority level?

interface Port-channel1.41
vlan 41
nameif DMZ-VMK-MGMT
security-level 5
ip address 10.56.130.113 255.255.255.240
IE-FW01/pri/act#

the acl is there but its getting dropped by implicit deny, could this have somehitng to do with security levels?

Thanks Sinead

[Georg Pauwen]

Hello,

what is the security level of the other interface ?

[craig.armstrong]

Hi there,

A couple of things are missing to help me understand fully the issue, are you hair-pinning the traffic on the same interface ? I see the input and output if are the same.

Do you have the configuration in place to allow hair-pinning ?

Spoiler

By default, interface security levels do not have to be unique on an ASA. However, if two interfaces have the same security level, the default security policy will not permit any traffic to pass between the two interfaces at all. You can override this behavior with the same-security-traffic permit inter-interface command.

https://www.ciscopress.com/articles/article.asp?p=1924778&seqNum=5#:~:text=By%20default%2C%20interface%20security%20levels%20do%20not%20have%20to%20be,the%20two%20interfaces%20at%20all.

This is for the security level part of the question, if you are actually hairpinning on the same interface then you'd need

same-security-traffic permit intra-interface

Hope this helps you out

[sshishi1234]

yes i believe we are using hair pinning but i havent heard of this term before.... as per conf, the dms are all part of port-channel1.xx ( xx being a sub port intrerface) so yes the traffic is physically using same interface for traffic. However we are not loosing all traffic. Just dropping some sync from tcp handhsake

FW01/pri/act# sh nameif
Interface Name Security
GigabitEthernet0/6 outside 0
Management0/0 management 100
Port-channel1.41 DMZ-VMK-MGMT 5
Port-channel1.42 DMZ-VMK-ACC 4
Port-channel1.70 DMZ-WLAN-CLIENT 11
Port-channel1.71 DMZ-WLAN-INSTALL 15
Port-channel1.106 DMZ-CONFIG 12
Port-channel1.107 DMZ-STORE-CCTV 22
Port-channel1.108 DMZ-CCTV 22
Port-channel1.140 UC-Servers 80
Port-channel1.254 TEST 100
Port-channel1.331 VULNERABILITY_SCANNER 99
Port-channel1.353 HR-TRANS-FW 99
Port-channel1.555 Servers 90
Port-channel2 EXTRANET 100
Port-channel48.901 vodafone-outside 0
Port-channel48.933 DMZ_Expressway 10

FW01/pri/act# sh port-channel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
U - in use N - not in use, no aggregation/nameif
M - not in use, no aggregation due to minimum links not met
w - waiting to be aggregated
Number of channel-groups in use: 3
Group Port-channel Protocol Span-cluster Ports
------+-------------+---------+------------+------------------------------------
1 Po1(U) - No Gi0/0(P) Gi0/1(P)
2 Po2(U) LACP No Gi0/2(P) Gi0/3(P)
48 Po48(U) - No Gi0/4(P) Gi0/5(P)

FW01/pri/act# sh run int gi 0/0
!
interface GigabitEthernet0/0
channel-group 1 mode on
no nameif
no security-level
no ip address
IE-FW01/pri/act# sh run int gi 0/1
!
interface GigabitEthernet0/1
channel-group 1 mode on
no nameif
no security-level
no ip address

GigabitEthernet0/6 outside 0

[craig.armstrong]

I get it now, the 10.56.8.95 IP the IP of the actual ASA, which makes the packet-tracer wrong since the input of the traffic isn't DMZ-VMK-MGMT but is locally generated.
The command you are typing is asking the ASA what would happen to a packet that enters DMZ-VMK-MGMT with source IP 10.56.8.95 and destination IP 10.56.130.114, which is not the case.

If you are only loosing some packets and not all monitoring traffic then that would suggest it's not an issue with security zones or ACLs.
Maybe you should configure a packet capture on the firewall to see what it happening to the traffic:

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html#anc10