SNMP across VLANs, responses not getting through firewall.
-
@erasedhammer It would be a policy on the AP being queried, not the server doing the queries.
This is just UDP. It is not the firewall.
Does the AP's management interface have a default gateway that points back to its pfSense local interface? Can you ping it?
-
-
You probably want to packet capture for the SNMP traffic to see where it is going wrong.
-
@erasedhammer Note your rule has 0 counters which mean it has never received a match since the filter was reloaded. Is there another rule above it that might be matching and policy routing the traffic or something like that?
-
From the same subnet snmp works:
From pfsense (vlan130 interface):
From pfsense (vlan100 interface):
It looks like its getting through the firewall. I have no clue why its responding to a device on the same subnet but not another network.
I guess this is a dlink issue, dang. -
Previously I had rules for all the different devices. I have consolidated this rule just now into an alias.
Here is what I am using now, it still doesn't work though:
-
@erasedhammer The firewall cannot make the AP respond to the requests it is sending to it.
Check the AP for anything that restricts SNMP to its local subnet.
-
Okay. the documentation on it is crap at the best. I'll have to post somewhere.
-
-
Looks like it. That documentation seems fairly comprehensive.
-
@Derelict said in SNMP across VLANs, responses not getting through firewall.:
Looks like it. That documentation seems fairly comprehensive.
I did just pick a random D-Link device manual so I could be wrong
Andy
1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22
-
@NogBadTheBad oh ok lol
-
Yeah wrong manual. The device I got said clearly it supports snmpv3, but turns out theres no way to change it and it only supports v2c, but I can live with that.
The snmp menu on this wap is very barebones, only fields are enabled, public/private strings, and trap ip. Nothing else.
-
Problem solved:
Ended up being an arp anti spoofing setting binding the default gateway IP to its MAC, but since pfsense is doing the routing the device was blocking another IP (the server) from using that mac.
