IPS recommendations

[#1]

OK - I am another " surprised" and overwhelmed new user by the IPS section on my FortiGate 60' s. I have scoured the forum archives but I do not see a " best practices" use of the IPS section. Is there such a thing? I am looking for how others are setting up their FortiGate 60' s - I have 28 of them at 28 remote branches - and I would like articles or ANYTHING that will guide me on the IPS setup. why you ask?? Well I am having a huge amount of trouble with my FortiGate 60' s and I see where others have posted that turning off many of the services under IPS may solve some performance issues. BTW - has anyone had to return any of their FortiGate 60' s because they no longer boot?? I am on my 7th out of 28. NCRL 30 Fortigate 60' s 2 300A' s

[rwpatterson]

Could you just use a cross cable?

[aplato]

Could you just use a cross cable?

You can, of course, but I have found that is typically what causes the corruption. Since TFTP is a correctionless protocol, its easy for the communication to collide and packets to get badly out of sequence. While a cross-cable connection is theoretically the quickest, there is differences in the interface network stacks on either side. Windows has a pretty heavy network stack, where as the Fortinet has very lean, Linux-based stack. As such, its not uncommon for these two interfaces to misnegotiate with each other and get packets out of sequence or mess up any number of other things. A switch will, to some extent mitigate that issue. As the devices will negotiate with the switch, and not each other. The switch will also help smooth out the transmission. That' s why I say - put a switch between the two.

[abelio]

You can, of course, but I have found that is typically what causes the corruption.

sorry, but i never experienced such ' corruption' connecting with a cable and in that hyphotesis, i' m sure that is not due to above affirmation

Since TFTP is a correctionless protocol, its easy for the communication to collide and packets to get badly out of sequence.

no, TFTP is connectionless (not ' correctionless' ) protocol; i guess that is not a typo because you' re posting it twice in this thread TFTP is UDP protocol, like DNS does: connectionless, efficient although not reliable by itself. TFTP clients (like a FGT box) use ack messages embedded in UDP datagrams to tell a server (like solarwinds one) that it received the last block of data and that is ready to receive another block. TFTP server then sends another block of data as another UDP message and then wait to receive an ack before sending another block. This is NOT like TCP. In this TFTP (UDP) case, the protocol waits for a clear-to-send signal from the remote system, transmits a datagram, and then stops to wait for the clear-to-send signal again. This IS specific to TFTP. Other UDP application implements similar or none error correction. It' s not reliable as TCP, but it was suitable and useful by years for transmits chunks of fixed size of blocks, like router or appliances images firmwares, trough crossover cables or directly throughout the Net

A switch will, to some extent mitigate that issue. As the devices will negotiate with the switch, and not each other. The switch will also help smooth out the transmission. That' s why I say - put a switch between the two.

Sorry i can' t sustain that argument; maybe is your local net experience, switches doesn' t ensures transmission reliability ' per se' . (if you argue ' hub vs switch' ok, i agree, but not in this thread situation) best regards,