ASA: The outside-IF cannot be used for encrypted monitoring traffic

[swscco001]

Hello everybody,

our customer has a ASA5516 OS rel. 9.16(4).

Because of another issue Cisco said the monitoring have to use the outside-IF
instead the inside-IF for ping, SSH and SNMP.

The ASA is in a remote site and all traffic goes though a S2S-tunnel.

On the ASA in the main site I see the ping, SSH- and SNMP-requests arriving
in the capture and the IP address of the monitoring station (10.10.40.86)
and of the outside-IF (109.A.B.C) are in the crypto-ACLs mirrored on both
ASAs. The tunnel is working well.

It seems to me that the requests from the monitoring station stay unreplied
because it is requesting the outside-IF.

It is impossible to make the outside-IF to the Management Access Interface
because it has the lowest security-level.

The following commands are in the default config:

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

What can I try to use the outside-IF for the monitoring and get replies to
the requests? Perhaps a special NAT?

I have attached the configuration of the remote ASA.

Every hint is welcome!

Thanks a lot!

Bye
R.

[MHM Cisco World]

add OUTside interface IP to ACL of VPN and check again

You already add it to acl, missing this part.

thanks

MHM

[tvotna · Accepted solution]

Hard to say. I believe you don't need any NAT for this traffic, but you configured two:

nat (inside,outside) source static DM_INLINE_NETWORK_23 DM_INLINE_NETWORK_23 destination static DM_INLINE_NETWORK_13 DM_INLINE_NETWORK_13 no-proxy-arp route-lookup
nat (outside,outside) source static 10.10.40.86 10.10.40.86 destination static 109.A.B.C 109.A.B.C no-proxy-arp route-lookup

On the other hand, it's unclear whether it fails because of the above NAT rules (unlikely) or due to some other reason. Can you collect capture on the internal nlp_int_tap interface and send SNMP request over the tunnel? Then share outputs as shown below. You should see request and response. The 169.254.x.y is an internal IP address SNMP server listens on (the destination 109.A.B.C will be NATed to it). The reply can be traced and we will see how it's processed inside the system.

capture cap1 type raw-data trace detail interface nlp_int_tap match udp any any eq 161

ASA# sh cap cap1

46 packets captured

1: 21:31:55.045209 10.60.143.20.56902 > 169.254.1.2.161: udp 64
2: 21:31:55.045545 169.254.1.2.161 > 10.60.143.20.56902: udp 134

ASA# sh cap cap1 trace packet-number 2

72 packets captured

2: 21:31:55.045545 169.254.1.2.161 > 10.60.143.20.56902: udp 134
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fc463228ec0, priority=13, domain=capture, deny=false
hits=181, user_data=0x7fc469a17840, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=nlp_int_tap, output_ifc=any

Phase: 2
Type: ACCESS-LIST
...

[Sheraz.Salim]

Good responce by @tvotna but do think this nat rule is not required and this is a wrong rule.

nat (outside,outside) source static 10.10.40.86 10.10.40.86 destination static 109.A.B.C 109.A.B.C no-proxy-arp route-lookup

you can capture the packet on interface nlp_int_tap. and also capture the asp drop. would be great if you get the logging entries too for this issue.

[swscco001]

Hi tvotna,

deleting the NAT command:

nat (inside,outside) source static DM_INLINE_NETWORK_23 DM_INLINE_NETWORK_23 destination static DM_INLINE_NETWORK_13 DM_INLINE_NETWORK_13 no-proxy-arp route-lookup

 has solved the issue.

Thanks a  lot!



Bye
R.