yurisk.info

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

Category: Fortigate (page 2 of 3)

Fortigate BGP – configure and debug

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.

(root) # sh router static
config router static
edit 3
set blackhole enable
set dst 192.0.2.1 255.255.255.255
next
End

Validation phase.
All configs are as good as the prove that it works.

List shortly all the peers

(root) # get router info bgp summary
BGP router identifier 10.250.250.2, local AS number 65002
BGP table version is 159
2 BGP AS-PATH entries
0 BGP community entries
 
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
84.22.96.5   4  65333       4       6      159    0    0 00:00:48        0
 
Total number of neighbors 1 

List all BGP neighbors and their peering state

My-FG (root) # get router info bgp neighbors
BGP neighbor is 84.22.96.5, remote AS 65333, local AS 65002, external link
  BGP version 4, remote router ID 84.22.96.5
  BGP state = Established, up for 00:00:58
  Last read 00:00:58, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received (old and new)
    Address family IPv4 Unicast: advertised and received
  Received 4 messages, 0 notifications, 0 in queue
  Sent 6 messages, 0 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
 
 For address family: IPv4 Unicast
  BGP table version 160, neighbor version 159
  Index 3, Offset 0, Mask 0x8
  Community attribute sent to this neighbor (both)
  Inbound path policy configured
  Route map for incoming advertisements is *NO-EXPORT
  0 accepted prefixes
  19 announced prefixes
  Connections established 1; dropped 0
  External BGP neighbor may be up to 255 hops away.
Local host: 10.250.250.2, Local port: 9188
Foreign host: 84.22.96.5, Foreign port: 179
Nexthop: 10.250.250.1

See the routes learned through the BGP protocol

(root) # get router info bgp network
BGP table version is 161, local router ID is 10.250.250.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
*> 5.0.0.0          192.0.2.1                0             0 65333 65333 i
*> 14.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 23.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 31.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 36.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 37.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 39.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 42.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 49.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 100.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 101.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 102.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 103.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 104.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 105.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 106.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 169.254.0.0      192.0.2.1                0             0 65333 65333 i
*> 172.16.0.0/12    192.0.2.1                0             0 65333 65333 i
*> 176.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 177.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 179.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 181.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 185.0.0.0/8      192.0.2.1                0             0 65333 65333 i
 

List routes that are currently installed in the routing table that were learned by BGP .

(root) # get router info routing-table bgp
B       5.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       14.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       23.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       31.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       36.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       37.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       39.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       42.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19

After all is configured and saved (and probably doesn’t work) comes the bgp debug round.
Enable bgp debug on the appliance

#diag ip router bgp all enable

Enable debug output to console

diag debug enable

To stop this output

diagnose debug disable

To verify that debug is on

# diag ip router bgp show
BGP debugging status:
  BGP events debugging is on
  BGP debug level: INFO 

If nothing after that happens try clearing all BGP sessions

#exec router clear bgp all

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 1
One of the peers is configured with wrong AS number.
In Fortigate you see this:

BGP: 84.22.96.5-Outgoing [FSM] State: Idle Event: 3
BGP: 84.22.96.5-Outgoing [NETWORK] FD=15, Sock Status: 0-Success
BGP: 84.22.96.5-Outgoing [FSM] State: Connect Event: 17
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 1
BGP: 84.22.96.5-Outgoing [ENCODE] Open: Ver 4 MyAS 65002 Holdtime 180
BGP: 84.22.96.5-Outgoing [ENCODE] Open: Msg-Size 45
BGP: 84.22.96.5-Outgoing [DECODE] Msg-Hdr: type 3, length 23
BGP: %BGP-3-NOTIFICATION: received from 84.22.96.5 2/2 (OPEN Message Error/Bad Peer AS.) 2 data-bytes

Now let’s compare to the debug from Cisco

#debug ip bgp events
Mar 24 13:14:55.572: %BGP-3-NOTIFICATION: sent to neighbor 10.250.250.2 2/2 (peer in wrong AS) 2 bytes FDEA FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 FAEA 01B4 0AFA EA02 1302 0201 1400 0100 0132 0222 0012 0222 00

Case 2
MD5 authentication is set on Cisco but not on the Fortigate. Again for comparison
debug from Fortigate and debug from Cisco
Cisco:

Jan  5 10:42:14.299: %TCP-6-BADAUTH: No MD5 digest from 10.250.250.2 (1037) to 84.22.96.5(179)

Fortigate:

84.22.96.5-Outgoing [FSM] State: Connect Event: 9
BGP: [RIB] Scanning BGP Network Routes...
84.22.96.5-Outgoing [FSM] State: Connect Event: 9
BGP: [RIB] Scanning BGP Network Routes...

Case 3 (that actually happened when I configured this Fortigate) is mismatched MD5 password on either side

Fortigate:
Doing summary listing showed peering as down :

84.22.96.5   4  65333     934    1036        0    0    0    never Connect 

Cisco:

*Mar 24 13:40:28.800: BGP: Regular scanner event timer
*Mar 24 13:40:28.800: BGP: Import timer expired. Walking from 1 to 1
*Mar 24 13:40:42.764: %TCP-6-BADAUTH: Invalid MD5 digest from 10.250.250.2(11064) to 84.22.96.5(179)
 

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 .

Cisco:

Jan  7 13:01:36.992: %BGP-4-INCORRECT_TTL: Discarded message with TTL 2 from 10.250.250.2

Forigate:

BGP: 84.22.96.5-Outgoing [FSM] State: OpenConfirm Event: 11
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 4
BGP: 84.22.96.5-Outgoing [ENCODE] Keepalive: 13548 KAlive msg(s) sent
84.22.96.5-Outgoing [FSM] State: OpenConfirm Event: 10
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 3
BGP: %BGP-3-NOTIFICATION: sending to 84.22.96.5 4/0 (Hold Timer Expired/Unspecified Error Subcode) 0 data-bytes
BGP: 84.22.96.5-Outgoing [FSM] State: Idle Event: 3
BGP: 84.22.96.5-Outgoing [NETWORK] FD=14, Sock Status: 111-Connection refused
BGP: 84.22.96.5-Outgoing [FSM] State: Connect Event: 18

Bonus Case Bug-not-a-feature thing on the Fortigate – when configuring MD5 password for BGP authentication you get Cross-Site vulnerability protection for free 🙂 Don’t ask me how XSS is connected to cli configuration of BGP …

set password <2AEARep>

The string contains XSS vulnerability characters
value parse error before ”
Command fail. Return code -173

Difference between ebgp-multihop and ttl-security.

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.

When ttl rule is broken we see in the debug session:
Dec 27 19:08:04.103: %BGP-4-INCORRECT_TTL: Discarded message with TTL 1 from 124.2.11.15
And neighbor status is:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
124.2.11.15 4 13462 33 63 0 0 0 00:04:31 Idle

#sh ip bgp neighbors 124.2.11.15
BGP neighbor is 124.2.11.15, remote AS 13462, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Closing

Fortigate firewall demo free access. Also FortiManager and FortiAnalyzer

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.com
ForiAnalyzer 800:
user:demo
password: fortianalyzer
fortianalyzer.com
FortiManager 400:
user:demo
password: fortimanager
fortimanager.com

Scheduled Daily Reboot of FortiGate

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 – setting don’t fragment bit in Linux/FreeBSD/Solaris/Cisco/Juniper

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

Some examples.
– sending pings station:
[root@lonestar ~]# ping 191.91.21.41
–   receiving station:
[root@darkstar ~]# tcpdump -s 1500 -n -vv icmp
21:23:51.598641 IP (tos 0x0, ttl  61, id 20, offset 0, flags [DF], proto: ICMP (1), length: 84) 112.225.125.100 > 10.99.99.150: ICMP echo request, id 5392, seq 20, length 64
21:23:51.598817 IP (tos 0x0, ttl  64, id 7135, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.150 > 112.225.125.100: ICMP echo reply, id 5392, seq 20, length 64
To change sent packet size:
-s  <size> , bytes (8 bytes of ICMP header will be added automatically).

Sending host:
[root@darkstar ~]# ping 10.99.99.158 -s 1300
PING 10.99.99.158 (10.99.99.158) 1300(1328) bytes of data.
1308 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=1.65 ms

Receiving host:
freeBSD# tcpdump -n -v -s 1500 icmp
16:15:11.901787 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 44399, seq 63, length 1308
To change sending interval (mostly used together with large packet size) :
-i  <secs>

Sending host:
[root@darkstar ~]# ping -s 1300 -i 0.2 10.99.99.158

Receiving host:
freeBSD# tcpdump -n -v -s 1500 icmp
16:20:11.223481 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 1136, seq 396, length 1308
16:20:11.223496 IP (tos 0x0, ttl 64, id 805, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.158 > 10.99.99.150: ICMP echo reply, id 1136, seq 396, length 1308

To force Linux to send pings with DF bit cleared (i.e. not set):
ping –M don’t

Sending host:

[root@darkstar ~]# ping -s 1300 -M dont  10.99.99.158
PING 10.99.99.158 (10.99.99.158) 1300(1328) bytes of data.
1308 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.560 ms

Receiving host:

freeBSD# tcpdump -n -v -s 1500 icmp
16:28:33.111903 IP (tos 0x0, ttl 64, id 41857, offset 0, flags [none], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 33136, seq 6, length 1308
16:28:33.111920 IP (tos 0x0, ttl 64, id 9425, offset 0, flags [none], proto ICMP (1), length 1328) 10.99.99.158 > 10.99.99.150: ICMP echo reply, id 33136, seq 6, length 1308

SideNote: FreeBSD ping has a nice add-on (see below) – sweeping size of the packets, while Linux doesn’t have such extra feature,
Below is script to emulate it on Linux:
awk  ‘ BEGIN  {for (size=100;size<1470;size++)  {
cmd = (“ping –c 3 –I 0.5 –s  ” size  ”  ”  “10.99.99.158”)
print cmd | “/bin/bash”
close(“/bin/bash”)  } } ‘

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 )

See it in action:
[root@darkstar ~]# awk  ‘ BEGIN  {for (size=100;size<1470;size++)  {
cmd = (“ping -c 3 -i 0.5 -s  ” size  ”  ”  “10.99.99.158”)
print cmd | “/bin/bash”
close(“/bin/bash”)  } } ‘
PING 10.99.99.158 (10.99.99.158) 100(128) bytes of data.
108 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=1.75 ms
108 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.276 ms
108 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.201 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.201/0.742/1.750/0.713 ms
PING 10.99.99.158 (10.99.99.158) 101(129) bytes of data.
109 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.185 ms
109 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.253 ms
109 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.230 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.185/0.222/0.253/0.033 ms
PING 10.99.99.158 (10.99.99.158) 102(130) bytes of data.
110 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.118 ms
110 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.201 ms
110 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.343 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.118/0.220/0.343/0.094 ms
PING 10.99.99.158 (10.99.99.158) 103(131) bytes of data.
111 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.565 ms
111 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.182 ms
111 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.329 ms
FreeBSD

Defaults:
Don’t fragment bit – not set   ; use –D  option to set
IP Packet size:  84 bytes  ;  use –s option to change
Sending interval:  1 sec  ;   use  –I  <secs> to change
e.g. Sending pings  of data size 1300 bytes with interval 0.2 seconds with df bit set:

Sending host[10.99.99.158]:
freeBSD# ping -D -s 1300 -i 0.2 10.99.99.150

Receiving host[10.99.99.150]:
[root@darkstar ~]# tcpdump -n -v -s 1500  host 10.99.99.158
20:42:57.816697 IP (tos 0x0, ttl  64, id 11630, offset 0, flags [DF], proto: ICMP (1), length: 1328) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 10770, seq 23, length 1308
20:42:57.816914 IP (tos 0x0, ttl  64, id 33327, offset 0, flags [none], proto: ICMP (1), length: 1328) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 10770, seq 23, length 1308

SideNote: *BSD family  has  a nice additional option  not found in most other systems  – you can  order ping to sweep size of sent packets .
Example follows:

Here sweep range is from 20 bytes up to 1400 bytes, increase step is 300 bytes.

Sending host[10.99.99.158]:
freeBSD# ping -D g 20 -G 1400 -h 300 10.99.99.150
PING 10.99.99.150 (10.99.99.150): (20 … 1400) data bytes
28 bytes from 10.99.99.150: icmp_seq=0 ttl=64 time=1.313 ms
328 bytes from 10.99.99.150: icmp_seq=1 ttl=64 time=0.531 ms
628 bytes from 10.99.99.150: icmp_seq=2 ttl=64 time=0.581 ms
928 bytes from 10.99.99.150: icmp_seq=3 ttl=64 time=0.362 ms
1228 bytes from 10.99.99.150: icmp_seq=4 ttl=64 time=0.223 ms

— 10.99.99.150 ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.223/0.602/1.313/0.377 ms
Receiving host[10.99.99.150]:
[root@darkstar ~]# tcpdump -n -v -s 1500  host 10.99.99.158
21:50:06.942165 IP (tos 0x0, ttl  10.99.99.150 64, id 12828, offset 0, flags [DF], proto: ICMP (1), length: 48) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 0, length 28
21:50:06.944098 IP (tos 0x0, ttl  64, id 43255, offset 0, flags [none], proto: ICMP (1), length: 48) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 0, length 28
21:50:07.944761 IP (tos 0x0, ttl  64, id 12831, offset 0, flags [DF], proto: ICMP (1), length: 348) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 1, length 328
21:50:07.944826 IP (tos 0x0, ttl  64, id 43256, offset 0, flags [none], proto: ICMP (1), length: 348) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 1, length 328
21:50:08.945815 IP (tos 0x0, ttl  64, id 12833, offset 0, flags [DF], proto: ICMP (1), length: 648) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 2, length 628
21:50:08.945890 IP (tos 0x0, ttl  64, id 43257, offset 0, flags [none], proto: ICMP (1), length: 648) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 2, length 628
21:50:09.946724 IP (tos 0x0, ttl  64, id 12835, offset 0, flags [DF], proto: ICMP (1), length: 948) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 3, length 928
21:50:09.946819 IP (tos 0x0, ttl  64, id 43258, offset 0, flags [none], proto: ICMP (1), length: 948) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 3, length 928

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.

Non-verbose ; use –s to override
IP packet size:  84 bytes

Pinging with defaults:
root@solaris:~# ping -s 10.99.99.150
PING 10.99.99.150: 56 data bytes
64 bytes from 10.99.99.150: icmp_seq=0. time=0.759 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v -s 1500  host 10.99.99.159
20:50:08.084364 IP (tos 0x0, ttl 255, id 8020, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.159 > 10.99.99.150: ICMP echo request, id 9096, seq 7, length 64
20:50:08.084538 IP (tos 0x0, ttl  64, id 52389, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.150 > 10.99.99.159: ICMP echo reply, id 9096, seq 7, length 64

To change size of sent packet, to say 1300 bytes of data:

root@solaris:~# ping -s 10.99.99.150  1320
PING 10.99.99.150: 1320 data bytes
1328 bytes from 10.99.99.150: icmp_seq=0. time=1.610 ms
1328 bytes from 10.99.99.150: icmp_seq=1. time=0.335 ms
SideNote: There is no size sweeping capability built-in , so I wrote  this script to   emulate this feature  in Solaris as well:
root@solaris:~# awk  ‘ BEGIN  {for (size=100;size<1470;size=size+10)  {
cmd = (“ping   -s ”    “10.99.99.158 ” size  ” 3″)
print cmd | “/bin/bash”
close(“/bin/bash”)  } } ‘

Here :
size –  size of date in ICMP packet , starts at 10 bytes ends at 170 bytes
size+10 – size incrementing by 10 bytes each series of pings
3 – number of pings in each size set.

Results:
root@solaris:~# awk  ‘ BEGIN  {for (size=100;size<1470;size=size+10)  {
cmd = (“ping   -s ”    “10.99.99.158 ” size  ” 3″)
print cmd | “/bin/bash”
close(“/bin/bash”)  } } ‘
PING 10.99.99.158: 100 data bytes
108 bytes from 10.99.99.158: icmp_seq=0. time=0.319 ms
108 bytes from 10.99.99.158: icmp_seq=1. time=0.460 ms
108 bytes from 10.99.99.158: icmp_seq=2. time=0.328 ms

—-10.99.99.158 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.319/0.369/0.460/0.079
PING 10.99.99.158: 110 data bytes
118 bytes from 10.99.99.158: icmp_seq=0. time=0.371 ms
118 bytes from 10.99.99.158: icmp_seq=1. time=0.370 ms
118 bytes from 10.99.99.158: icmp_seq=2. time=0.477 ms

—-10.99.99.158 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.370/0.406/0.477/0.061
PING 10.99.99.158: 120 data bytes
128 bytes from 10.99.99.158: icmp_seq=0. time=0.395 ms
128 bytes from 10.99.99.158: icmp_seq=1. time=0.361 ms
128 bytes from 10.99.99.158: icmp_seq=2. time=0.264 ms

CISCO routers (IOS)

Defaults:
IP packet size : 100 bytes ;  use size <size> to change
Don’t fragment bit – not set  ;  use df-bit to set

Running with defaults:
Tokyo#ping 191.91.21.41
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v  -s 1500 icmp
22:16:53.758056 IP (tos 0x0, ttl 253, id 11, offset 0, flags [none], proto: ICMP (1), length: 100) 174.93.31.134 > 10.99.99.150: ICMP echo request, id 4, seq 0, length 80
22:16:53.758246 IP (tos 0x0, ttl  64, id 10923, offset 0, flags [none], proto: ICMP (1), length: 100) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 4, seq 0, length 80
< — Cut for brevity –>
Setting df bit and size of the packet size  (Note – here when you set size of the ping you set IP packet size and not ICMP data size as  in *Nix systems).
Repeat count is set to 3 .
Tokyo#ping 191.91.21.41 size 1300 df-bit rep 3
Type escape sequence to abort.
Sending 3, 1300-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
Packet sent with the DF bit set
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 4/4/4 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v  -s 1500 icmp
22:18:16.657849 IP (tos 0x0, ttl 253, id 21, offset 0, flags [DF], proto: ICMP (1), length: 1300) 174.93.31.134  > 10.99.99.150: ICMP echo request, id 6, seq 0, length 1280
22:18:16.658028 IP (tos 0x0, ttl  64, id 10933, offset 0, flags [none], proto: ICMP (1), length: 1300) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 6, seq 0, length 1280
Sweeping ping size.
This feature is available from extended ping menu:
Rio#ping
Protocol [ip]:
Target IP address: 191.91.21.41
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]:
Sweep max size [18024]: 1700
Sweep interval [1]: 100
Type escape sequence to abort.
Sending 85, [36..1700]-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!
Receiving host:
10:35:22.563851 IP (tos 0x0, ttl 253, id 179, offset 0, flags [DF], proto: ICMP (1), length: 36) 174.93.31.134  > 10.99.99.150: ICMP echo request, id 9, seq 0, length 16
10:35:22.563891 IP (tos 0x0, ttl  64, id 46861, offset 0, flags [none], proto: ICMP (1), length: 36) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 9, seq 0, length 16
10:35:22.566205 IP (tos 0x0, ttl 253, id 180, offset 0, flags [DF], proto: ICMP (1), length: 136) 174.93.31.134  > 10.99.99.150: ICMP echo request, id 9, seq 1, length 116
10:35:22.566223 IP (tos 0x0, ttl  64, id 46862, offset 0, flags [none], proto: ICMP (1), length: 136) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 9, seq 1, length 116

Juniper routers (JunOS):
Defaults:
Ip packet size : 84 bytes
Don’t fragment bit – not set; use do-not-fragment to set
Interval  – 1 sec;  use interval <secs> to change
Sending pings with df bit set and size 1470 bytes
root@Juniper> ping 192.168.37.29 do-not-fragment size 1470
ping 192.168.37.29 do-not-fragment size 1470
PING 192.168.37.29 (192.168.37.29): 1470 data bytes
1478 bytes from 192.168.37.29: icmp_seq=0 ttl=64 time=1.434 ms
1478 bytes from 192.168.37.29: icmp_seq=1 ttl=64 time=0.210 ms

— 192.168.37.29 ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.203/0.513/1.434/0.532 ms

IF packet size too large and df is set you get this:

root@Juniper> ping 192.168.37.29 do-not-fragment size 13000
ping 192.168.37.29 do-not-fragment size 13000
PING 192.168.37.29 (192.168.37.29): 13000 data bytes
ping: sendto: Message too long

Failed to connect to Fortiguard servers

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. Doing
FG100 # show system fortiguard Gave only this
config system fortiguard
set antispam-cache disable
set webfilter-cache disable
end

And only doing FG100 # get system fortiguard Gave the answer
hostname : 66.92.33.1
srv-ovrd : disable
port : 53
client-override-status: disable

To fix this you enter:
FG100 # config system fortiguard
FG100 (fortiguard) # set
*hostname hostname or IP of the FortiGuard server
FG100 (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:

– To see real time list of servers to which the firewall tries to connect for Fortiguard service
FG200# diagnose debug rating
Locale : english
License : Contract
Expiration : Fri Jun 17 02:00:00 2010
Hostname : guard.fortinet.net

-=- Server List (Wed Jun 19 08:12:58 2009) -=-

IP Weight Round-time TZ Packets Curr Lost Total Lost
212.95.252.121 0 85 0 521863 0 113
212.95.252.120 0 89 0 4625 0 5
82.71.226.65 0 97 0 2140 0 34
62.209.40.73 10 105 1 2060 0 0
62.209.40.72 10 103 1 2060 0 0
66.117.56.37 50 158 -5 2060 0 0
69.20.236.180 50 191 -5 2060 0 0
69.20.236.179 50 185 -5 2060 0 0
66.117.56.42 50 164 -5 2061 0 1
72.52.72.243 80 245 -8 2063 0 3
116.58.208.39 80 371 -8 2081 0 21
208.91.112.194 80 233 -8 2075 0 12
216.156.209.26 80 239 -8 2068 0 7
121.111.236.179 90 354 9 2061 0 1
121.111.236.180 90 366 9 2064 0 4

– The same for Antispam service
FG200# diagnose spamfilter fortishield servers
Locale : english
License : Contract
Expiration :Fri Jun 17 02:00:00 2010
Hostname : guard.fortinet.net

-=- Server List (Wed Jun 19 08:13:39 2009) -=-

IP Weight Round-time TZ Packets Curr Lost Total Lost
212.95.252.121 0 94 0 2063 0 0
212.95.252.120 0 96 0 2061 0 0
82.71.226.65 0 104 0 2076 0 18
62.209.40.73 10 113 1 2061 0 0
62.209.40.72 10 111 1 2061 0 0
66.117.56.37 50 159 -5 2061 0 0
69.20.236.180 50 199 -5 2061 0 0
69.20.236.179 50 193 -5 2061 0 0
66.117.56.42 50 169 -5 2063 0 2
72.52.72.243 80 273 -8 2065 0 4
116.58.208.39 80 380 -8 2085 0 24
208.91.112.194 80 271 -8 2071 0 8
216.156.209.26 80 261 -8 2064 0 2
121.111.236.179 90 362 9 2061 0 0
121.111.236.180 90 370 9 2062 0 1

– To see on the console Webfiltering doing its work:
FG200# diagnose debug application urlfilter 1

FG200 # id=93000 pid=50 main-696 in main.c received pkt:count=197, a=/tmp/.thttp.socket/21
id=22009 received a request /tmp/.thttp.socket, addr_len=21: d=www.cnn.com:80, url=/a7Admin/SelectImage.aspx?end=document.f.largeimage.value&preview=document.getElementById(‘oImg2’)&w=319&h=215, id=913659, vfid=0, type=0, client=192.168.7.238
id=93000 msg=”found it in cache”
id=93003 user=”N/A” src=192.168.7.238 sport=4796 dst=157.166.224.25 dport=80 service=http cat=36 cat_desc=”News and Media” hostname=www.cnn.com url=/a7Admin/SelectImage.aspx?end=document.f.largeimage.value&preview=document.getElementById(‘oImg2’)&w=319&h=215 status=passthrough msg=”URL belongs to an allowed category in the policy”
id=93000 pid=50 main-696 in main.c received pkt:count=255, a=/tmp/.thttp.socket/21
id=22009 received a request /tmp/.thttp.socket, addr_len=21: d=b.mail.google.com:80, url=/mail/channel/bind?VER=6&it=460207&at=xn3j2v04hx65iz3ypmmyzptrbkimsf&RID=rpc&SID=57A1C77D6AAC35B0&CI=1&AID=347&TYPE=html&zx=8i5clc-olem8j&DOMAIN=mail.google.com&t=1, id=900542, vfid=0, type=0, client=192.168.7.56
id=93003 user=”N/A” src=192.168.7.56 sport=4280 dst=74.125.39.189 dport=80 service=http cat=23 cat_desc=”Web-based Email” hostname=b.mail.google.com url=/mail/channel/bind?VER=6&it=460207&at=xn3j2v04hx65iz3ypmmyzptrbkimsf&RID=rpc&SID=57A1C77D6AAC35B0&CI=1&AID=347&TYPE=html&zx=8i5clc-olem8j&DOMAIN=mail.google.com&t=1 status=passthrough msg=”URL belongs to an allowed category in the policy”

You can’t set duplex/speed settings of the Fortigate interfaces?

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]

FG100 (dmz2) # set speed
100full 100M full-duplex
100half 100M half-duplex
10full 10M full-duplex
10half 10M half-duplex
auto auto adjust speed

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)  :

# conf sys int
(interface)# edit internal
(internal)# set speed

100full 100M full-duplex
100half 100M half-duplex
10full 10M full-duplex
10half 10M half-duplex

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) :

FG100 # diagnose hardware deviceinfo nic internal
Description VIA VT6102 Rhine-II
Part_Number N/A
Driver_Name via-rhine
Driver_Version 1.1.17
PCI_Vendor 0x1106
PCI_Device_ID 0x3065
PCI_Subsystem_Vendor 0x3065
PCI_Subsystem_ID 0x1106
PCI_Revision_ID 0x74
PCI_Address 0:12.0
PCI_Bus_Type
Memory 0x0000f400
IRQ 11
System_Device_Name internal
Current_HWaddr 00:09:0f:30:32:11 #In HA set up primary member would have different , virtual MAC address , for more see here http://kc.fortinet.com/default.asp?SID=&Lang=1&id=1772 FortiOS v3.0 HA Cluster virtual MAC addresses
Permanent_HWaddr 00:09:0f:30:32:11
Link up
Speed 100
Duplex forced full
FlowControl off
State up(0x00001103)
MTU_Size 1392
Rx_Packets 89944267
Tx_Packets 73437299
Rx_Bytes 370540924
Tx_Bytes 428118992
Rx_Errors 0
Tx_Errors 0
Rx_Dropped 0
Tx_Dropped 0
Multicast 8810
Collisions 0
Rx_Length_Errors 0
Rx_Over_Errors -0
Rx_CRC_Errors 0
Rx_Frame_Errors 0
Rx_FIFO_Errors 0
Rx_Missed_Errors 0
Tx_Aborted_Errors 0
Tx_Carrier_Errors 0
Tx_FIFO_Errors 0
Tx_Heartbeat_Errors 0
Tx_Window_Errors 0
Tx_Single_Collision_Frames 0
Tx_Multiple_Collision_Frames 0
Rx_Frame_Too_Longs 0
Rx_Symbol_Errors 0
Rx_Control_Unknown_Opcodes 0
Rx_Pause_Frames 0
Tx_Pause_Frames 0
Scatter_Gather OFF
poll_intr_switch 0
rx_tasklet_pkts 92505560
xmit queue 0
recv queue -64
phy_id= 1/1

Older posts Newer posts

© 2016 yurisk.info

Theme by Anders NorenUp ↑