[Insider Sharing] Service manage feature utilization caveat

Hi Guys,

I would like to describe a funny situation that I encounter while I was trying to set up SNMP configuration on my USG6000 firewall.

Here I have a loopback interface which is used as the source interface for traps, which works fine (SNMP 162 outbound). However, the firewall is rejecting every SNMP message (SNMP 161 inbound) sent by our NMS. Here you can see the Loopback 0 configuration, the snmp-agent configuration and the security policy rule that controls the incoming packets towards the firewall, as well as the ACL and the IP address sets used: \\\ Sorry for the large amount of commands, I'm a CLI freak :)

interface LoopBack0

description INBAND_MGMT

alias INBAND_MGMT_29004_FW

ip address X.X.1.53 255.255.255.255

ospf cost 1

ospf network-type p2p

snmp-agent local-engineid 000007DB7F0000016FD75838

snmp-agent community read xxxxxxxxxxx

snmp-agent community write xxxxxxxxxxx

snmp-agent sys-info contact xxxxxxx

snmp-agent sys-info location xxxxxxxxxxxxx

snmp-agent sys-info version v3

snmp-agent group v3 v3group privacy read-view v3view write-view v3view notify-view v3view acl 2020

snmp-agent target-host trap address udp-domain x.x.30.6 params securityname xxxxxx v3 privacy

snmp-agent target-host trap address udp-domain x.x.16.6 params securityname xxxxxx v3 privacy

snmp-agent target-host trap address udp-domain x.x.6.6 params securityname xxxxxx v3 privacy

snmp-agent mib-view included v3view iso

snmp-agent usm-user v3 xxxx v3group authentication-mode sha xxxxxxxxxx

snmp-agent trap enable ipsec

snmp-agent trap enable l2tp

snmp-agent trap enable configuration

snmp-agent trap enable system

snmp-agent trap enable standard

snmp-agent trap enable srm

snmp-agent trap source LoopBack0

acl number 2020

rule 5 permit source xx.x.6.0 0.0.0.255

rule 10 permit source x.x.22.0 0.0.0.255

rule 15 permit source x.x.30.0 0.0.0.255

rule 100 deny

rule name "INBOUND MGMT UNTRUST > LOCAL"

policy logging

source-zone untrust

destination-zone local

source-address address-set INBOUND_MGMT

action permit

[core]display ip address-set verbose INBOUND_MGMT item

08:18:00 2016/06/02

Address-set: INBOUND_MGMT

Type: object

Item number(s): 1

Reference number(s): 2

Item(s):

address 0 x.x.30.0 mask 24

[core]display ip address-set verbose 41 item

08:18:27 2016/06/02

Address-set: 41

Type: group x

Item number(s): 2

Reference number(s): 2

Item(s):

address 0 address-set NMS

address 1 address-set NMS2

[core]display ip address-set verbose NMS item

08:18:47 2016/06/02

Address-set: NMS

Type: object

Item number(s): 1

Reference number(s): 1

Item(s):

address 0 x.x.6.16 mask 32

[core]display ip address-set verbose NMS2 item

08:18:51 2016/06/02

Address-set: NMS2

Type: object

Item number(s): 1

Reference number(s): 1

Item(s):

address 0 x.x.6.17 mask 32

Firewall version

display version

12:04:39 2016/06/03

Huawei Versatile Security Platform Software

Software Version: USG6600 V100R001C30 (VRP (R) Software, Version 5.30)

USG6650 uptime is 4 weeks, 3 days, 1 hour, 11 minutes

So everything looks great, but when I'm trying to walk the firewall OIDs, I'm getting a big TIMEOUT. So what's the problem? Dr. WoW can you help me?

[root@nmS ~]# snmpwalk -v3 -l authPriv -u xxxxx -x AES -X xxxxxx -a SHA -A xxxxxx x.x .1.53:161 IF-MIB::ifAlias

snmpwalk: Timeout

Let me show you how I start my investigations:

1. Test ping and SSH connection from my NMS to the firewall. It looks like it's working.

[root@nms ~]# ping x.x.1.53

PING x.x.1.53 (x.x.1.53) 56(84) bytes of data.

64 bytes from x.x.1.53: icmp_seq=1 ttl=252 time=6.40 ms

64 bytes from x.x.1.53: icmp_seq=2 ttl=252 time=6.27 ms

--- x.x.1.53 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4005ms

rtt min/avg/max/mdev = 5.939/6.173/6.409/0.204 ms

[root@nms ~]# telnet x.x.1.53 22

Trying x.x.1.53...

Connected to x.x.1.53.

2. Check the firewall session table, there is nothing related to SNMP. This means that the SNMP get is not reaching the firewall OR the firewall is dropping the packets before setting a session.

3. At this point I decided to enable firewall traffic statistics to find whether the firewall is dropping packets. How to do this?

A. Create an ACL to match the communication flow between NMS and USG.

acl number 3999

rule 10 permit ip source x.x.30.6 0 destination x.x.1.53 0

rule 20 permit ip source x.x.1.53 0 destination x.x.30.6 0

B. Enable statistics on the firewall.

<HUAWEI>system-view

14:26:41 2016/06/03

Enter system view, return user view with Ctrl+Z.

[HUAWEI]diag

[HUAWEI]diagnose

[HUAWEI-diagnose]firewall statistic acl 3999 enable

C. Try walking the OID again against the firewall.

D. Check the firewall statistics, collect the output

[HUAWEI-diagnose]display firewall statistic acl

E. Close statistics.

[HUAWEI-diagnose]undo firewall statistic

14:29:58 2016/06/03

Stop the ACL statistic

So what's there interesting fact I discover in the firewall traffic statistics logs?

the following error,

...........

Discard detail information:

IF_SERVICE_MANAGER_PACKET_FILTER: 6

............

means that interface service manage module is dropping the packets.

So let's analyze a little bit deeper:

The firewall loopback interface is routed to my core network via the vlan interface 999.

interface Vlanif999

ip address x.x.1.1 255.255.255.252

ospf cost 1

ospf bfd enable

service-manage https permit

service-manage ping permit

service-manage ssh permit

I decided to consider the alarm from firewall statistics and enable "service-manage snmp permit" under this vlan interface.

Surprize, the SNMP walk started to work, but checking the firewall session table it shows the traffic flow is not matching any security policy. So, let's put all the information together.

With the initial service manage configuration, we can consider that there is a command that is denying all the SNMP traffic coming towards the vlan interface

interface Vlanif999

ip address x.x.1.1 255.255.255.252

ospf cost 1

ospf bfd enable

service-manage https permit

service-manage ping permit

service-manage ssh permit

servide-manage SNMP deny

As soon as you enable SNMP all this type traffic will bypass security policy engine and will be processed further.

It's best to disable the service manage function and let firewall process the incoming SNMP traffic through the configured security policies.

<sysname> system-view

[sysname] interface Vlanif999

[sysname-Vlanif999]undo service-manage enable

"Service-manage enable" commands are only used to quickly configure, SSH, Telnet, HTTPS access to firewall in order to avoid configuring security policy, just for easy management. A firewall should control all the incoming traffic flows through security policies, which finally offers better granularity, control and security.

I hope you enjoy reading this. Cheers!