Hello, I am working on a VPN setup to a credit card company for authorizations etc...
They cannot accept any private IPs from us and request that I send 1 public IP over the tunnel and NAT all required underlying servers to that IP.
Per documentation I can find I need to create an IP POOL.
This is for the cloud as well so what I was thinking was I need to add an additional public IP to the WAN VNIC of the FGT (like I would a public facing website). Let's call it 1.1.1.1.
I have 4 servers that need to talk over this tunnel. Would the IP POOL setup be the below?
External IP range 1.1.1.1 - 1.1.1.1
Internal IP range 10.100.202.66-10.100.202.69.
Would the Policy then be
FROM:
LAN and Carrier Interface created via the tunnel (not the WAN)
TO:
LAN and Carrier Interface created via the tunnel (not the WAN)
Source:
Would be the public IPs allowed over the tunnel from the Carrier and my new public IP 1.1.1.1.
NAT:
IP Pool I created.
Thanks in advance.
Is the CC processor's requirement for the "public IP" just to be a unique IP so that there is no potential IP conflict in their network in RFC 1918? That's unusual they don't assign /30 or /31 public subnets from public IPs they own. Then I'd assume they didn't provide a tunnel interface IP on their end but only the public peer IP on their interface, means policy-base.
Regardless, you just need to assign the 1.1.1.1/32 on the tunnel interface (same name with the Phase1-interface name) then not to specify "remote-ip" if their end is not interface-mode as assumption above. Then just (S)NAT at the policy from the interface where the 4 servers are connected to the tunnel interface, specifying the source addresses (4 servers) and their server IP(s). which would be the final destination(s) of the traffic. You need proper routes for the final destination(s) into the tunnel.
Thanks for reply.
They provided a peer IP to peer with over the tunnel and then the phase 2 selectors are public /24 blocks they own.
I need to have those servers NAT'd to the public IP I have as my selectors allowed over tunnel to CC.
The tunnel peer IPs, in some routers/FWs, need to be in a subnet like 1.1.1.2/30 on one end and 1.1.1.1/30 on the other (FGT doesn't care though). So CC service providers generally assign what they have.
If the peer IP you got is a public IP separated from their interface IP to establish the tunnel, you need to set that IP on the tunnel interface as "set remote-ip 1.1.1.2 255.255.255.255" in case 1.1.1.2. Then you need to have a static route for the destination /24 toward the tunnel interface with the GW 1.1.1.2, so that the traffic routes into the tunnel, in addition to my previous post including the policy.
This (S)NAT is nothing different from the one for your internet traffic. By default an SNAT takes the interface IP automatically, which is in your case the tunnel interface IP 1.1.1.1.
Okay thanks I will try that out.
Okay just want to confirm with you making sure I am same page.
I was given a public IP to Peer with from the CC processor side -- 1.1.1.1
They are passing a public IP /24 range over the tunnel 2.2.2.0/24
I have my Peer IP 3.3.3.3
and I have my public IP 4.4.4.4/32 passing over the tunnel towards the CC processor.
SNAT meaning IP Pool?
So I would have my 4 servers 10.100.202.66-69 pointing to 4.4.4.4/32 in the IP Pool correct then I would add that IP pool to the policy
FROM: LAN and Carrier Interface created via the tunnel (not the WAN) TO: LAN and Carrier Interface created via the tunnel (not the WAN) Source: Would be the public IPs allowed over the tunnel from the Carrier and my new public IP 4.4.4.4. NAT: IP Pool I created.
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 |
---|---|
1759 | |
1116 | |
766 | |
447 | |
242 |
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.