Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
varriola
New Contributor

Fortigate 500D - NAT Entire Subnets

Hello,

   I'm having some trouble with NAT'ing entire subnets and am looking for suggestions and/or confirmation that I am doing it correctly.

 

I'm trying to give each school a separate external IP address based on their subnets. I am doing the following to create the NAT rule.

1)Create Address Object for the school site's subnet

     -School 1 - 10.1.0.0/16

     -School 2 - 10.2.0.0/16

     -School 3 - 10.3.0.0/16

2)Create IP Pool Object for each external IP address (All 3 IP addresses are part of a Single WAN interface network)

     -Set "TYPE" to overload (Per Fortinet Chat Support)

3)Create IPV4 Policy

     -School 1 NAT Policy:

       -Incoming Interface - LAN

       -Outgoing Interface - WAN

       -Source: School 1 - 10.1.0.0/16

       -Destination: ALL

       -Schedule: Always

       -Service: ALL

       -Action: Accept

          -Firewall/Network Options

             -NAT: On

             -IP Pool Configuration: Use Dynamic IP Pool

             -<Overload IP POOL Object I created>

 

When I apply this rule I lose all access to the internet.

At one school site, it works for the wired connections, but not for the wireless connections. As soon as I toggle the rule off, internet connectivity returns for all subnets.

 

If I do a tracert from a machine that can no longer get out to the internet I successfully hit my Fortigate 500D and then drop all other attempts to reach the outside.

 

Can anyone confirm this is the correct process for what I am trying to do? Any suggestions where I should be looking to trouble shoot this?

 

2 Solutions
jamesmeuli
New Contributor II

That all looks correct. Can you use those addresses? 

 

#exec ping-options source x.x.x.x

#exec ping <yourgatewayorgoogle>

 

If there are no vips on those addresses the Fortigate is probably not responding to ARP so you should add secondary IPs to your WAN interface

View solution in original post

ede_pfau

I think (and please take this as a hint for further research only) that one could/should use a VIP in this case.

Even if you think "VIPs are for destination NAT, I need source NAT". VIPs have 2 properties:

- they respond to arp (proxy arp)

- they automatically apply source NAT for the reverse traffic (!)

 

I faintly remember there was a KB article applying this, with "1:1 NAT" in the title. Time permitting I will re-edit my post to include a link to it. It was surprisingly easy to apply and worked right away.

I personally dislike secondary addresses as they are quite 'invisible' in the GUI yet they interact fully. Maybe the VIP will do the trick.

 

edit:

ah, found it: https://kb.fortinet.com/k...ypeID=DT_KCARTICLE_1_1


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
9 REPLIES 9
jamesmeuli
New Contributor II

That all looks correct. Can you use those addresses? 

 

#exec ping-options source x.x.x.x

#exec ping <yourgatewayorgoogle>

 

If there are no vips on those addresses the Fortigate is probably not responding to ARP so you should add secondary IPs to your WAN interface

varriola

Adding the external IPs as secondary IP addresses on the WAN interface seems to have done the trick. Thank you!

 

I assumed that because I had entered the interface network as a /28, it would automatically include the full range.

ede_pfau

I think (and please take this as a hint for further research only) that one could/should use a VIP in this case.

Even if you think "VIPs are for destination NAT, I need source NAT". VIPs have 2 properties:

- they respond to arp (proxy arp)

- they automatically apply source NAT for the reverse traffic (!)

 

I faintly remember there was a KB article applying this, with "1:1 NAT" in the title. Time permitting I will re-edit my post to include a link to it. It was surprisingly easy to apply and worked right away.

I personally dislike secondary addresses as they are quite 'invisible' in the GUI yet they interact fully. Maybe the VIP will do the trick.

 

edit:

ah, found it: https://kb.fortinet.com/k...ypeID=DT_KCARTICLE_1_1


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Adam18290

Going off the article in https://kb.fortinet.com/k...ypeID=DT_KCARTICLE_1_1, do you happen to know if the translation occurs in the opposite direction i.e. if network 'External' initiates traffic to 192.168.37.5, will that be mapped to 10.10.10.43 or does this only work when initiated from the inside?

 

Best,

Adam

ede_pfau

Yes, of course. That is the normal way to employ a VIP. The trick here is that VIPs will not only DNAT inbound, but SNAT outbound, so to conceal the internal address completely. This is used in the KB article to SNAT 1:1. But DNAT will occur as well.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Adam18290

So it’s essentially one to one NAT on a mass scale and the mappings are Consistent i.e .1 translates to .1 Similar to the way Cisco implement NAT when you specify the source and destination network and mask in the NAT statement
ede_pfau

Correct. IMHO this should / could be implemented in SNAT (IPpools) as well. Seems nobody has asked yet...


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
smari
New Contributor

I've done similar scenarios without adding secondary ip on the interface.

Did you check if your IPpool has "arp-reply" enabled ?

NSE7, FMG, FAC, FAZ .

1500D's, 1200D's, 900D's, 300D's, 200D's, 100D's and bunch of small stuff.

 

NSE7, FMG, FAC, FAZ . 1500D's, 1200D's, 900D's, 300D's, 200D's, 100D's and bunch of small stuff.
varriola
New Contributor

Interesting. I will look into it. 

I went with the method that I did because that's what Fortinet support suggested.

Labels
Top Kudoed Authors