<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SNMP/AAA access to an external switch? in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/snmp-aaa-access-to-an-external-switch/m-p/3187602#M1065918</link>
    <description>&lt;P&gt;Ableton,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It sounds like you want to use in-band management for the external switch and are using NAT on your firewall. For most NAT configurations, no special configuration is needed for communications originating from the inside of your network. Therefore, SSH and SNMP polling initiated from the inside of your network will be allowed out to the switch (firewall permitting) and the return traffic for the&amp;nbsp;matching flow will be allowed back inside based on the NAT table entries established by the outbound connection. As this switch is external to your firewall but has remote administration enabled, be sure to block those protocols on all but the expected interfaces&amp;nbsp;using an ACL. Moving on, the communications originating from the switch destined for the inside of the network will not have a NAT entry so will be dropped. To resolve this you will need to create a static port mapping. On a Cisco router you would type something like 'ip nat inside source static tcp 10.0.0.10 49&amp;nbsp;132.16.0.1 49 extendable' to enable authentication&amp;nbsp;using the&amp;nbsp;TACACS+ protocol (where &lt;SPAN&gt;10.0.0.&lt;/SPAN&gt;&lt;SPAN&gt;10:&lt;/SPAN&gt;&lt;SPAN&gt;49 is your server's IP:port and&amp;nbsp;132.16.0.1:49 is&amp;nbsp;the IP:port you want&amp;nbsp;the&amp;nbsp;server to be accessible from on the outside&lt;/SPAN&gt;). You can also change the external port from the default of 49 to something else in order to obfuscate the external communications or ensure that port is open for later use. You do this when defining the TACACS server in the switch configuration. For older IOSs, the syntax was 'tacacs-server host [IP Address] port [port #] key [shared secret]', but I believe it is nested in sub-configurations now.&lt;/P&gt;</description>
    <pubDate>Thu, 21 Sep 2017 18:06:33 GMT</pubDate>
    <dc:creator>Rich Uline</dc:creator>
    <dc:date>2017-09-21T18:06:33Z</dc:date>
    <item>
      <title>SNMP/AAA access to an external switch?</title>
      <link>https://community.cisco.com/t5/network-security/snmp-aaa-access-to-an-external-switch/m-p/3187365#M1065917</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We have an external switch which links our core firewalls to a private network in the internet.&lt;/P&gt;&lt;P&gt;This switch is not currently able to be managed from our internal network via SNMP or with ACS/AAA Tacacs etc.&lt;/P&gt;&lt;P&gt;I want to know the best way of securely being able to manage it remotely and monitor it on our monitoring platform.&lt;/P&gt;&lt;P&gt;The link between the core firewalls and the Cisco switch is a basic trunk link at the moment.&lt;/P&gt;&lt;P&gt;Would I use NAT/PAT, place an external address on the switch on an interface then NAT to it from the core FW's?&lt;/P&gt;&lt;P&gt;What other rules would I need etc?&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 14:20:28 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/snmp-aaa-access-to-an-external-switch/m-p/3187365#M1065917</guid>
      <dc:creator>Ableton34</dc:creator>
      <dc:date>2020-02-21T14:20:28Z</dc:date>
    </item>
    <item>
      <title>Re: SNMP/AAA access to an external switch?</title>
      <link>https://community.cisco.com/t5/network-security/snmp-aaa-access-to-an-external-switch/m-p/3187602#M1065918</link>
      <description>&lt;P&gt;Ableton,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It sounds like you want to use in-band management for the external switch and are using NAT on your firewall. For most NAT configurations, no special configuration is needed for communications originating from the inside of your network. Therefore, SSH and SNMP polling initiated from the inside of your network will be allowed out to the switch (firewall permitting) and the return traffic for the&amp;nbsp;matching flow will be allowed back inside based on the NAT table entries established by the outbound connection. As this switch is external to your firewall but has remote administration enabled, be sure to block those protocols on all but the expected interfaces&amp;nbsp;using an ACL. Moving on, the communications originating from the switch destined for the inside of the network will not have a NAT entry so will be dropped. To resolve this you will need to create a static port mapping. On a Cisco router you would type something like 'ip nat inside source static tcp 10.0.0.10 49&amp;nbsp;132.16.0.1 49 extendable' to enable authentication&amp;nbsp;using the&amp;nbsp;TACACS+ protocol (where &lt;SPAN&gt;10.0.0.&lt;/SPAN&gt;&lt;SPAN&gt;10:&lt;/SPAN&gt;&lt;SPAN&gt;49 is your server's IP:port and&amp;nbsp;132.16.0.1:49 is&amp;nbsp;the IP:port you want&amp;nbsp;the&amp;nbsp;server to be accessible from on the outside&lt;/SPAN&gt;). You can also change the external port from the default of 49 to something else in order to obfuscate the external communications or ensure that port is open for later use. You do this when defining the TACACS server in the switch configuration. For older IOSs, the syntax was 'tacacs-server host [IP Address] port [port #] key [shared secret]', but I believe it is nested in sub-configurations now.&lt;/P&gt;</description>
      <pubDate>Thu, 21 Sep 2017 18:06:33 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/snmp-aaa-access-to-an-external-switch/m-p/3187602#M1065918</guid>
      <dc:creator>Rich Uline</dc:creator>
      <dc:date>2017-09-21T18:06:33Z</dc:date>
    </item>
  </channel>
</rss>

