On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))
This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.
Hi all
which Fortigate version is related to this bug?
It seems from the provided fortinet help link the version is 5.6.x which is very old and superseded.
Alex
On 18/01/2023 10:38, Morten Brekkevold wrote:
On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.
According to an older post from December it is a 101F v6.4.11 build 2030,221031
Regards ________________________________________ From: Alessandro Del Ferro a.delferro@bitmagic.it Sent: 18 January 2023 10:56:20 To: Morten Brekkevold; Biselx Nicolas Cc: nav-users@lister.sikt.no Subject: [Nav-users] Re: Fortigate firewall
Hi all
which Fortigate version is related to this bug?
It seems from the provided fortinet help link the version is 5.6.x which is very old and superseded.
Alex
On 18/01/2023 10:38, Morten Brekkevold wrote:
On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.
Yes it is the v6.4.11, We will see the evolution when we have updated the fortigate to a more recent version.
We don't have a date yet, but I'll let you know if the problem is fixed.
@Morten, Thanks a lot for the support
Nicolas
Le 18.01.23 à 13:39, Jan Sigurd Refvik a écrit :
According to an older post from December it is a 101F v6.4.11 build 2030,221031
Regards ________________________________________ From: Alessandro Del Ferro a.delferro@bitmagic.it Sent: 18 January 2023 10:56:20 To: Morten Brekkevold; Biselx Nicolas Cc: nav-users@lister.sikt.no Subject: [Nav-users] Re: Fortigate firewall
Hi all
which Fortigate version is related to this bug?
It seems from the provided fortinet help link the version is 5.6.x which is very old and superseded.
Alex
On 18/01/2023 10:38, Morten Brekkevold wrote:
On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.
Additional information, If I enter a Fortigate with an SRV (Server) category, I no longer get a warning
Regards, Nicolas
Le 23.01.23 à 10:52, Biselx Nicolas a écrit :
Yes it is the v6.4.11, We will see the evolution when we have updated the fortigate to a more recent version.
We don't have a date yet, but I'll let you know if the problem is fixed.
@Morten, Thanks a lot for the support
Nicolas
Le 18.01.23 à 13:39, Jan Sigurd Refvik a écrit :
According to an older post from December it is a 101F v6.4.11 build 2030,221031
Regards ________________________________________ From: Alessandro Del Ferro a.delferro@bitmagic.it Sent: 18 January 2023 10:56:20 To: Morten Brekkevold; Biselx Nicolas Cc: nav-users@lister.sikt.no Subject: [Nav-users] Re: Fortigate firewall
Hi all
which Fortigate version is related to this bug?
It seems from the provided fortinet help link the version is 5.6.x which is very old and superseded.
Alex
On 18/01/2023 10:38, Morten Brekkevold wrote:
On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order
The corresponding InetAddressType value is ipv4(1).
This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))
This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.
-
Alessandro Del Ferro -
Biselx Nicolas -
Jan Sigurd Refvik -
Morten Brekkevold