topic That also results in an allow in Network Security

External Server Needs SNMP from Internal Device through ASA5520

Sandra Proesch — Tue, 12 Mar 2019 06:48:11 GMT

We have an external vendor who has placed a device (several actually) on our internal network. We are using one external IP and natting to different devices inside by using different ports. This works fine for http and a couple of custom tcp ports they are using. What we cannot get to work is that they want to connect to one of the devices with UDP/161 (snmp). Even though I've used the same type of rules and nat that I did for the other ports, this is not working. The outside host still reports that port UDP/161 is not open. Inside we can determine that yes, the device is running the snmp service.

I think this may have something to do with the group policy on the ASA5520, but I'm not sure. I can do access rules and nat, but I'm not enough of an expert to really understand the rest of the configuration. Is there a good reference I can look at, or is anyone here doing something similar and can point me in the right direction?

Thanks for the help.

--Sandy

So it is the external server

Jon Marshall — Wed, 28 Oct 2015 20:14:22 GMT

So it is the external server that needs to send SNMP to the internal device ?

Just checking because your thread description suggests the other way round.

If so can you run this command on your ASA and post here -

"packet-tracer input outside udp <external server IP> 12345 <public IP of inside server> 161"

Jon

The external server will be

Sandra Proesch — Wed, 28 Oct 2015 20:26:04 GMT

The external server will be making the SNMP request to the internal device.

The packet trace results in action allow. Seems like this should mean it's working. Let me get back with the vendor and see if he's seeing it now. Thanks for your help. I'll post back when I've determined how it looks to the vendor now.

No, that didn't fix the

Sandra Proesch — Thu, 29 Oct 2015 12:57:50 GMT

No, that didn't fix the problem. Back to the drawing board.

Can you just check the other

Jon Marshall — Thu, 29 Oct 2015 13:15:39 GMT

Can you just check the other way ie.

"packet-tracer input inside udp <real server IP> 161 <external server IP> 12345"

Also is this device on the inside accessble via any other ports to the vendor ?

Jon

That also results in an allow

Sandra Proesch — Thu, 29 Oct 2015 14:17:15 GMT

That also results in an allow. And yes the device on the inside is accessible via port 80 to the vendor.

Think you might need a new

Jon Marshall — Thu, 29 Oct 2015 14:42:16 GMT

Think you might need a new vendor 🙂

Unless you are doing some sort of NAT on their source IP as it comes through your firewall and you haven't set that up for this connection I can't see what is wrong.

You would only need to do this type of NAT if the devices didn't send the traffic back to the ASA either direct or via other L3 devices internally.

It is unlikely this is the problem but I have seen it.

Other than that you are going to have to do some packet captures on the firewall I think to see if you are -

1) seeing the UDP packets leaving the inside interface to the device

and

2) seeing the return UDP packets on the inside interface being sent back from the device

This is a link on how to setup the capture but obviously you need to liase with your vendor to test and I would do it in a quiet time -

https://supportforums.cisco.com/document/69281/asa-using-packet-capture-troubleshoot-asa-firewall-configuration-and-scenarios

if you want to post the configuration by all means do and someone may spot something.

Jon

Thanks very much for the help

Sandra Proesch — Thu, 29 Oct 2015 14:42:17 GMT

Thanks very much for the help. You've pretty much confirmed what I thought. I'm going back to the vendor and ask him where if anywhere does he have this working!