Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

Category: Fortigate
(page 2 of 3)

Everyone today speaks BGP: Cisco routers, Juniper routers and ScreenOS firewalls, Fortigate does it,even SonicWall have it as planned feature So question is not whether but how. The opportunity to see how it works on Fortigate recently presented itself and here is the sum up of how I configured and debugged Fortigate BGP set up.
[showmyads]
Task at hand: configure BGP peering with Bogon Route project by Team Cymru www.team-cymru.org/Services/Bogons/routeserver.html . More information about the Bogon Routes can be found at the source – www.team-cymru.org/Services/Bogons . But in few words they advertise to you routes that are never to be seen in your network for legitimate reasons. Those are networks not only from RFC 1918 but those reserved by RIPE for special purposes, and those unallocated to anyone as of now.
What we need to know for this set up is this:

They advertise all the networks with no-export community

also they attach 65333:888 community (as per their site)

they use md5 password authentication

they don’t expect you to advertise to them anything

in advertised networks next hop is their advertising router

their AS number is 65333

Based on all the above my Fortigate BGP peer had to :

enable multihop peering

use MD5 password authentication

have route-map to attach no-export community so that we don’t inadvertently advertise learned routes to other peers ( just safety net , in case BGP peer stops attaching no-export community to their routes)

set next hop for the learned routes to Null 0 interface.

Let’s start configuring something. Important surprise here – in Fortigate GUI you can only set 3 parameters:As number , Peer Ip and networks to be advertised, the rest is to be done on the command line . So here it goes
1) Configuring route-map to set no-export community on learned networks and force next hop to be some reserved Ip (192.0.2.1 ) that in turn is statically routed to Null interface ,

config router route-map
edit “NO-EXPORT”
config rule
edit 3
set set-community “no-advertise”
set set-ip-nexthop 192.0.2.1
next
end
next
End

2) Configure BGP peer

(root) # show router bgp
config router bgp
set as 65002
config neighbor
edit 84.22.96.5
set ebgp-enforce-multihop enable
set remote-as 65333
set route-map-in “NO-EXPORT”
set password “yuiyui”
next
end
config redistribute “connected”
set status enable
end

3) Configure static blackhole route for the reserved IP used as the next hop for this.

The good way to judge something new is to compare it with something you already know. To continue
With that logic I cross-reference debug output seen on Fortigate with the one seen on the Cisco BGP peer. That
way you can decide what is more informative and who wins the race (Cisco of course, what you thought?).

Case 1One of the peers is configured with wrong AS number.
In Fortigate you see this:

Case 4 On Cisco ttl-security is enabled while on Forigate ebgp multi-hop is not .
There is no such thing as TTL security on the Fortigate by the way, all you can do to handle this state is enable ebgp-multihop and them it starts sending BGP packets with ttl = 255 .

Once upon a time reading some CCIE paper at work I asked myself a question : “Why would someone bother to invent ttl-security and even write RFC http://tools.ietf.org/html/rfc5082 on it when multi-hop EBGP feature provides the same end result ?” .
The results of my busy/doing-nothing activity I present here.First some background. For some (unknown to me) reasons BGP peering was envisioned as TCP connection between directly connected routers, by default. To proceed with this design (worth checking BGP RFCs if it was actually an obligation) vendors (Cisco,Juniper and even Fortinet) implemented all BGP protocol communication using TTL=1 in TCP packets being exchanged. As the logical consequence of this if a router was placed more than 1 hop away from its peer BGP session could not be established. To provide for such set ups when peers are many hops away the ebgp-multihop term was coined – on configuration level you can specify that BGP peer is that hops far away . What happens in fact is that when you specify such multi-hop BGP peer the router starts sending BGP packets with TTL being equal to the number of hops you set . That means if I set peer to be 3 hops away and some attacker tries to spoof legit peer’s IP but is 4 hops away – such attack won’t succeed cause my router will receive spoofed BGP packets ok but will send replies with TTL of 3 which will expire just 1 hop away from the attacker.
Questionable , but security . So why ttl security?
This feature indeed enforces that BGP peer is no more than given hops away . And here comes the difference – it enforces it inbound . It works this way – after you enable ttl security on the BGP peer session and specify how many hops away this peer is allowed to be, your router
checks incoming TCP packets from this peer and does this simple calculation ; configured value <= 255 – hops-away-to-peer , if it holds true your router goes on with establishing BGP session , if not – session is shut down. Regarding outgoing TTL values – may be it is Cisco-only thing, may be not , but the moment you enable ttl security for some BGP peer on Cisco the router itself starts sending BGP-related packets to this peer with initial ttl being equal to 255. I guess it is logical that if you enforce on your side ttl security the peering side will want to do the same.

As someone said best things in life are free.
Here are links to the demo Forigate firewall, ForiAnalyzer and FortiManager open to access from anywhere . So that you can
familiarize yourself with the Management GUI look and feel.
NOTE: Access is read-only.
NOTE 2: No , it is not me being so generous, it’s Fortinet caring for us.Fortigate 300 :
user:demo
password: fortigate fortigate.comForiAnalyzer 800:
user:demo
password: fortianalyzerfortianalyzer.com FortiManager 400:
user:demo
password: fortimanagerfortimanager.com

Recently I had to do late night restart of a Fortigate and was looking for “Reload in…”
I found it, but in Fortigate it is a little different.
It’s called Daily Restart, and if you want to use it once you need to remember to remove this command.

config system global
set daily-restart enable
set restart time 04:00
end

Now the FortiGate is configured to reboot at 4 AM (System Time).
Don’t forget to update the system clock (Use NTP, Always keeps it synced)

Ping.
[showmyads]
Many times while debugging network problems of various kinds you need to send some packets
of desirable size and don’t fragment bit being set. Below I list how to do it for the different
equipment/OSes.
Let’s start with the most popular operating system among network folks – Linux:

Linux

By default ping in any Linux-based system (It also means any distribution – Slackware, Ubuntu, CentOS etc) is sent with
Don’t fragment (df) bit set . You don’t need to add any command line switches for that.
Here is what you get by default ping in Linux:
Defaults:
Don’t fragment bit (in echo request) – set
Ip packet size – 84 bytes
Sending interval – 1 second

Here: size – size of data in ICMP packet (bytes);-I 0.5 – interval of 5 seconds (optional);-c 3 – number of pings in each size session (NOT optional – or you will enter an endless loop which even Ctrl-C won’t be able
to stop )

SOLARIS
Defaults:
Don’t fragment bit – not set , and not changeable , yes , it sounds strange but Solaris doesn’t
support df bit in its ping utility. You may set df bit in their traceroute program , but it has no provision for changing size of the packet and therefore is of no value for our case.

Today encountered otherwise easy to diagnose misconfiguration only that Fortinet decided to ‘hide’ this parameter deep enough so that it got on my nerves until I fixed it.
[showmyads]

NOTE : Fortiguard is subscription based service when your Fortigate unit periodically
connects to the Fortinet servers (collectively named Fortiguard servers) to get info that enables advanced
feautures like filtering by category/rating.

Problem – suddenly Fortigate of the client refused to do web/spamfiltering service while having valid contract subscription. Not a big deal as in System -> Maintenance -> Fortiguard status was “Failed to connect ” (or something of a kind dont recall it now) . On the same page there is a nice button “Test Availability” pushing which would bring error “Connection failed Check firewall routing table” .
In most of the cases it is either reachability issue or Fortigate is trying to update against wrong server.
Doing pings successfuly from the firewall to service.fortiguard.net (FQDN to use for Fortiguard servers)
left 2nd option – wrong Fortiguard server hardcoded somewhere in the configs. DoingFG100 # show system fortiguard Gave only this
config system fortiguard
set antispam-cache disable
set webfilter-cache disable
end

To fix this you enter:FG100 # config system fortiguardFG100 (fortiguard) # set
*hostname hostname or IP of the FortiGuard serverFG100 (fortiguard) # set service.fortiguard.net
FG100 (fortiguard) #next

* FortiOS 3.x uses service.fortiguard.net , FortiOS 2.80 used guard.fortinet.net for Webfiltering and
antispam.fortigate.com for Antispam filtering and it is Fortinet recommendation to do so, nevertheless
setting guard.fortinet.net in Fortios 3 works as well (after all they are CNAME’d )

And while we are on it, here are few useful debug commands for the topic:

You can’t set duplex/speed settings of the Fortigate interfaces. Important FIX: depends on which interface you are trying to set! [ Thanks to Chen for pointing out ]
Upon careful reexamination turns out that you can’t set duplex/speed settings of 4-port switch interfaces only, i.e. Internal interface of Fortigate 60, 60M, 100A, 200A, and FortiWiFi-60 and also LAN interface of 500A .
Tried on FG100A FortiOS v4.0,build0178,090820 (MR1)
[showmyads]

Working most of the time with Cisco gear I’m (and others) used to being able to set duplex/speed
parameters on the physical interfaces to my liking.
This comes as a necessity when connecting cisco to various equipment of differing quality. So it was a surprise to me when I encountered strange layer1/layer2 connectivity problem between some Fortigate 200A and cisco and tried to set manually duplex full/speed 100 on the Fortigate just to find out that it is impossible to do it on the Fortigate.
It was possible back in the days of FortiOS 2.80 (and early 3.0 – I guess up until MR5) :

But then Fortinet dropped this option and the only (not direct) explanation
found on their site is this memo:
“Locked-down port policies (forcing speed, duplex, and link capabilities with auto-negotiation disabled) are
outdated. Legacy and historical reasons for forced setup with auto-negotiation disabled date
back many years when the technology was new…”

Now we can see what is the negotiated status of the links
(this command also shows errors/collisions/MTU on the interface) :