SNMPv3 issue with authentification

[AlbertasG]

Hello, I've encountered problem authenticating on both SNMPv3 to v1 and Forward proxy when switching to SNMPv3 auth.

From logs seems that USM user is created and credentials are passed well.

Python 2.7.5 snmpfwd==0.3.2 pysnmp==4.4.4 pycryptodomex==3.6.0

server.cfg:

config-version: 2 program-name: snmpfwd-server

snmp-credentials-group { snmp-transport-domain: 1.3.6.1.6.1.1.100 snmp-bind-address: 127.0.0.1:1161

snmp-engine-id: 0x0102030405070809

snmp-community-name: public

snmp-security-name: public

snmp-security-model: 3 snmp-security-level: 3

snmp-security-name: testuser123 snmp-usm-user: testuser123 snmp-usm-auth-protocol: md5 snmp-usm-auth-key: authkey123 snmp-usm-priv-protocol: des snmp-usm-priv-key: privkey123

snmp-credentials-id: snmp-credentials

}

Test trap i'm trying to send:

snmptrap -v 3 -n "" -a MD5 -A authkey123 -x DES -X privkey123 -l auth -u testuser1234 127.0.0.1:1161 '' .1.3.6.1.4.1.5089.1.0.1 .1.3.6.1.4.1.5089.2.0.999 s "123456"

Response from server:

root0@linux ~]$ /usr/bin/snmpfwd-server.py --config-file=/home/user1/server7.conf --log-level=debug 2018-04-11 13:30:48,246 INFO configuring snmp-credentials snmp-credentials (at .snmp-credentials-group)... 2018-04-11 13:30:48,267 INFO new engine-id 0x0102030405070809 2018-04-11 13:30:48,268 INFO new transport endpoint 127.0.0.1:1161, options , transport ID 1.3.6.1.6.1.1.100 2018-04-11 13:30:48,268 INFO new USM user testuser123, security-model 3, security-level 1, security-name testuser123 2018-04-11 13:30:48,275 INFO configuring peer ID 100 (at .peers-group)... 2018-04-11 13:30:48,275 INFO configuring context ID any-context (at .context-group), composite key: .?#.? 2018-04-11 13:30:48,276 INFO configuring content ID trap-content (at .content-group), composite key: (TRAPv1|TRAPv2|TRAPv3)#.*? 2018-04-11 13:30:48,276 INFO configuring destination trunk ID(s) trunk-1 (at .routing-map)... 2018-04-11 13:30:48,276 INFO configuring trunk routing to trunk-1 (at .routing-map), composite key: snmp-credentials/any-context/100/trap-content 2018-04-11 13:30:48,276 INFO configuring trunk ID trunk-1 (at .trunking-group)... 2018-04-11 13:30:48,276 INFO new trunking client from 127.0.0.1 to 127.0.0.1:30301 2018-04-11 13:30:48,276 INFO starting I/O engine... 2018-04-11 13:30:49,278 INFO TrunkingClient at 127.0.0.1:0, peer 127.0.0.1:30301: initiated trunk client connection from ('127.0.0.1', 0) to ('127.0.0.1', 30301)... 2018-04-11 13:30:49,279 DEBUG TrunkingClient at 127.0.0.1:0, peer 127.0.0.1:30301: trunk announcement sent 2018-04-11 13:30:49,279 INFO TrunkingClient at 127.0.0.1:0, peer 127.0.0.1:30301: client is now connected 2018-04-11 13:35:12,534 ERROR SNMPv3 auth failure at 127.0.0.1:1161 from 127.0.0.1:37736 using snmp-usm-user "testuser123": Unknown SNMP security name encountered 2018-04-11 13:35:13,002 ERROR SNMPv3 auth failure at 127.0.0.1:1161 from 127.0.0.1:51985 using snmp-usm-user "testuser123": Unknown SNMP security name encountered 2018-04-11 13:35:13,435 ERROR SNMPv3 auth failure at 127.0.0.1:1161 from 127.0.0.1:39172 using snmp-usm-user "testuser123": Unknown SNMP security name encountered

[etingof]

One thing is that in the configuration you have testuser123 while in snmptrap command you seem to use testuser1234. Is that just a typo in this issue?

The other thing is that when you send SNMPv3 traps you have to configure SNMP engine ID of your trap source (e.g. snmptrap -e) at the server part of snmpfwd. The reason is that TRAP is a unidirectional affair what does not let SNMP manager/agent to negotiate anything including SNMP engine IDs they use.

[AlbertasG]

Thanks for response, Ilya. Yes that "4" was a typo from tests I used. I believe I tried with - e EngineID, I'll double check it and inform you. The strange thing was when using example from SNMP v3tov1 SNMP walk went just fine and redirected. Maybe you tried to run the trap proxy from your latest builds? Any strange observations?

Many thanks, Albertas.

On Fri, 13 Apr 2018, 01:58 Ilya Etingof, notifications@github.com wrote:

One thing is that in the configuration you have testuser123 while in snmptrap command you seem to use testuser1234. Is that just a typo in this issue?

The other thing is that when you send SNMPv3 traps you have to configure SNMP engine ID of your trap source at the server part of snmpfwd. The reason is that TRAP is a unidirectional affair what does not let SNMP manager/agent to negotiate anything including SNMP engine IDs they use.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/etingof/snmpfwd/issues/20#issuecomment-380969382, or mute the thread https://github.com/notifications/unsubscribe-auth/AaJZELEl0Ebi7iItTwEQh6Ev_ECp20nmks5tn9wNgaJpZM4TP3QZ .

[etingof]

This may be the difference between SNMP commands and SNMP notifications as I have just mentioned. Make sure you are using the same SNMP engine ID at both SNMPv3 parties.

I do not see anything abnormal in your config or log so far. The message referring to unknown username may be caused by mismatching SNMP engine ID because internally users are indexed by SNMP engine ID.

[AlbertasG]

Resolved. Problem was EngineID not provided to snmptrap arguments.

[etingof]

\o/

I will add a note in the doc on that.