I've came up with a problem configuring SNMP monitoring of remote site. I need to monitor 5 switches on their LAN using SNMP. There is a firewall doing NATing. I've checked the forum and some people say SNMP cannot be done over NAT, some say if you do Static NAT it should work, that's a bit confusing. Could anybody explain is it possible to do that please?
If I use these methods of nat translation, for example:
1. 10.10.1.1(Source lan ip) port 161 to 22.214.171.124(Destination wan ip) port 10161
10.10.1.2(Source lan ip) port 161 to 126.96.36.199(Destination wan ip) port 10162
2. 10.10.1.1(Source lan ip) port 161 to 188.8.131.52(Destination wan ip) port 161
10.10.1.2(Source lan ip) port 161 to 184.108.40.206(Destination wan ip) port 161
3. Use something else? OID or MIB ?
Highly appretiate your help guys as I need it up and running like yesterday.
Our side is properly configured so there is no issue there, as we can monitor other devices once you put their WAN IP addresses.
Remote side is really straight forward. One core C3750 switch and other 4 switches C2960 and C3750 connected to it. All of them configured with snmp-community and ACL list permitting our WAN ip address (monitoring side). The default gateway is CheckPoint firewall doing NATing. We added a NAT rule like no.2 above, and I think it should automatically add ACL rule to allow SNMP traffic.
Do you think Static NAT is fine and it should work, so SNMP traffic can be translated using static NAT rule? But the problem with ACL?
I had a similar issue with multiple CPE devices at a client site. I did attempt to perform the PAT on the edge, however, the SNMP server downstream would just view the same socket of srcip:162 and could never differentiate between the different hosts. Could you stand up some for of routing tunnel (i.e. IPsec, GRE) so you can natively communicate to the source IP addresses of the seperate subnet. Even if there was a subnet conflict for any reason you could alway implement intermediate NATs.
I punted this problem around for awhile and eventually realize the tunnel was just the easiest route.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...