On Mon, 19 Jun 2023 08:26:38 +0000 (4 days, 6 hours, 19 minutes ago) Philipp Petermann philipp.petermann@unibas.ch wrote:
From what I understand VLANs are added automatically by ipdevpoll from detected router ports. Now the reason for this missing VLAN most probably is the fact that it is routed on a PaloAlto firewall. This firewall exists in NAV as type "Palo Alto Networks PA-5200 (Palo Alto Networks PA-5200 series firewall from PaloAlto)" (sysobjectid 1.3.6.1.4.1.25461.2.3.23) but no router ports are reported (count 0).
So my questions at this point are:
- Is there a way to manually add VLANs so the can be used by
"vlan_auth"?
Potentially by using the solution proposed by Mischa Diehm - although, manual registration of prefixes is usually meant to mark a prefix as a scope or to make an address space reservation for future use.
- Is my assumption correct that the VLAN is missing because the
PaloAlto router ports are not correctly detected?
I think this may be a result of using the `vlan_auth` feature. I believe PortAdmin will happily let you set any VLAN on a switch port, as long as it can detect that VLAN tag as existing on the switch.
However, once you enable `vlan_auth`, PortAdmin necessarily needs to correlate the VLAN tag used on the switch with one of the VLANs it has discovered and stored from inspecting router ports, since the router port description is where it gets organizational ownership for a VLAN from.
So again, you may be able to work around it by using Mischa's tip.
- Should PaloAlto router ports normally be detected with NAV?
I think so, but I have no direct experience with PaloAlto (yet - we are currently evaluating PaloAlto firewalls for upcoming campus network installations for customers).
Perhaps someone from the University of Tromsø reads this and can comment? They use PaloAlto, and have recently contributed the pull request you mentioned.
- If so, how can I fix this? And if not, is there any workaround
available?
The best way to resolve this would be to make NAV see your PaloAlto router ports. Again, I cannot be sure what the problem is here without some debugging - but as long as PaloAlto properly supports the IF-MIB and the IP-MIB, this should just work.
I'm off on a few week's vacation now, so I'm cheekily sending a blind carbon copy to someone at the University of Tromsø, just in case they have time to offer some feedback :)
- Is https://github.com/Uninett/nav/pull/2613 a solution to this?
Not likely. This is mainly a workaround for the fact that, although PaloAlto supports SNMP, it does not want to report ARP cache information through SNMP (this seems to be the case for firewall products from several other vendors as well).