Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: X-REMOTE_USER not being passed to Dancer (Christian Ramseyer)
2. Fortinet FortiOS Shenanigans (Michael Butash)
3. Re: Fortinet FortiOS Shenanigans (Christian Ramseyer)
--- Begin Message ---
Hi Michael
Yes I tried something similar once and also had the impression this
didn't work properly. I've played around some more now and attempted a fix:
https://github.com/netdisco/netdisco/pull/1310
It would be great if you could take the DBIC.pm file from there and see
if it works for you? Watch out there's two DBIC.pm, more precisely it's
lib/App/Netdisco/Web/Auth/Provider/DBIC.pm that has the change.
Cheers
Christian
On 11.03.2025 18:53, Michael Dano wrote:
We are working to set up SAML login via Apache Reverse Proxy to do
authentication. We have the X-REMOTE_USER being populated with the user
name from Entra ID. We have verified that the X-REMOTE_USER value is
being sent to Dancer in the header. We did use the Dancer Debug sidebar
to verify that the value is accurate. We do not see any login attempts
into the Netdisco site from the user. In the deployment.yml file we have
the values set as:
auth_user_env: "X-REMOTE_USER"
trust_x_remote_user: true
validate_remote_user: true
We have verified that the user exists in Netdisco but never see any
authentication attempts come in. Is there additional configuration that
needs to be done on the deployment.yml side to allow the user to
authenticate?
--
Christian Ramseyer, netnea ag
Network Management. Security. OpenSource.
https://www.netnea.com
Phone: +41 79 644 77 64
--- End Message ---
--- Begin Message ---
I'm setting up ND for a new customer, and found a few problems I'm
scratching my head with.
First, Out 3 Fortigates, two work fine, but one I'm unable to get port data
out of. A snmpwalk comes back fine, as well librenms polls and sees all
ports, but the one simply hangs ND for the 10 minute timeout, comes back
with a weird HASH output then an error, grabs the rest of the node entity
data, and exits normally.
Doing a discover -DIQ on the node, it polls then until it gets to
ifStackStatus, hangs the 10 minutes, then moves on, but minus ports:
<code>
[1465732] 2025-03-16 04:25:57 debug ⮕ worker Discover::Properties p100
# cut bits
SNMP::Info::_load_attr bp_index : BRIDGE-MIB::dot1dBasePortIfIndex :
.1.3.6.1.2.1.17.1.4.1.2
SNMP::Info::_load_attr i_lastchange : IF-MIB::ifLastChange :
.1.3.6.1.2.1.2.2.1.9
SNMP::Info::_load_attr ifStackStatus : IF-MIB::ifStackStatus :
.1.3.6.1.2.1.31.1.2.1.3
## hang occurs here
[1465732] 2025-03-16 04:35:55 debug -> HASH(0x5a1a1c8c3b98)
[1465732] 2025-03-16 04:35:55 debug ⬅ (error) {}
[1465732] 2025-03-16 04:35:55 debug //// MAIN \\\\ phase
[1465732] 2025-03-16 04:35:55 debug ⮕ worker Discover::CanonicalIP p100
[1465732] 2025-03-16 04:35:55 debug ⮕ worker Discover::Entities p100
SNMP::Info::_load_attr entPhysicalDescr : ENTITY-MIB::entPhysicalDescr :
.1.3.6.1.2.1.47.1.1.1.1.2
</code>
... and the rest exits normally, but missing port data in the device.
Now on a working node, it simply runs through this, gets the ports, and
exits quickly.
<code>
SNMP::Info::_load_attr bp_index : BRIDGE-MIB::dot1dBasePortIfIndex :
.1.3.6.1.2.1.17.1.4.1.2
SNMP::Info::_load_attr i_lastchange : IF-MIB::ifLastChange :
.1.3.6.1.2.1.2.2.1.9
SNMP::Info::_load_attr ifStackStatus : IF-MIB::ifStackStatus :
.1.3.6.1.2.1.31.1.2.1.3
## other hangs here
SNMP::Info::_load_attr ifType : IF-MIB::ifType : .1.3.6.1.2.1.2.2.1.3
SNMP::Info::_load_attr i_stack_status : IF-MIB::ifStackStatus :
.1.3.6.1.2.1.31.1.2.1.3
SNMP::Info::_validate_autoload_method(i_subinterfaces) Unable to resolve
method.
SNMP::Info::_global load_uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global snmpEngineTime : SNMP-FRAMEWORK-MIB::snmpEngineTime.0 :
.1.3.6.1.6.3.10.2.1.3.0
SELECT me.ip, me.alias, me.subnet, me.port, me.dns, me.creation
FROM device_ip me
</code>
The weird thing, these are almost exact mirrors of each other as two sdwan
hubs, and really no difference in port or snmp configurations. Any ideas?
Second, I set up the ssh arp collector for FortiOS per instructions, but
the collector simply never seems to attempt to use ssh, only using the snmp
v3 set. I tried to set up a host_group again per github docs on using it
for FortiOS, but nothing. I tried with and without including SNMP with the
ssh collector bits, not sure if I should, but still I never see the ssh
portion.
Here's my deployment.yml bits, do you see anything wrong with this approach?
<code>
device_auth:
- tag: 'corp_fortinet'
# user: 'monitor-user'
# auth:
# pass: 'secret'
# proto: SHA
# priv:
# pass: 'secret
# proto: AES
action: arpnip::nodes
only: 'group:Fortinet-Fortigate'
driver: cli
platform: FortiOS
username: 'monitor-user'
password: 'secret'
banner: true
ssh_master_opts:
- "-o"
- "StrictHostKeyChecking=no"
- tag: 'corp_v3authpriv_network_security'
user: 'monitor-user'
auth:
pass: 'secret'
proto: SHA
priv:
pass: 'secret'
proto: AES
- tag: 'corp_v2c_servers'
community: 'secret'
read: true
write: false
host_groups:
Fortinet-Fortigate:
- 'platform:FortiOS'
</code>
Thanks in advance!
-mb
--- End Message ---
--- Begin Message ---
Hi Mike
On 16.03.2025 06:16, Michael Butash wrote:
I'm setting up ND for a new customer, and found a few problems I'm
scratching my head with.
First, Out 3 Fortigates, two work fine, but one I'm unable to get port
data out of. A snmpwalk comes back fine, as well librenms polls and sees
all ports, but the one simply hangs ND for the 10 minute timeout, comes
back with a weird HASH output then an error, grabs the rest of the node
entity data, and exits normally.
Just recently we've encountered crashing SNMP agents on Fortigates and I
suspect it might be triggered by Netdisco queries. Can you check in the
Forti logs if you get something like
200: 2024-09-30 03:21:47 snmpd watchdog timeout
201: 2024-09-30 03:21:47 <16862> firmware FortiGate-600E
v7.2.10,build1706b1706,240918 (GA.M) (Release)
202: 2024-09-30 03:21:47 <16862> application snmpd
203: 2024-09-30 03:21:47 <16862> *** signal 6 (Aborted) received ***
Apparently a fix for 7.2 and 7.4 should be in the works. Also a
workaround was proposed:
config system snmp sysinfo
set append-index enable
end
Not sure if this is related to your problem, but might be worth a look.
Second, I set up the ssh arp collector for FortiOS per instructions, but
the collector simply never seems to attempt to use ssh, only using the
snmp v3 set. I tried to set up a host_group again per github docs on
using it for FortiOS, but nothing. I tried with and without including
SNMP with the ssh collector bits, not sure if I should, but still I
never see the ssh portion.
Here's my deployment.yml bits, do you see anything wrong with this approach?
<code>
device_auth:
- tag: 'corp_fortinet'
# user: 'monitor-user'
# auth:
# pass: 'secret'
# proto: SHA
# priv:
# pass: 'secret
# proto: AES
action: arpnip::nodes
only: 'group:Fortinet-Fortigate'
driver: cli
platform: FortiOS
username: 'monitor-user'
password: 'secret'
banner: true
ssh_master_opts:
- "-o"
- "StrictHostKeyChecking=no"
- tag: 'corp_v3authpriv_network_security'
user: 'monitor-user'
auth:
pass: 'secret'
proto: SHA
priv:
pass: 'secret'
proto: AES
- tag: 'corp_v2c_servers'
community: 'secret'
read: true
write: false
host_groups:
Fortinet-Fortigate:
- 'platform:FortiOS'
Sorry you can't match on platform: like that in the group, since
platform is only the name of the Perl module that is used to do the ssh
arpnip, not really a property that is materialized in the database. I'd
try matching just a single IP, see if that works, and go from there:
device_auth:
- tag: 'corp_fortinet'
#action: arpnip::nodes
#only: 'group:Fortinet-Fortigate'
only:
- 192.168.1.42
driver: cli
platform: FortiOS
username: 'monitor-user'
password: 'secret'
banner: true
ssh_master_opts:
- "-o"
- "StrictHostKeyChecking=no"
Putting SNMP credentials into the cli stanzas is not required and won't
do anything (but also shouldn't make it fail).
Also note the bit from the doc that SSH will not enumerate multiple
credentials, "For drivers other than SNMP, only one stanza will be
tried, and it is a fatal error to have more than one stanza available
for a target device." - this has gotten various people already.
Cheers
Christian
--
Christian Ramseyer, netnea ag
Network Management. Security. OpenSource.
https://www.netnea.com
Phone: +41 79 644 77 64
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
