OIDfilter config #37

Pelleplast · 2019-02-19T08:30:39Z

Hi! So I'm trying to configure OIDfiltering to be able to restrict users in the MIBtree based on both their IP and community string. I have a Proxy behind a firewall. The firewall redirects the traffic to the proxy. I'm having problem getting respons from my manager (with public IP) when I'm running this line.

snmpget -v2c -c test 213.79.163.67:161 1.3.6.1.2.1.2.2.1.8.2

This is the respons from that.

Timeout: No Response from 192.168.1.100.

If i run this command from the proxy i get respons but can i query any OID i want so the filtering doens't work

snmpget -v2c -test 192.168.1.100 1.3.6.1.2.1.2.2.1.8.2

but with -v1 i get

Timeout: No Response from 192.168.1.100.

I don't know If I've missunderstood the config or what it is.

This is my server conf

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

test-1 {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address: PublicIP:161
  snmp-engine-id: 0x0102030405070809
  snmp-community-name: test
  snmp-security-name: test-user
  snmp-security-model: 2
  snmp-security-level: 1
  snmp-credentials-id: test-1
}

context-group {
  snmp-context-engine-id-pattern: .*?
  snmp-context-name-pattern: .*?
  snmp-context-id: any-context
}

content-group {
  snmp-pdu-type-pattern: (GET|SET|GETNEXT|GETBULK)
  snmp-pdu-oid-prefix-pattern-list: .*?
  snmp-content-id: any-content
}

peers-group {
  snmp-transport-domain: 1.3.6.1.2.1.2.2.1.8.1
  snmp-bind-address-pattern-list: .*?
  snmp-peer-address-pattern-list: .*?
  snmp-peer-id: 100
}

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins/

plugin-group {
  plugin-module: oidfilter
  plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf log-denials=true
  plugin-id: permit-system-branch
}

trunking-group {
  trunk-crypto-key: 1234567890
  #Endpointaddress för trunk
  trunk-bind-address: 192.168.1.100
  trunk-peer-address: 192.168.1.100:30301
  trunk-ping-period: 60
  trunk-connection-mode: client
  trunk-id: trunk-1
}

routing-map {
  matching-snmp-context-id-list: any-context
  matching-snmp-content-id-list: any-content
  matching-snmp-credentials-id-list: test-1
  matching-snmp-peer-id-list: 100
  using-plugin-id-list: permit-system-branch
  using-trunk-id-list: trunk-1
}

And my client conf

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

peers-group {
  snmp-engine-id: 0x0102030405070809
  snmp-transport-domain: 1.3.6.1.6.1.1.1
  #Originate SNMP packets from this transport address endpoint
  snmp-bind-address: 0.0.0.0:0
  snmp-peer-timeout: 100
  snmp-peer-retries: 1
  snmp-community-name: test
  #Idintifier that logically groups SNMP configuration settings together.
  snmp-security-name: testing
  #Snmp v1, v2c eller v3
  snmp-security-model: 2
  #1=no auth, 2=auth no encry, 3=aut/encry
  snmp-security-level: 1
  #Send SNMP packets to this network address
  snmp-peer-address: PublicIP
  snmp-peer-id: snmplabs
}

trunking-group {
  trunk-bind-address: 192.168.1.100:30301
  trunk-ping-period: 60
  trunk-connection-mode: server
  trunk-id: <discover>
}

original-snmp-peer-info-group {
  orig-snmp-bind-address-pattern: .*?
  orig-snmp-context-name-pattern: .*?
  orig-snmp-pdu-type-pattern: .*?
  orig-snmp-oid-prefix-pattern: .*?
  orig-snmp-engine-id-pattern: .*?
  orig-snmp-context-engine-id-pattern: .*?
  orig-snmp-transport-domain-pattern: .*?
  orig-snmp-peer-address-pattern: .*?
  orig-snmp-security-level-pattern: .*?
  orig-snmp-security-name-pattern: .*?
  orig-snmp-security-model-pattern: .*?
  orig-snmp-peer-id: manager-1
}

server-classification-group {
  server-snmp-credentials-id-pattern: .*?
  server-snmp-context-id-pattern: .*?
  server-snmp-content-id-pattern: .*?
  server-snmp-peer-id-pattern: .*?
  server-classification-id: any-classification
}

routing-map {
  matching-trunk-id-list: trunk-1
  matching-orig-snmp-peer-id-list: manager-1
  matching-server-classification-id-list: any-classification
  using-snmp-peer-id-list: snmplabs
}

The text was updated successfully, but these errors were encountered:

etingof · 2019-02-19T09:29:15Z

Could you post some relevant logs from server and perhaps from oidfilter plugin please?

Pelleplast · 2019-02-19T09:35:19Z

Here is the conf for OIDfilter i tested with to only allow to view the upstatus on one port.

# allow port 2 up-status
1.3.6.1.2.1.2.2.1.8.1 1.3.6.1.2.1.2.2.1.8.2 1.3.6.1.2.1.2.2.1.8.2

My topology is

PublicIP (Manager)
|
Firewall 192.168.1.1
|
Proxy 192.168.1.3
|
Private network
SW 192.168.1.100

And here's a TCPdump from the proxy

snmpget -v2c -c unrpa 213.79.163.67 1.3.6.1.2.1.2.2.1.8.2
Timeout: No Response from 213.79.163.67.


tcpdump -i ens160 port 161
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
09:09:43.964982 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2
09:09:44.966143 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2
09:09:45.967549 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2
09:09:46.968843 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2
09:09:47.970129 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2
09:09:48.971341 IP hosting.dot1q.it.38961 > 192.168.1.3.snmp:  C="test" GetRequest(30)  interfaces.ifTable.ifEntry.ifOperStatus.2

Here is a screenshot from iftop when i did the same snmpget command from the manager (twice)

etingof · 2019-02-19T17:22:05Z

Is it correct that the forwarder (server) listens on PublicIP (snmp-bind-address: PublicIP:161)? I'd expect it to bind to 192.168.1.1, no?

Do you see anything in the snmpfwd-server logs when you run snmpget?

etingof · 2019-02-19T17:26:47Z

In the client config, why is the client sending SNMP packets to snmp-peer-address: PublicIP rather than to the switch (192.168.1.100)?

Also note, that if your switch operates with a different community name than then manager is using, then you should configure that community name through snmp-community-name: test in the client config.

Pelleplast · 2019-02-19T17:42:12Z

Is it correct that the forwarder (server) listens on PublicIP (snmp-bind-address: PublicIP:161)? I'd expect it to bind to 192.168.1.1, no?

Do you see anything in the snmpfwd-server logs when you run snmpget?

Yes it listens to the public IP. Is it easier to bind it to the firewall? When i monitored the active interface on the server (forwarder) the source-address was the public IP so i thought it didn't matter.

etingof · 2019-02-19T17:49:19Z

Is it easier to bind it to the firewall? When i monitored the active interface on the server (forwarder) the source-address was the public IP so i thought it didn't matter.

You should bind snmpfwd server to the interface where the original SNMP queries from your manager come to (not from!). Which is the IP of that first interface in the chain?

Note that snmp-credentials-id entry has nothing to do with source IP address of the SNMP manager. If you want to differentiate based on the source address, then snmp-peer-address-pattern-list should be used for matching the desired source address(es).

etingof · 2019-02-19T18:12:01Z

Looking at your topology, may be you could just:

run both snmpfwd-server and snmpfwd-client on 192.168.1.3
bind snmpfwd-server snmp-bind-address to 192.168.1.3:161
direct snmp-peer-address in snmpfwd-client to 192.168.1.100
configure snmp-community-name in snmpfwd-client to use SNMP community name that 192.168.1.100 switch respects
if both processes run on the same machine, you could set up "trunking" through localhost e.g. for snmpfwd-client trunk-bind-address -> 127.0.0.1:30301, for snmpfwd-server trunk-bind-address -> 127.0.0.1, trunk-peer-address -> 127.0.0.1:30301
block direct SNMP access to 192.168.1.100 from the world, only packets from 192.168.1.3 should be allowed.

Pelleplast · 2019-02-19T18:52:39Z

I'm not running the logger plugin propperly and getting no output there but i changed my config for client.conf and server.conf

server.conf

#
# SNMP forwarder: Agent part configuration
#

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

snmp-credentials-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address: 192.168.1.3:161
  snmp-engine-id: 0x0102030405070809
  snmp-community-name: test
  snmp-security-name: test-user
  snmp-security-model: 2
  snmp-security-level: 1
  snmp-credentials-id: snmp-credentials
}

context-group {
  snmp-context-engine-id-pattern: .*?
  snmp-context-name-pattern: .*?
  snmp-context-id: any-context
}

content-group {
  snmp-pdu-type-pattern: (GET|SET|GETNEXT|GETBULK)
  snmp-pdu-oid-prefix-pattern-list: .*?
  snmp-content-id: any-content
}

peers-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address-pattern-list: .*?
  snmp-peer-address-pattern-list: .*?
  snmp-peer-id: 100
}

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins/

plugin-group {
  plugin-module: oidfilter
  plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf
  plugin-id: permit-system-branch
}

trunking-group {
  trunk-bind-address: 127.0.0.1
  trunk-peer-address: 127.0.0.1:30301
  trunk-ping-period: 60
  trunk-connection-mode: client
  trunk-id: trunk-1
}

routing-map {
  matching-snmp-context-id-list: any-context
  matching-snmp-content-id-list: any-content
  matching-snmp-credentials-id-list: snmp-credentials
  matching-snmp-peer-id-list: 100
  using-plugin-id-list: permit-system-branch
  using-trunk-id-list: trunk-1
}

Client.conf

#
# SNMP forwarder: Manager part configuration
#

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

peers-group {
  snmp-engine-id: 0x0102030405070809
  snmp-transport-domain: 1.3.6.1.6.1.1.1
  snmp-bind-address: 0.0.0.0:0
  snmp-peer-timeout: 100
  snmp-peer-retries: 0
  snmp-community-name: unrpa
  snmp-security-name: public
  snmp-security-model: 2
  snmp-security-level: 1
  snmp-peer-address: 192.168.1.100
  snmp-peer-id: snmplabs
}

trunking-group {
  trunk-bind-address: 127.0.0.1:30301
  trunk-ping-period: 60
#server mode söker efter client mode att sammankoppla med
  trunk-connection-mode: server
  trunk-id: <discover>
}

original-snmp-peer-info-group {
  orig-snmp-bind-address-pattern: .*?
  orig-snmp-context-name-pattern: .*?
  orig-snmp-pdu-type-pattern: .*?
  orig-snmp-oid-prefix-pattern: .*?
  orig-snmp-engine-id-pattern: .*?
  orig-snmp-context-engine-id-pattern: .*?
  orig-snmp-transport-domain-pattern: .*?
  orig-snmp-peer-address-pattern: .*?
  orig-snmp-security-level-pattern: .*?
  orig-snmp-security-name-pattern: .*?
  orig-snmp-security-model-pattern: .*?
  orig-snmp-peer-id: manager-1
}

server-classification-group {
  server-snmp-credentials-id-pattern: .*?
  server-snmp-context-id-pattern: .*?
  server-snmp-content-id-pattern: .*?
  server-snmp-peer-id-pattern: .*?
  server-classification-id: any-classification
}

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins/


plugin-group {
  plugin-module: logger
  plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/logger.conf
  plugin-id: custom-logger
}

routing-map {
  matching-trunk-id-list: trunk-1
  matching-orig-snmp-peer-id-list: manager-1
  matching-server-classification-id-list: any-classification
  using-snmp-peer-id-list: snmplabsrouting-map {
  matching-trunk-id-list: trunk-1
  matching-orig-snmp-peer-id-list: manager-1
  matching-server-classification-id-list: any-classification
  using-snmp-peer-id-list: snmplabs
}

but with this conf when i run

snmpget -v2c -c unrpa 213.79.163.67 1.3.6.1.2.1.1.3.0

my output is still

Timeout: No Response from 213.79.163.67.

But the SNMP-message is obviously reaching the proxy. This is showing when i'm monitoring the interface. But i have no output in snmpfwd loggfile.

etingof · 2019-02-19T21:26:52Z

Looks good except the community name you use - with snmpget you are querying snmpfwd-server which has community public configured. The client part will use community name unrpa against the switch regardless.

But i have no output in snmpfwd loggfile.

But you still see some records there on the startup, right? But nothing related to your queries? Or logging is not functional at all?

Pelleplast · 2019-02-19T21:31:30Z

No my /tmp/snmpfwd-brief.log is completly empty. On startup you say? Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Ilya Etingof <notifications@github.com> Sent: Tuesday, February 19, 2019 10:26:53 PM To: etingof/snmpfwd Cc: Pelleplast; Author Subject: Re: [etingof/snmpfwd] OIDfilter config (#37) Looks good except the community name you use - with snmpget you are querying snmpfwd-server which has community public configured. But i have no output in snmpfwd loggfile. But you still see some records there on the startup, right? But nothing related to your queries? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#37 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AtXFFK4OW3636r8dLbrycml6vCCu_kd2ks5vPGwdgaJpZM4bCbWV>.

etingof · 2019-02-19T21:40:49Z

That /tmp/snmpfwd-brief.log is a custom audit log maintained by the logger plugin. It might have some specific details on the passing traffic you chose to configure.

The meat of the matter is logged by snmpfwd processes themselves. They should log to stderr by default, but you can set up file or syslog logging.

It should be easy to see what's happening there as soon as SNMP packets start hitting the proxy.

Pelleplast · 2019-02-19T21:53:17Z

When i try to run cat /dev/stderr to see some info from log the command just keeps running withou any output Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Ilya Etingof <notifications@github.com> Sent: Tuesday, February 19, 2019 10:40:50 PM To: etingof/snmpfwd Cc: Pelleplast; Author Subject: Re: [etingof/snmpfwd] OIDfilter config (#37) That /tmp/snmpfwd-brief.log is an audit log. It might have some details on the passing traffic. The meat of the matter is logged by snmpfwd processes themselves. They should log to stderr by default, but you can set up file<http://snmplabs.com/snmpfwd/configuration/index.html#logging-method-file> or syslog<http://snmplabs.com/snmpfwd/configuration/index.html#logging-method-syslog> logging. It should be easy to see what's happening there as soon as SNMP packets start hitting the proxy. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#37 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AtXFFJeu5VgwNPHeNR44TUlVlorLYRYXks5vPG9igaJpZM4bCbWV>.

etingof · 2019-02-19T22:14:03Z

I think you can't read from /dev/stderr - this device's solely for writing.

How do you run snmpfwd-server process? If you just invoke it from the command line, it should log right to your terminal i.e. to stderr.

Alternatively, if you configure snmpfwd to log to a local file, you should have all logging going there.

Pelleplast · 2019-02-19T22:36:08Z

When i run

$ snmpfwd-server.py

I get following output

2019-02-19 23:32:41,162 INFO configuring plugin ID permit-system-branch (at .plugin-group) from module oidfilter with options config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf...
2019-02-19 23:32:41,162 INFO scanning "/home/ueexjobo/.local/snmpfwd/plugins/" directory for plugin modules...
2019-02-19 23:32:41,169 INFO oidfilter: plugin initialization complete
2019-02-19 23:32:41,169 INFO plugin module "/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.py" loaded
2019-02-19 23:32:41,169 INFO configuring snmp-credentials snmp-credentials (at .snmp-credentials-group)...
2019-02-19 23:32:41,191 INFO new engine-id 0x0102030405070809
2019-02-19 23:32:41,192 ERROR Traceback (most recent call last):;
2019-02-19 23:32:41,192 ERROR   File "/home/ueexjobo/.local/bin/snmpfwd-server.py", line 981, in <module>;    main();
2019-02-19 23:32:41,192 ERROR   File "/home/ueexjobo/.local/bin/snmpfwd-server.py", line 707, in main;    t = transport.openServerMode(bindAddr);
2019-02-19 23:32:41,192 ERROR   File "/home/ueexjobo/.local/lib/python2.7/site-packages/pysnmp/carrier/asyncore/dgram/base.py", line 57, in openServerMode;    raise error.CarrierError('bind() for %s failed: %s' % (iface, sys.exc_info()[1],));
2019-02-19 23:32:41,192 ERROR CarrierError: bind() for ('192.168.1.3', 161) failed: [Errno 13] Permission deniedcaused by <class 'socket.error'>: [Errno 13] Permission denied;
2019-02-19 23:32:41,192 INFO process terminated

Then as sudo

$sudo /home/ueexjobo/.local/bin/snmpfwd-server.py

the command is accepted

etingof · 2019-02-19T22:57:43Z

Ah, I see now!

If you run it under root (which is required for binding ports < 1024), you need to specify the user and the group to which the process should switch upon startup. Assuming you have nobody and nogroup user and group on your system:

$ sudo snmpfwd-server.py --process-user=nobody --process-group=nogroup

May be you also need to specify your config file via --config.

Pelleplast · 2019-02-19T23:10:30Z

$ sudo /home/ueexjobo/.local/bin/snmpfwd-server.py --process-user=nobody --process-group=nogroup


2019-02-20 00:09:51,685 INFO configuring plugin ID permit-system-branch (at .plugin-group) from module oidfilter with options config=, ~/.local/snmpfwd/plugins/oidfilter.conf...
2019-02-20 00:09:51,685 INFO scanning "~/.local/snmpfwd/plugins" directory for plugin modules...
2019-02-20 00:09:51,685 ERROR directory "~/.local/snmpfwd/plugins" does not exist
2019-02-20 00:09:51,685 ERROR plugin permit-system-branch not loaded: plugin module "oidfilter" not found in search path(s): ~/.local/snmpfwd/plugins
2019-02-20 00:09:51,686 INFO process terminated

etingof · 2019-02-20T05:44:36Z

That's a good progress!

Are the config files you've pasted above still the same you are running? I suspect you might have a ~ somewhere in your configuration (config=~/.local/snmpfwd/plugins) which probably gets expanded into /root under sudo...

Alternatively, trysudo -E to preserve your user environment.

Pelleplast · 2019-02-20T06:03:59Z

I had the config file written like /home/ueexjobo/.local/snmpfwd/plugins/ But i got the same output and then i tried to change it to ~. I haven't created any files while in root. All the files are created as ueexjobo user.

etingof · 2019-02-20T06:51:25Z

This is curious - I can't reproduce this behavior so far. Are you certain that the plugin-modules-path-list: option does not have "~" or "${}" in path?

Are you using snmpfwd 0.4.4?

etingof · 2019-02-20T07:14:54Z

Alternatively, trysudo -E to preserve your user environment.

Looking at the code, the above suggestion won't work because the code does not expand "~" at all.

What's interesting that the path in this message in the log:

2019-02-20 00:09:51,685 INFO scanning "~/.local/snmpfwd/plugins" directory for plugin modules...

Comes directly from the

plugin-modules-path-list: <path>

option. How come you have different paths in the config and in the log...? Hmm...

Pelleplast · 2019-02-20T07:17:53Z

The whole path to the snmpserver.py is

/home/ueexjobo/.local/bin/

The path for the plugins are

/home/ueexjobo/.local/snmpfwd/plugins/

Pelleplast · 2019-02-20T07:30:09Z

I removed a space between config= and the path and changed my path to

plugin-modules-path-list:~/.local/snmpfwd/plugins/

plugin-group {
  plugin-module: oidfilter
  plugin-options: config=~/.local/snmpfwd/plugins/oidfilter.conf
  plugin-id: permit-system-branch

now when i run

.local/bin/snmpfwd-server.py --process-user=ueexjobo --process-group=ueexjobo

My output is

2019-02-20 08:28:03,452 ERROR configuration parsing error: <snmpfwd.cparser.Parser object at 0x7f0d08998f90> missing object beginning sign: plugin-group
2019-02-20 08:28:03,452 INFO process terminated

etingof · 2019-02-20T07:40:03Z

No-no, you should neither remove spaces nor use "~" in the config. The right config should be:

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins

plugin-group {
  plugin-module: oidfilter
  plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf
  plugin-id: permit-system-branch
}

So how did you install snmpfwd? Was it just pip install --user snmpfwd?

I'd like to build the same environment and use your config files to reproduce this puzzling behavior.

Pelleplast · 2019-02-20T07:42:17Z

So how did you install snmpfwd? Was it just pip install --user snmpfwd?

pip install snmpfwd

etingof · 2019-02-20T07:44:56Z

Which Python version? Is it on Linux? Can you share your pip list output?

Pelleplast · 2019-02-20T07:45:56Z

So i fixed my error in the path file and now running

sudo .local/bin/snmpfwd-server.py --process-user=ueexjobo --process-group=ueexjobo

this is my output

etingof · 2019-02-20T07:48:13Z

Ha! Awesome! So what was the problem?

Now it seems you need to have snmpfwd-client running so they could connect to each other.

Pelleplast · 2019-02-20T07:52:08Z

There were a space between config= and /home/ue.....

Is it needed to have two windows of putty to have client running on one and server on the other?
but now as i start both in different windows i can run: snmpget -v2c -c test 213.79.163.67 1.3.6.1.2.1.1.3.0 and get:

iso.3.6.1.2.1.1.3.0 = Timeticks: (120322246) 13 days, 22:13:42.46

in respons.
And this:

snmpget -v2c -c test 213.79.163.67 1.3.6.1.2.1.1.2.0

returns:

iso.3.6.1.2.1.1.2.0 = No Such Instance currently exists at this OID

is this correct? I'm runnig the example config for OIDfilter.conf

etingof · 2019-02-20T08:08:52Z

Is it needed to have two windows of putty to have client running on one and server on the other?

That's a good way when setting things up. Once everything is configured, you should --daemonize both processes into background.

is this correct? I'm runnig the example config for OIDfilter.conf

Looks good. The example config allows just 1.3.6.1.2.1.1.1.0 and 1.3.6.1.2.1.1.3.0from thesystem` branch. So the other OIDs should be reported as non-existent.

# allow sysDescr.0
1.3.6.1.2.1.1.1 1.3.6.1.2.1.1.1.0 1.3.6.1.2.1.1.1.0

# allow a few objects at the system branch
1.3.6.1.2.1.1.3 1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.1.3.0

# allow whole sysORUpTime branch
1.3.6.1.2.1.1.9.1.4 1.3.6.1.2.1.1.9.1.4.1 1.3.6.1.2.1.1.9.1.4.8

...

You can change with the config to see how it affects the behavior to make sure it filters out stuff the way you want it.

Pelleplast · 2019-02-20T08:20:54Z

Waow thank you sooooooo much! you've saved me like never before. I'll try to configure some OIDfiltering without destroying everything :)
much love to you!

Pelleplast · 2019-02-20T10:03:14Z

I don't really understad the peers-group config. No stress with this but would like to filter based on source address. So when i send snmpget from 80.244.65.175 i want to restrict OIDs but with same string sent from another IP i want to allow different OIDs.

I tried changing the snmp-bind-address-pattern-list: to 80.244.65.175. but then the logs responed with no route configured.

etingof · 2019-02-20T12:26:54Z

would like to filter based on source address

This is definitely doable.

I tried changing the snmp-bind-address-pattern-list:

This can be used if you make snmpfwd listening on many local interfaces and you want to distinguish peers based on that.

So when i send snmpget from 80.244.65.175 i want to restrict OIDs but with same string sent from another IP i want to allow different OIDs.

What you need is snmp-peer-address-pattern-list option where you put a regex matching the source ip:port and coming out with some unique snmp-peer-id. Then you use matched snmp-peer-id in matching-snmp-peer-id statement in the routing block to associate with specific using-plugin-id-list option.

Perhaps you will have multiple instances of oidfilter plugin having different configuration (via different files). Then you put each plugin-id to the respective using-plugin-id-list in different routing entries. All these routing entries will probably have the same using-trunk-id-list, they will only differ in their using-plugin-id-list contents.

Let me know if it's too confusing, I can draft an example.

Pelleplast · 2019-02-20T12:48:53Z

I have absolutly no experience using regex but for this i need to filter out 80.244.65.175 and .176 from each other and make them reach different OID and hopefully two different switches.
so would this be a valid regex to filter out the .175 add?

/^([1-9]?\d|1\d\d|2[0-4]\d|25[0-5])\.([1-9]?\d|1\d\d|2[0-4]\d|25[0-5])\.([1-9]?\d|1\d\d|2[0-4]\d|25[0-5])\.([1-9]?\d|1\[0-6]\d|17[0-5])$

etingof · 2019-02-20T13:22:52Z

There are any ways how to configure that... Consider this server config, I can't test it, but it should generally work. May be you need to apply the fixes you've encountered earlier.

#
# SNMP forwarder: Agent part configuration
#

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

snmp-credentials-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address: 192.168.1.3:161
  snmp-engine-id: 0x0102030405070809
  snmp-community-name: test
  snmp-security-name: test-user
  snmp-security-model: 2
  snmp-security-level: 1
  snmp-credentials-id: snmp-credentials
}

context-group {
  snmp-context-engine-id-pattern: .*?
  snmp-context-name-pattern: .*?
  snmp-context-id: any-context
}

content-group {
  snmp-pdu-type-pattern: (GET|SET|GETNEXT|GETBULK)
  snmp-pdu-oid-prefix-pattern-list: .*?
  snmp-content-id: any-content
}

peers-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address-pattern-list: .*?

  peer-one {
    snmp-peer-address-pattern-list: ^80\.244\.65\.175:.*?
    snmp-peer-id: 175
  }
  
  peer-two {
    snmp-peer-address-pattern-list: ^80\.244\.65\.176:.*?
    snmp-peer-id: 176
  }
}

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins/

plugin-group {
  plugin-module: oidfilter

  system-branch {
    plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf
    plugin-id: permit-system-branch
  }

  other-branch {
    plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/oidfilter.conf
    plugin-id: permit-other-branch
  }
}

trunking-group {
  trunk-bind-address: 127.0.0.1
  trunk-peer-address: 127.0.0.1:30301
  trunk-ping-period: 60
  trunk-connection-mode: client
  trunk-id: trunk-1
}

routing-map {
  matching-snmp-context-id-list: any-context
  matching-snmp-content-id-list: any-content
  matching-snmp-credentials-id-list: snmp-credentials

  system-branch-route {
    matching-snmp-peer-id-list: 175
    using-plugin-id-list: permit-system-branch
    using-trunk-id-list: trunk-1
  }

  other-branch-route {
    matching-snmp-peer-id-list: 176
    using-plugin-id-list: permit-other-branch
    using-trunk-id-list: trunk-1
  }
}

You'd need to copy and edit one of the oidfilter.conf files to match your filtering needs.

etingof · 2019-02-20T13:30:25Z

And the client part leveraging the above server config classification. The goal of the client config is to route SNMP messages coming from server over one of the two backend switches.

#
# SNMP forwarder: Manager part configuration
#

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

peers-group {
  snmp-engine-id: 0x0102030405070809
  snmp-transport-domain: 1.3.6.1.6.1.1.1
  snmp-bind-address: 0.0.0.0:0
  snmp-peer-timeout: 100
  snmp-peer-retries: 0
  snmp-community-name: unrpa
  snmp-security-name: public
  snmp-security-model: 2
  snmp-security-level: 1

  switch-1 {
    snmp-peer-address: 192.168.1.100
    snmp-peer-id: sw-one
  }

  switch-2 {
    # TODO: set second switch IP
    snmp-peer-address: 192.168.1.100
    snmp-peer-id: sw-two
  }
}

trunking-group {
  trunk-bind-address: 127.0.0.1:30301
  trunk-ping-period: 60
#server mode söker efter client mode att sammankoppla med
  trunk-connection-mode: server
  trunk-id: <discover>
}

original-snmp-peer-info-group {
  orig-snmp-bind-address-pattern: .*?
  orig-snmp-context-name-pattern: .*?
  orig-snmp-pdu-type-pattern: .*?
  orig-snmp-oid-prefix-pattern: .*?
  orig-snmp-engine-id-pattern: .*?
  orig-snmp-context-engine-id-pattern: .*?
  orig-snmp-transport-domain-pattern: .*?
  orig-snmp-peer-address-pattern: .*?
  orig-snmp-security-level-pattern: .*?
  orig-snmp-security-name-pattern: .*?
  orig-snmp-security-model-pattern: .*?
  orig-snmp-peer-id: any-manager
}

server-classification-group {
  server-snmp-credentials-id-pattern: .*?
  server-snmp-context-id-pattern: .*?
  server-snmp-content-id-pattern: .*?

  peer-175 {
    server-snmp-peer-id-pattern: 175
    server-classification-id: peer-175
  }

  peer-176 {
    server-snmp-peer-id-pattern: 176
    server-classification-id: peer-176
  }
}

plugin-modules-path-list: /home/ueexjobo/.local/snmpfwd/plugins/


plugin-group {
  plugin-module: logger
  plugin-options: config=/home/ueexjobo/.local/snmpfwd/plugins/logger.conf
  plugin-id: custom-logger
}

routing-map {
  matching-orig-snmp-peer-id-list: any-manager
  matching-trunk-id-list: trunk-1

  sw-one-route {
    matching-server-classification-id-list: peer-175
    using-snmp-peer-id-list: sw-one
  }

  sw-two-route {
    matching-server-classification-id-list: peer-176
    using-snmp-peer-id-list: sw-two
  }
}

Do not pay attention to block names - they are never used for matching. Can be just whatever.

Pelleplast · 2019-02-20T14:00:47Z

waow thanks!
this row? from where is the snmplapsrouting-map?

using-snmp-peer-id-list: snmplabsrouting-map {

etingof · 2019-02-20T14:13:50Z

using-snmp-peer-id-list: snmplabsrouting-map {

Oh, pardon my text editing skills! Hopefully, fixed!

Pelleplast · 2019-02-20T14:32:24Z

perfect i fixed my config so it looks like your
when i now run
snmpget -v2c -c test 213.79.163.67 1.3.6.1.2.1.2.2.1.2.7
my respons from server log is

2019-02-20 15:29:16,231 ERROR no route configured callflow-id=d7ea20b7fb snmp-engine-id=0x0102030405070809 snmp-transport-domain=1.3.6.1.6.1.1.100 snmp-bind-address=192.168.1.3 snmp-bind-port=161 snmp-security-model=2 snmp-security-level=1 snmp-security-name=test-user snmp-credentials-id=test-user snmp-context-engine-id=0x0102030405070809 snmp-context-name=<nil> snmp-context-id=any-context snmp-pdu=GetRequestPDU#1.3.6.1.2.1.2.2.1.2.5:<nil>, snmp-content-id=any-content snmp-peer-address=80.244.65.175 snmp-peer-port=41378 snmp-peer-id=<nil>

etingof · 2019-02-20T15:27:34Z

This bit in the log snmp-peer-id=<nil> means that regexp did not match for some reason. The source address seems correct snmp-peer-address=80.244.65.175.

What does the server log on start up related to snmp-peer-id? Do you have precisely this configuration in the server config?

peers-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address-pattern-list: .*?

  peer-one {
    snmp-peer-address-pattern-list: ^80\.244\.65\.175:.*?
    snmp-peer-id: 175
  }
  
  peer-two {
    snmp-peer-address-pattern-list: ^80\.244\.65\.176:.*?
    snmp-peer-id: 176
  }
}

Pelleplast · 2019-02-20T15:47:04Z

Here is my config


peers-group {
  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address-pattern-list: .*?

  peer-one {
    snmp-peer-address-pattern-list: ^80\.244\.65\.175:.*?}
    snmp-peer-id: 175
  }

  peer-two {
    snmp-peer-address-pattern-list: ^80\.244\.65\.176:.*?
    snmp-peer-id: 176
  }
}

This is the startup from peer ID

2019-02-20 16:43:23,580 INFO configuring peer ID 175 (at .peers-group.peer-one)...
2019-02-20 16:43:23,580 INFO configuring peer ID 176 (at .peers-group.peer-two)...

etingof · 2019-02-20T15:52:16Z

Perhaps trailing } gets in the way:

    snmp-peer-address-pattern-list: ^80\.244\.65\.175:.*?}

Pelleplast · 2019-02-20T16:02:55Z

yea that did ti and both client and server starts propperly now.
server output when i run snmp get from .176

2019-02-20 17:00:32,756 INFO received trunk message #30, remote end reported error-indication "no route to SNMP peer configured", NOT responding callflow-id=e1139b5780

And client output

2019-02-20 17:00:29,751 INFO received SNMP error-indication "no route to SNMP peer configured" callflow-id=361ec22ec8 snmp-pdu=<nil>
2019-02-20 17:00:30,752 ERROR unroutable trunk message #28 callflow-id=30d1786ec8 trunk-id=trunk-1 server-snmp-engine-id=0x0102030405070809 server-snmp-transport-domain=1.3.6.1.6.1.1.100 server-snmp-peer-address=80.244.65.176 server-snmp-peer-port=49856 server-snmp-bind-address=192.168.1.3 server-snmp-bind-port=161 server-snmp-security-model=2 server-snmp-security-level=1 server-snmp-security-name=test-user server-snmp-context-engine-id=0x0102030405070809 server-snmp-context-name=<nil> server-snmp-pdu=GetRequestPDU#1.3.6.1.2.1.2.2.1.8.7:<nil>, server-snmp-entity-id=any-manager server-snmp-credentials-id=test-user server-snmp-context-id=any-context server-snmp-content-id=any-content server-snmp-peer-id=176

etingof · 2019-02-20T16:40:28Z

Just spotted a duplication in client conf:

  peer-175 {
    server-snmp-peer-id-pattern: ^175$
    server-classification-id: peer-175
  }

  peer-175 {
    server-snmp-peer-id-pattern: ^176$
    server-classification-id: peer-176
  }

Let's rename block name peer-175 -> peer-176 just in case.

etingof · 2019-02-20T16:41:38Z

2019-02-20 17:00:30,752 ERROR unroutable

Is this the complete line from the log? It seems to miss some attributes...

Pelleplast · 2019-02-20T16:50:26Z

This is the full output from one snmpget

etingof · 2019-02-20T17:01:57Z

So let's update client conf - I've updated it up in this thread.

Pelleplast · 2019-02-20T17:29:53Z

Now I've redone and copied in the config you posted earlier.

and this is what the client outputs

etingof · 2019-02-20T17:43:32Z

One more change to the client config please - we need to remove regexp anchors:

    server-snmp-peer-id-pattern: ^175$
    server-snmp-peer-id-pattern: ^176$

Should be:

    server-snmp-peer-id-pattern: 175
    server-snmp-peer-id-pattern: 176

Pelleplast · 2019-02-20T17:47:26Z

That did the job!

etingof · 2019-02-26T06:55:29Z

So I hope you are all set by now. Feel free to open an issue if you run into anything later on.

etingof closed this as completed Feb 26, 2019

OIDfilter config #37

OIDfilter config #37

Comments

Pelleplast commented Feb 19, 2019 • edited Loading

etingof commented Feb 19, 2019 • edited Loading

Pelleplast commented Feb 19, 2019 • edited Loading

etingof commented Feb 19, 2019

etingof commented Feb 19, 2019

Pelleplast commented Feb 19, 2019

etingof commented Feb 19, 2019

etingof commented Feb 19, 2019 • edited Loading

Pelleplast commented Feb 19, 2019 • edited Loading

etingof commented Feb 19, 2019 • edited Loading

Pelleplast commented Feb 19, 2019 via email

etingof commented Feb 19, 2019 • edited Loading

Pelleplast commented Feb 19, 2019 via email

etingof commented Feb 19, 2019

Pelleplast commented Feb 19, 2019 • edited Loading

etingof commented Feb 19, 2019

Pelleplast commented Feb 19, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019 via email • edited by etingof Loading

etingof commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019 • edited Loading

Pelleplast commented Feb 20, 2019

Pelleplast commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

Pelleplast commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019 • edited Loading

Pelleplast commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019 • edited Loading

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019 • edited Loading

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019

etingof commented Feb 20, 2019

Pelleplast commented Feb 20, 2019 • edited Loading

etingof commented Feb 26, 2019

Pelleplast commented Feb 19, 2019 •

edited

Loading

etingof commented Feb 19, 2019 •

edited

Loading

Pelleplast commented Feb 19, 2019 •

edited

Loading

etingof commented Feb 19, 2019 •

edited

Loading

Pelleplast commented Feb 19, 2019 •

edited

Loading

etingof commented Feb 19, 2019 •

edited

Loading

etingof commented Feb 19, 2019 •

edited

Loading

Pelleplast commented Feb 19, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 via email •

edited by etingof

Loading

etingof commented Feb 20, 2019 •

edited

Loading

etingof commented Feb 20, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 •

edited

Loading

etingof commented Feb 20, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 •

edited

Loading

etingof commented Feb 20, 2019 •

edited

Loading

etingof commented Feb 20, 2019 •

edited

Loading

etingof commented Feb 20, 2019 •

edited

Loading

Pelleplast commented Feb 20, 2019 •

edited

Loading