Good afternoon and please forgive me for dumb questions. In my defense, this is my first venture into Fortigate so this might be a simple issue to fix.
I have a tunnel coming in that is being nat'd. I have created vips for my 10.10.x.x nodes that the remote end needs to connect to. I can ping those nodes from the fortigate to the nodes nat and internal ip. I am using their nat ips as the encryption domains since these are the only 3 nodes they need to get to from the remote. Phase 1 is up and phase 2 is up. I've allowed the traffic on the gcloud firewall and the fortigate. Everything seems to be routed right. Am I missing something? For example, my Peer ip 34.115.117.95 (Not really, but an example. My encryption IDs are from the VIPs I created on the fortigate of 34.120.117.4, .6, and .8. I've mapped these to the 10.10.x.x address of each node. Am I missing something? I've looked at documentation and it appears that it's correct. Any and all help is appreciated.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Could you please share the exact issue? Are you not able to reach the remote subnet?
You can also collect the sniffer log
diagnose sniffer packet any 'host local_IP and host remote_ip' 4 0 l
Thanks for responding. I spun up a fortigate appliance in GCloud. I have multiple tunnels coming in and only need to touch two load balancers. Those IPs are 10.10.20.5 and 10.10.20.6. I've assigned them virtual nat ips from the appliance or 34.10.20.5 and 34.10.20.6. I can ping these external ips from the appliance and can ping the appliance from the servers with the nat ips.
I've made these IPs along with one another my encryption domains, and the remote host cannot hit them. Everything appears to be setup properly. phase 1 and phase 2 are up.
Hey raydietz,
so, I have very little experience with Google Cloud, but if I understand correctly:
- you've set up two VIPs on FortiGate (virtual nat IP), with external IP 34.10.20.5/.6, and translating those to internal IPs 10.10.20.5 and 10.10.20.6
- the load-balancers (10.10.20.5 and 10.10.20.6) can ping the public IPs hosted on FortiGate
- a remote host can ping 34.10.20.5/.6, but this does not translate to the internal IPs
If my understanding is correct, then you probably need to add a firewall policy on FortiGate, with roughly these settings:
source interface: IPSec tunnel interface? wherever traffic comes in to reach the loadbalancers
destination interface: egress to the load-balancers
source address: any
destination address: the two VIP objects
-> you need to put the VIPs into a firewall policy for FortiGate to accept and translate the traffic properly
Cheers,
Deborah
Thanks for relying Deborah,
You are correct. I did add the rule with no success. I can ping the endpoints. I can't seem to get the traffic to flow over the tunnel in either direction. Phase 1 is up Phase 2 isn't but settings match on both sides. Do I have my encryption domain setup wrong? it is a /32 address, so I am wondering how that routes to two nat addresses.
Hello raydietz,
Could you please share the outputs from the ike debug. This should show us if there is a mismatch for the encryption/hashing algorithms used.
diagnose vpn ike log-filter dst-addr4 [remote-peer]
diagnose debug application ike -1
diagnose debug enable
I've confirmed no mismatches. I think it is routing or something related. I guess my question is this.. How do I set up my natted encryption domain of 43.138.15.2/32 (example) to pass traffic through to my 10.x networks within the vpcs? I have 4 subnets I need that address to pass traffic through to the nodes without subnet overlap.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.