Question about NAT and Firewall policy source interface

[ITadm]

Hello,

 I'm exchanging my WatchGuard router to FortiGate 60E with 1 to 1 setting if possible and I'm not sure how to implement my NAT settings on FortiGate:

Dynamic DNS pool and 1-to-1 NAT:

NAT settings in example policy:

And this is how it looks in my FG GUI:

 My second concern is the Incoming interface in my policies. I have like 6 VPN site-to-site tunnels and do I have to add every tunnel and VLAN as incoming interface or I can just set it to 'any' and restrict access to specific source and service. It worries me because NAT in this specific policy is turned off and 'any' includes WAN interface. Whats the best way to handle it?

Thank you in advance for your answers!

[ede_pfau · Accepted solution]

Hi,

and welcome to the forums.

Lots of questions but that's the usual thing. Would have been better if you hadn't had any previous experience with firewalls :)

So, first: IPpools do source NAT. With private addresses in your LAN you need it when traffic leaves the WAN interface. But, to make that easy, you just enable NAT in the policy from LAN to WAN. Traffic will then use the WAN's public IP address.

You will use IPpools if you want to assign specific (source) addresses to traffic. For example, for traffic entering a VPN tunnel.

Second, "it's not a bug - it's a feature!". Single interface policies allow for the most control. You will appreciate this when debugging. But, if you foresee that a bunch of interfaces will be used in the same manner you can group them. Instead of "interface group" Fortinet called them "zone". You first create interfaces, then put them into a zone you create, and then use the zone as the source or destination interface in a policy.

I'm not a big fan of zones, though. They kind of mask where traffic is coming from. And, you can't do all the neat stuff you can do with interfaces, like add a DHCP server to it (well, obviously).

And there are corner cases. Imagine you need to allow traffic between 2 members of a zone of 15 interfaces. You will have to write a policy from "zone" to "zone", and filter out this traffic by address objects. Obvious?

So you have say 20 interfaces and need policies for them. So what? The policy table is segmented in interface pairs, so no real fuss dealing with that. Once you introduce the "any" interface anywhere you will lose that - all policies in a flat table ("sequential view"). Not nice.

Every vendor has great aspects in his software, and not-so-great ones. It takes some time to get used to it. At least, you can always ask around in the forums, many users are willing to give you hints or help.

[ede_pfau · Accepted solution]

Hi,

and welcome to the forums.

Lots of questions but that's the usual thing. Would have been better if you hadn't had any previous experience with firewalls :)

So, first: IPpools do source NAT. With private addresses in your LAN you need it when traffic leaves the WAN interface. But, to make that easy, you just enable NAT in the policy from LAN to WAN. Traffic will then use the WAN's public IP address.

You will use IPpools if you want to assign specific (source) addresses to traffic. For example, for traffic entering a VPN tunnel.

Second, "it's not a bug - it's a feature!". Single interface policies allow for the most control. You will appreciate this when debugging. But, if you foresee that a bunch of interfaces will be used in the same manner you can group them. Instead of "interface group" Fortinet called them "zone". You first create interfaces, then put them into a zone you create, and then use the zone as the source or destination interface in a policy.

I'm not a big fan of zones, though. They kind of mask where traffic is coming from. And, you can't do all the neat stuff you can do with interfaces, like add a DHCP server to it (well, obviously).

And there are corner cases. Imagine you need to allow traffic between 2 members of a zone of 15 interfaces. You will have to write a policy from "zone" to "zone", and filter out this traffic by address objects. Obvious?

So you have say 20 interfaces and need policies for them. So what? The policy table is segmented in interface pairs, so no real fuss dealing with that. Once you introduce the "any" interface anywhere you will lose that - all policies in a flat table ("sequential view"). Not nice.

Every vendor has great aspects in his software, and not-so-great ones. It takes some time to get used to it. At least, you can always ask around in the forums, many users are willing to give you hints or help.

[ITadm]

Thank you @ede_pfau for your detailed answer!

So, can you please tell me if my conclusions are correct:

1) As long as I have NAT traversal enabled on my Access_to_WAN policies I don't have to worry about creating 'any' policy, because FG will use this policy and will translate my hosts IP to one of my public IP, right? I need to add separately my public IPs which I want to use to "IP Pools" and use them as DynamicIP Pool 1to1 NAT, right?

You're right that it sounds inconvenient to handle these 'any' policies, but here is the reason I wanted to do this:

I have like 200 users with laptops, and every one of them has his unique last octet in IP addressing in every location. They travel, so for instance in one location his IP address is 192.168.1.201 and in the other 192.168.2.201. I've already created address groups for them and DHCP reservations (yeah, lots of work!).

When I create a policy for user 201 to access terminal server I wanted to use 'any' to 'LAN-Servers" and restrict access to his address group. I understand that you suggest to put as "incoming interface" all my VPN tunnels for example grouped as a zone instead of 'any', am I right? :)

2) I will try to just switch off NAT between VLANs and VPN tunnels. When user 201 from location b) wants to reach terminal server from location a) using policy on FG in a) it shouldn't need any NAT traversal, am I right?

Sorry for so many questions :)

One, last and simple question: when I create a specific service on Firewall, I have "Destination Port" option and there is Low - High. I assume that it can be used to provide port range and when I want to use single port I have to fill both of them? I created around 50 policies filling both Low and High, does it make any difference?

Uff, I think thats all for now, thank you :) 

[ede_pfau]

1) As long as I have NAT traversal enabled on my Access_to_WAN policies I don't have to worry about creating 'any' policy, because FG will use this policy and will translate my hosts IP to one of my public IP, right?

Well, it's just NAT. NATT is a term used in VPNs.

Anyway, the FGT will use whichever policy matches the traffic first: a match is defined by source interface, dest. interface, source address, dest. address and service (5 tuple). So, for several source interfaces you need one policy for each.

And because the source address is a private address (RFC1918), you need to enable NAT. The FGT will use the wan's interface IP address every time. The one primary, and only this one! It doesn't know about a range of public addresses you might be able to use.

If you want to use a different public IP for each subnet, you create 1-address-IPpools for each and specify this in the policy.

 I need to add separately my public IPs which I want to use to "IP Pools" and use them as DynamicIP Pool 1to1 NAT, right?

Yes, if you want to mark outbound traffic with different public IPs.

And yes again,  a zone pulls together several interfaces as a group, for administrative purposes. IMHO both the 'any'  interface and zones are a sort of compromise, but YMMV.

2) I will try to just switch off NAT between VLANs and VPN tunnels. When user 201 from location b) wants to reach terminal server from location a) using policy on FG in a) it shouldn't need any NAT traversal, am I right?

Why would you NAT traffic between remote subnets? BECAUSE: your routing is missing, or you have duplicate subnet address ranges. Both of which are shortcomings of the [strike]admin[/strike] setup.

One, last and simple question: when I create a specific service on Firewall, I have "Destination Port" option and there is Low - High. I assume that it can be used to provide port range and when I want to use single port I have to fill both of them? I created around 50 policies filling both Low and High, does it make any difference?

For services, only the destination port is "well known" and usually it's a single value. Depends on the version of FortiOS whether you have to fill out the high port at all. Just try it out (enter, OK, edit).

What exactly has the policy to do with services? Or did you mean "I created around 50 custom services"?

[ITadm]

ede_pfau wrote:
What exactly has the policy to do with services? Or did you mean "I created around 50 custom services"?

I meant 50 policies with different custom services, little less than the policy number, but still a lot :).

ede_pfau wrote:
If you want to use a different public IP for each subnet, you create 1-address-IPpools for each and specify this in the policy.

Type Overload, right? Do I need to add secondary IP address in my WAN interface settings as I did in WatchGuard?

Thank you, for dispelling my doubts about NAT, I wasn't sure why previous administrator configured it this way, one problem less on FG.

I've already almost finished configuration, tomorrow I will give it a go. To give you insight into the situation- I've migrated my WatchGuards from almost every site to FG, this one is the last one, but it's in my DC. Previous ones were pretty easy, because I've just had to properly create tunnels (wasn't that obvious and easy from FG -> WG) and send all traffic (excluding WAN) to DC where everything was filtered by proper policies. 

My tunnels look like this:

site 192.168.1.0/24

DC  0.0.0.0/0.0.0.0 (any)

So when I need to send traffic between tunnels I don't have to add additional tunnels with remote address from DC. However it looks odd to me on policy table, but I assume that when I need to forward traffic between tunnels I have to set incoming interface as tunnel and outgoing as another tunnel. Does it make sense? 

Thank you very much for your explanations, I'm sorry when I sometimes misspell or confuse something, but this will be my second night without sleep :). You really helped me.

[ede_pfau · Accepted solution]

You're always welcome. Just wanted to clarify.

No, you don't have to create secondaries but you won't have ARP replies either. Adding a secondary address to a matching IPpool would do that. OTOH, one doesn't see secondaries in the GUI until deep down in the interface setup...so I try to avoid them.

Hmmm, maybe I don't understand the concept but you really do use the same local private subnet at every location? That will get you into trouble as soon as you need to connect subnet to subnet. Private address space is so vast, why economize? Even with 50 tunnels it would only be 50 changes.

And you're right, a tunnel-to-tunnel policy would enable traffic from one remote site to another.

Some hints:

- avoid 192.168.[0-2].0/24 at all means! those are default addresses used for network equipment and you don't want to have stuff working out of the box on your LAN.

- finally:

Say, you use FOS v5.6.x (not sure about v5.4). Create an address object for the local subnet, and enable it for routing. Then, use it

- in the phase2 quick mode selector

- in the access policy tunnel to DC LAN

- in the static route

This faciliates things a bit, and documents the remote subnets at the same time. If you ever have to change a remote subnet (as seen from the DC), you only change the address object.

[ITadm]

I don't use 192.168.1.x anymore it's just an example because I like to show general rules on it, I can focus better on the matter :). My IP addressing after changing firewalls looks more like this 10.1xx.15.0 :). Thanks for the tips!

Everything with firewall exchange went pretty smooth, static NATs work, tunnels work, had some issues with tunnel to site with PPPoE WAN, but I've figured it out.

 The only problem I have is no traffic in custom S2S VPN tunnel from and to physical interface in 2 locations. There are a few VLANs which work and 1 interface which doesn't.

 Funny thing is that I have one location with 2 physical interfaces configured (because I needed them untagged as there is no switch) and they work fine, traffic goes through. I'm thinking about configuring a separate interface-based tunnel for them, but it's still strange. In the IPsec monitor they are UP.