aggressive mode vs main mode

[dirkdigs]

how secure is aggressive mode. i know its faster then main mode with less exchanges but what does it send in clear text. is this a security issue?.

[ede_pfau]

Well, I think that if you start an IKE negotiation against a FGT and you would NOT see any response that the FGT would be bricked then. ' ike-scan' just does what any IPsec client would do. And I bet you could do some fingerprinting from the kind of response to various connection attempts. Hopefully, Fortinet R&D has probed this before it gets drawn into public here.

[netmin]

@ede : well, not necessarily bricked. The tool appears to use DH 2 by default and the FGT indeed sees this request but doesn' t respond with any single packet when using different DH groups. Certainly the tool might provide addl. options, but not by default (or without reading the documents )

[fcb]

I get that this an old post (google search landed me here - where I found my answer I might add) but considering that most of the people that posted to this thread are still active on the forums, a sort of follow-up question if i may. You guys mention that Aggressive mode is to be used mostly for dynamic and dial-up connections. This is the default still to this day on the Fortigate wizard but in an environment with oversight we were forced to move ALL VPN's to Main Mode, ALL VPN's. Did we hurt our self in doing so? I get the extra time during negotiation, but in what other way would it be negative? If memory serves the Main Mode makes you move the gate into more of an interface based VPN but I don't recall specifics behind that. I know when using this type of VPN the client is assigned an IP in the defined range and then the clients gateway is always one number higher than the IP that they were assigned. ie:

Ethernet adapter Ethernet 2:    Connection-specific DNS Suffix  . :    Description . . . . . . . . . . . : Fortinet Virtual Ethernet Adapter (NDIS 6.30)    Physical Address. . . . . . . . . : 00-09-0F-FE-00-01    DHCP Enabled. . . . . . . . . . . : Yes    Autoconfiguration Enabled . . . . : Yes    IPv4 Address. . . . . . . . . . . : 10.100.31.153(Preferred)    Subnet Mask . . . . . . . . . . . : 255.255.255.255    Lease Obtained. . . . . . . . . . : Wednesday, April 20, 1999 4:20:00 PM    Lease Expires . . . . . . . . . . : Saturday, December 31, 1999 23:59:59 PM    Default Gateway . . . . . . . . . : 10.100.31.154    DHCP Server . . . . . . . . . . . : 14.20.24.7    DNS Servers . . . . . . . . . . . : 14.20.3.65                                               14.20.7.24    NetBIOS over Tcpip. . . . . . . . : Enabled for some reason Thanks - mainly just curious so thank you if anyone still has ears on

[emnoc]

we were forced to move ALL VPN

what do you mean "forced" ?

If memory serves the Main Mode makes you move the gate into more of an interface based VPN but I don't recall specifics behind that

And no, aggressive or main mode for IKE has no bearing on vpn-interface ( aka routed-based ) or policy-ipsec ( aka policy-based ) VPNs.

FWIW, If you had a vulnerability scan and they flagged aggressive-mode ( most does btw ) than see if you can build the tunnels out with IKEv2. 

Ken Felix

[fcb]

Well, maybe "forced" is too harsh of a word but the auditors that came in and their script told them that we should be using Main Mode so as to not allow anyone to see the authentication proposal during IKE. I was pleased since that was the only thing that they really busted us up on this last time since we had managed to get rid of every reference to ALL addresses or ANY protocol or ANY interface on every single rule.... There is not one rule in our topology with  ANY,ANY or ALL. That one I agree with them on in most cases.

Regarding the mode of the tunnel, when I changed them to custom tunnels and to Main mode the way our dial-up clients received their IP and GW changed to the previously mentioned setup where the IP is say .100 while the GW is one IP higher, 101. I know the tunnels before that change were setup to where they got an IP and the GW was the interface on the Gate. For whatever reason the whole policy based vs route based has confused me but I get that you're saying that IKE has nothing to do with that

[AndreaSoliva]

Hi one more hint from my site: If you use several FortiClient connections on example WAN interface YOU HAVE TO USE with PSK Aggressive Mode. The reason ist hat if user A for Client2Site A is requesting on WAN IKE the daemon for IKE can not identify the connection to be related to Client2Site A. This means acutally that the PSK will be checked on both Client2Site meaning A and B. The request for B will of course fail. To prevent this -if you are using more as one Client2Site IPSec configuration is using " local-id" in phase1. In this way the User A will deliver local-id for Client2Site A and in this way the IKE deamon can full identify the connection. The disandvantage of such a configuation is that the local-id will be delivered in clear-text to the IKE Deamon listening on WAN. If you like to prevent this you have to configure main-mode and using RSA authentication with Certificates. If so the IKE deamon can verify the connection over the Certifdate list. From my point of view if you are using Site2Site use always Main-Mode except if the other site is a interoberability device which requests Aggressive Mode. hope this helps have fun Andrea