Browsed by
Category: Fortinet

Fortigate SNMP monitoring

Fortigate SNMP monitoring

Technical Note: SNMP ifDescr missing in FortiOS 5.4

Description With FortiOS 5.2, and lower the “ifDescr” OID is systematically filled in with the interface name. 

This behavior was not compliant as per RFC 1213 that states: “ifDescr should be filled in with a textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface.” 

Since  FortiOS 5.4 and above, the “ifDesc” OID now behaves as per RFC 1213 i.e. “ifDesc” OID is effectively filled in with the interface description, that is: 
– The “description” variable value of each specific interface (CLI) 
– The “comment” field value of each specific interface (GUI) 

To summarize, in FortiOS 5.4 and above: 
– ifDescr OID returns the interface description 
– ifAlias OID returns interface alias 
– ifName OID returns interface name 

On FortiGates running FortiOS 5.2.x, all interfaces by default have SNMP ifDescr MIB populated.$ snmpwalk -v3 -u blahblah -a MD5 -A blahblah1 -x DES -X blahblah1 -l authPriv -Oa 10.8.8.8 | grep -i descSNMPv2-MIB::sysDescr.0 = STRING: Fortigate v5.2.11SNMPv2-MIB::sysORDescr.1 = STRING:IF-MIB::ifDescr.1 = STRING: port1IF-MIB::ifDescr.2 = STRING: port2IF-MIB::ifDescr.3 = STRING: port3IF-MIB::ifDescr.4 = STRING: port4IF-MIB::ifDescr.5 = STRING: port5IF-MIB::ifDescr.6 = STRING: port6IF-MIB::ifDescr.7 = STRING: port7IF-MIB::ifDescr.8 = STRING: port8IF-MIB::ifDescr.9 = STRING: port9IF-MIB::ifDescr.10 = STRING: port10IF-MIB::ifDescr.13 = STRING: ssl.root

FortiGate running FortiOS 5.4.x the default SNMP ifDescr MIB values have changed
$ snmpwalk -v3 -u blahblah -a MD5 -A blahblah1 -x DES -X blahblah1 -l authPriv -Oa 10.8.8.8 | grep -i descSNMPv2-MIB::sysDescr.0 = STRING: Fortigate v5.4.5SNMPv2-MIB::sysORDescr.1 = STRING:IF-MIB::ifDescr.1 = STRING:IF-MIB::ifDescr.2 = STRING:IF-MIB::ifDescr.3 = STRING:IF-MIB::ifDescr.4 = STRING:IF-MIB::ifDescr.5 = STRING:IF-MIB::ifDescr.6 = STRING:IF-MIB::ifDescr.7 = STRING:IF-MIB::ifDescr.8 = STRING:IF-MIB::ifDescr.9 = STRING:IF-MIB::ifDescr.10 = STRING:IF-MIB::ifDescr.11 = STRING: Workaround

In FortiOS v5.4 you can get the port descriptions using the following MIB

IF-MIB:ifMIB.ifMIBObjects.ifXTable.ifXEntry – 1.3.6.1.2.1.31.1.1.1

How to use the DNS translation feature

How to use the DNS translation feature

Description
The DNS translation feature available in the FortiOS firmware is designed to modify the DNS reply from a DNS server.

It is typically used to allow internal users of a network to access resources with their private IP addresses, hence can simplify the firewall configurations.

A network diagram is provided below with an example that illustrates on how to configure this feature.

In this example, the client sends a DNS resolution request to the DNS server 172.31.17.252 for resource “server1.lab.mycompany.com” . The DNS reply sent by the DNS server is 172.31.17.37 (this is the public IP address of “server1”), but the reply is translated on the FortiGate unit into 10.73.1.37, which is the private IP address of the same resource, “server1”.

 

Solution
How internal users can access internal resources via an external VIP

How internal users can access internal resources via an external VIP

Products
FortiGate
Description
This article describes a solution for the following requirement :

A user located to an internal LAN needs to access a server located on an internal LAN or DMZ by using however a public Virtual IP on the Fortigate.
External users also access the same server via the “external” port.

The following diagram illustrates this scenario :

port3
10.67.2.82 10.67.0.176 port1
[ INTERNAL USER ] ====|==== [ FortiGate ] == VIP 172.31.16.164 == [ EXTERNAL USERS ]
| | 172.31.19.113
[ SERVER1 ] ==========| | port2
10.67.0.164 |10.67.0.176
|
[ SERVER2 ] ==========================|
10.91.3.113

The INTERNAL USER PC is accessing the SERVER1 and SERVER2 with destination IP = 172.31.16.164 or 172.31.19.113, which in turn gets translated to the real servers IP and routed back to the servers.
Solution
FortiGate configuration excerpt :
========================

config firewall vip
edit “SERVER1”
set extip 172.31.16.164
set extintf “any” <<< Specifying “any” is a requirement
set mappedip 10.67.0.164
next
end
edit “SERVER2”
set extip 172.31.19.113
set extintf “any” <<< Specifying “any” is a requirement set mappedip 10.91.3.113 next config firewall policy edit 4 set srcintf “port1” set dstintf “port3” set srcaddr “all” set dstaddr “SERVER1” set action accept set schedule “always” set service “ANY” next edit 3 set srcintf “port3” set dstintf “port3” set srcaddr “all” set dstaddr “SERVER1” set action accept set schedule “always” set service “ANY” next edit 5 set srcintf “port1” set dstintf “port2” set srcaddr “all” set dstaddr “SERVER2” set action accept set schedule “always” set service “ANY” next edit 6 set srcintf “port3” set dstintf “port2” set srcaddr “all” set dstaddr “SERVER2” set action accept set schedule “always” set service “ANY” next end Note : policy 4 and 5 are used for external users ; policy 3 and 6 are used for internal users. Traffic flow snippet an HTTP session from USER to SERVER1: ============================================== FGT-1 (root) # diagnose sniffer packet any “host 10.67.2.82 or host 10.67.0.164” 4 interfaces=[any] filters=[host 10.67.2.82 or host 10.67.0.164] 6.798488 port3 in 10.67.2.82.2080 -> 172.31.16.164.8090: syn 391946722
6.798556 port3 out 10.67.0.176.26756 -> 10.67.0.164.80: syn 391946722
6.798856 port3 in 10.67.0.164.80 -> 10.67.0.176.26756: syn 3548167716 ack 391946723
6.798873 port3 out 172.31.16.164.8090 -> 10.67.2.82.2080: syn 3548167716 ack 391946723
6.799125 port3 in 10.67.2.82.2080 -> 172.31.16.164.8090: ack 3548167717
6.799131 port3 out 10.67.0.176.26756 -> 10.67.0.164.80: ack 3548167717

Note : for this traffic (port3 to port3), even though NAT is not enabled on the policy, the source IP address gets translated with the Fortigate internal IP address.

Session list for an HTTP session from USER to SERVER1
==========================================

FGT-1 (root) # diagnose sys session list

session info: proto=6 proto_state=05 duration=2 expire=0 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=5
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 hakey=758
policy_dir=0 tunnel=/
state=may_dirty
statistic(bytes/packets/allow_err): org=3407/13/1 reply=18467/19/1 tuples=4
orgin->sink: org pre->post, reply pre->post dev=4->4/4->4 gwy=10.67.0.164/10.67.2.82
hook=pre dir=org act=dnat 10.67.2.82:2075->172.31.16.164:8090(10.67.0.164:80)
hook=post dir=org act=snat 10.67.2.82:2075->10.67.0.164:80(10.67.0.176:26815)
hook=pre dir=reply act=dnat 10.67.0.164:80->10.67.0.176:26815(10.67.2.82:2075)
hook=post dir=reply act=snat 10.67.0.164:80->10.67.2.82:2075(172.31.16.164:8090)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=3 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0080d305 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_rule_id=0
per_ip_bandwidth meter: addr=10.67.2.82, bps=19399

Traffic flow snippet an HTTP session from USER to SERVER2:
==============================================

FGT1# diagnose sniffer packet any “host 10.67.2.82 or host 10.91.3.113 and port 80” 4

4.741440 port3 in 10.67.2.82.2726 -> 172.31.19.113.80: syn 53278201
4.741515 port2 out 10.67.2.82.2726 -> 10.91.3.113.80: syn 53278201
4.741697 port2 in 10.91.3.113.80 -> 10.67.2.82.2726: syn 153837872 ack 53278202
4.741722 port3 out 172.31.19.113.80 -> 10.67.2.82.2726: syn 153837872 ack 53278202
4.742024 port3 in 10.67.2.82.2726 -> 172.31.19.113.80: ack 153837873
4.742033 port2 out 10.67.2.82.2726 -> 10.91.3.113.80: ack 153837873
4.742917 port3 in 10.67.2.82.2726 -> 172.31.19.113.80: psh 53278202 ack 153837873
4.742924 port2 out 10.67.2.82.2726 -> 10.91.3.113.80: psh 53278202 ack 153837873
4.743306 port2 in 10.91.3.113.80 -> 10.67.2.82.2726: ack 53279042
4.743315 port3 out 172.31.19.113.80 -> 10.67.2.82.2726: ack 53279042

Session list for an HTTP session from USER to SERVER2
==========================================

session info: proto=6 proto_state=01 duration=2 expire=3597 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 hakey=1475
policy_dir=0 tunnel=/
state=may_dirty
statistic(bytes/packets/allow_err): org=92/2/1 reply=52/1/1 tuples=2
orgin->sink: org pre->post, reply pre->post dev=4->3/3->4 gwy=10.91.3.113/10.67.2.82
hook=pre dir=org act=dnat 10.67.2.82:2752->172.31.19.113:80(10.91.3.113:80)
hook=post dir=reply act=snat 10.91.3.113:80->10.67.2.82:2752(172.31.19.113:80)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=6 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0082338c tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_rule_id=0
per_ip_bandwidth meter: addr=10.67.2.82, bps=4049