NAT over Site-to-site

VPN
1

I pick up a Fortigate to start playing with it and and get away from the Cisco im currently using. I am able to create some site to site vpn connections to my cisco box. However I am unable to figure out on how to create a vpn connection with a source NAT address on the fortigate end.

Example:

Fortigate: Server (192.168.1.100) [ I want this to be NAT as 172.16.88.100]

I tried setting up a VIP and policy, but couldn’t figure how to tie it all together with the VPN configuration.

Some insight or examples would be much appreciated.

2

Two ways, without central NAT (which I personally dislike, as my background is mostly in Fortigates going back almost 20 years).

One, create a VIP with external interface VPN tunnel, external address 172.16.88.100, internal address 192.168.1.100. Create a policy from VPN to internal, source address whatever, destination target your VIP. Create a policy from internal to VPN, source and destination whatever (so long as it matches your networks), NAT enabled, using outbound interface IP.

This will work because by default, on a Fortigate, when you have inbound NAT for a certain IP, it will automatically create outbound NAT with the same settings. Be careful: if you create that VIP with external interface set to ‘any’, this IP will apply to ALL outbound NAT-enabled traffic, and can potentially break traffic - for example, if your 192.168.1.100 tries to NAT to internet as 172.16.88.100, your next-hop ISP router will not be able to respond to that. To avoid this in scenarios where you want this VIP to respond on multiple interfaces, there is a CLI-only option on the VIP level called ‘set srcintf-filter’ - you can use it to limit the interfaces that the VIP works with to a specified list, i.e. more than one, but not everything.

Another option is to use IP pools - this is outbound-only, i.e. it will allow 192.168.1.100 to access your other site masquerading as 172.16.88.100, but it will not let that other site to reach 192.168.10.100 by initiating sessions to 172.16.88.100. To use it, go to Policy & Objects → IP pools, create a pool of type ‘overload’ with external IP range 172.16.88.100-172.16.88.100, then create a policy from internal to VPN, NAT enabled, but instead of using outgoing interface address, select ‘Use Dynamic IP Pool’ and select the pool that you’ve created. This will override all other NAT settings - interface address, VIP, whatever - and masquerade all source addresses going through the policy as what is set in the IP pool. You can set the pool to use more than one address; in that case addresses will be assigned sequentially.

Note that VIPs, like IP pools, can also use IP ranges, which is quite useful. For example, you can create a VIP with external address 172.16.88.1-172.16.88.254 and mapped address 192.168.1.1-192.168.1.254. When you use that in a policy, the entire ranges are mapped one-to-one - i.e. if you want to reach 192.168.1.30, you can hit 172.16.88.30, and so on; the reverse is also true - i.e. 192.168.1.55 will NAT as 172.16.88.55 on its outbound sessions.

3

On the FortiGate, do you have Central SNAT enabled or is it still off (it’s off by default)?

4

Very helpful information! Thank you. I will give it another try. 99% of the time I will be setting a NAT for a single host on my end that the client will be accessing (only if the subnet overlaps). On the ASA I would create the VPN tunnel then back track then set the NAT rule to route the NAT address to the real host after I created the VPN.

In this cause, looks like I have to prepare the NAT to the real host, then refer that NAT address on the VPN setup.

I will try this again next week, would like to enjoy the weekend frustration free lol!

Thanks all to have replied!

5

It is off. I did turned it on at one point, which cause that network to lose internet access. I assume I would have to redo the policy to allow internet differently? End up turning it off again lol

6

I’m a bit confused as to what you’re trying to do here. NAT over site-to-site tunnels is usually what you do when you have an IP address conflict between sites. For example, you have HQ with 192.168.0.0/24, branch A with 192.168.1.0/24, branch B with 192.168.2.0/24, and suddenly you acquire subsidiary C, which is already built with 192.168.1.0/24. Since you’re already routing 192.168.1.0 to your branch A, you have to either renumber the subsidiary C network to something else, or hide it behind NAT, so your HQ routes to, for example, 192.168.3.0/24, and the router/firewall at subsidiary C (be that a Fortigate or anything else) translates 192.168.3.0/24 to/from 192.168.1.0/24.

Would you mind describing your network in more detail so that I could suggest the most optimal way of implementing the traffic flow in a Fortigate?

7

It’s usually suggested to turn Central SNAT on from the beginning. It basically makes the way you do NAT more aligned with how other brands of firewalls do NAT (such as Cisco ASAs) where it’s not done in the policy (rule), and is its own definition. And yes, if you don’t have a NAT defined in the Central SNAT to do you general internet traffic NAT, you’ll lose access (since, as I mentioned already, you don’t do NAT on the firewall policy directly anymore). Central SNAT allows you to be far more granular and have far more control with your NAT definitions.

With Central SNAT still disabled, you do your NAT definition on the firewall policy, which you’d set to be a specific IP Pool (which will be defined however you need it to be, but usually a 1:1) instead of the egress interface address. Then you’d just need to make sure that the NAT address is part of your tunnel’s interesting traffic (phase 2) definitions.

8

Well, that is kind of the case. Right now on the Cisco ASA I have maybe 30-40 site-to-site tunnels to/from clients and maybe 5 of them are setup as a NAT on my end due to conflicting/overlapping subnets. I just want to know the best approach of getting this done on the Fortigate as I’m considering of migrating everything over to the fortigate. My network is pretty small, primarily just 8 VM servers and I setup my end as /32 while my client’s end can be a subnet of /24 can may or may not overlap my subnet or they request I NAT so it doesn’t conflict their end and with other client’s/vendors they may have.

9

Great, thanks for the insight, I will try both ways. I might just go with Central SNAT being on, easier to manage NAT that way coming from the ASA if I can get it working lol.

10

Central NAT is not the “Fortinet way”. Most documentation you’ll find will reference VIPs not CNAT.

If you need to do a lot of NATting then it might be worth it but otherwise I’d say stick to VIPs

11

Been working with FortiGates for years and I still despise the way they do NAT out of the box. Central NAT should be the default and I will always turn it on immediately if given the chance.

If you mostly use interface IP for outbound NAT then I guess it makes sense. But if you like to segment up your network to use different public IPs for different VLANs, the “Fortinet way” makes no sense and requires a lot of extra policies.

12

No problem. Feel free to ask more questions if you get stuck again.

13

I’ve tried the Fortinet way, I kinda get the concept but I couldn’t get it to work in a site-to-site scenario. I will give it another go, maybe im missing the concept.

14

You still configure VIPs with Central NAT.

15

You use VIPs for incoming traffic and IP-Pools for outgoing traffic.