IPsec VPN associated interface object ip and remote-ip with multiple phase2?

[tanr]

Have two ipsec phase1-interface VPNs between two locations (FortiGate to FortiGate, 5.6.x), each with multiple phase2s.  All works fine, and branch fortigate logs to our central FortiAnalyzer over the VPN.

Setting up Security Fabric following https://cookbook.fortinet.com/security-fabric-over-ipsec-vpn-56/ it specifies changing the interface object (config system interface) for the phase1 vpn (NOT the vpn ipsec phase1/phase2s) to set its ip and remote-ip to match the local and remote ips of the two fortigates to use for FortiTelemetry between them (upstream FortiGate in Fabric).  These were initially both 0.0.0.0, with the ipsec phase1-interface specifying local-gw and remote-gw, and the multiple phase2-interfaces specifying local and remote subnets.

My uneducated questions:

- Will I break my multiple phase2s by specifying a specific ip and remote-ip in the phase1 interface object?

- If the interface ip and remote-ip specified are /32 will this break the associated phase2 that is for a larger subnet?

- Better way to do this?

Thanks.

[tanr]

I got the downstream FortiGate talking to the upstream FortiGate over IPsec VPN (already had it logging correctly over the VPN) but found that there are some unneeded / confusing sections of the cookbook article (https://cookbook.fortinet.com/security-fabric-over-ipsec-vpn-56/), at least for 5.6.5.

[ul]

The tunnel interface ip can't be set to an ip within an existing subnet for any single interface, so it can't part of any existing phase2, or any existing single interface.  Enabling FortiTelemetry on the interface if IPs are 0.0.0.0 doesn't work.  I ended up using new IPs in a new subnet I'll reserve for fabric communication.

Since all you need between the two FortiGates is FortiTelemetry, you don't need to create security policies for this, nor do you need to enable Multiple Interface Policies.  I did create the matching phase2's and static routes.

The security policy to allow logging from the branch FortiGate to the central FAZ doesn't need to have NAT enabled. [EDIT] Note that I did set the source-ip in config logging fortianalyzer setting though.[/ul]

Anybody know the best method for reporting corrections to cookbook articles?  Facebook comment on their page?  Open a support ticket?

Side Rant: I wish documentation and cookbook articles wouldn't always create their security policy examples allowing ALL services.  It would be much more useful if they could just list the specific services needed for their example.

[ede_pfau]

Anybody know the best method for reporting corrections to cookbook articles?

Either mail to the author, comment the article (if allowed) or send mail to the Documentation staff led by Bill Dickie (bdickie@fortinet.com). I've always got a response from him within a short time.

[tanr]

Thanks Ede, I'll pass on the comments to their documentation folk.

[emnoc · Accepted solution]

FWIW the  document teams has a emall post for the  group that manages the documents. It's listed in ALL documents.  techdocs@fortinet.com  . They are pretty much quick to response depending on  how busy the group is or is not.

So if you don't use the  online help , but download a pdf you can find the team mail-aliases. Emailing a direct  user might not net an as quick response. The 1st 2-3 pages has all of the email  or links for techdocs in all pdf files.

Ken 

[ede_pfau]

+1