Hi everyone,
on our FortiGate firewall we have a remote site (AWS cloud) reachable via Direct Connect and IPsec VPN.
All traffic related to private networks flows through the Direct Connect connection. Only Internet traffic flows through the IPsec VPN.
A resource on the remote site needs to be exposed to the Internet for FTPS traffic. I have configured routing, policy routing, and used a VIP. However, if I don’t enable NAT in the firewall policy that allows incoming traffic, the sessions time out. When I enable NAT, FortiGate performs source NAT using a private IP address, and I have no idea where it’s coming from.
My doubt is that the remote resource will see the traffic incoming from a private IP address instead of the public IP and the flow will not work.
Am I missing something in the configuration?
Thanks for the support.
Not exactly clear the direction of traffic you're having the problem and the SNAT. But I would assume you had to set SNAT on the same policy you have the VIP from the internet side toward the AWS resource. Then the problem must be the default route on the resource side. If the default route at the resource/AWS is NOT pointing into the tunnel, the return traffic wouldn't come back to your FGT over the tunnel without the SNAT.
Toshi
Hi @Toshi_Esumi, thanks for the reply. The direction of the traffic is from the Internet to the VIP and then to the AWS resource.
I've the SNAT on the same policy where I have the VIP.
The default route on the resource side (AWS) is pointing to the IPsec tunnel.
Hi @l16 ,
It's really not clear about what your issue is.
It's better to provide us with a network diagram with some descriptions in it for the issue.
For example:
1) "A resource on the remote site needs to be exposed to the Internet for FTPS traffic."
Do you mean that the resource is an FTPS server and it is on the remote peer side?
2) " I have configured routing, policy routing, and used a VIP."
Where did you configure those settings? On the local side or the remote side?
Atually, I should ask you first, is the remote side also a FGT? And do you have access to it?
3) "However, if I don’t enable NAT in the firewall policy that allows incoming traffic, the sessions time out."
Again, not sure where the firewall policy is, local or remote side?
4) You should share your configurations and any debugs.
Hi @dingjerry_FTNT, thanks for your reply.
1) yes
2) only local side. On the remote side I don't have any firewall, only AWS routing tables and IPsec tunnel.
3) yes, local side.
Actually the setup is working but the FTPS server receives the incoming traffic from the private IP address of the FGT instead of the real public IP address on the Internet.
Hi @l16 ,
With the above info and combining other info you provided in the replies to others, it's more clear about your issue.
1) When you enabled SNAT in the firewall policy using VIP.
It will use the destination interface IP. I believe that the destination interface IP should be the IPSec VPN interface.
2) Session timed out while SNAT is enabled.
Again, you did not provide your configuration, so I do not know what your IPSec VPN selectors are in phase2 settings.
I hope that you are using "0.0.0.0/0.0.0.0" for both local and remote selectors.
And the remote peer should know how to return the traffic to the IPSec VPN tunnel either with the public IPs or the NATted IP.
You may run the following CLI command to confirm whether the packets leaving local FGT while SNAT is enabled:
diag sniffer packet any 'host x.x.x.x' 4 // x.x.x.x is the mapped IP of the VIP which is for the FTPS server
The expected issue is routing in reply direction. TYPICALLY, if src IP is unchanged, the server-side FGT will want to route the reply back via its WAN (the client's IP is some random public IP after all), leading to either RPF check fail = dropped traffic, or to asymmetrically routed TCP session = broken again. Masking the real src IP by SNAT done by the FGT with the VIP policy should avoid this issue.
Hi @kamagth2 , thanks for your reply.
I don't have a server-side FGT.
User | Count |
---|---|
2538 | |
1351 | |
795 | |
642 | |
455 |
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 2025 Fortinet, Inc. All Rights Reserved.