Skip to main content
ShawnZA
ShawnZA
New Member
March 24, 2020
Question

IP Pools and Zones

  • March 24, 2020
  • 2 replies
  • 5732 views

Can one use IP Pools for SNAT with the source interfaces as a Zone and the destination as a physical interface? I did read that you can't use zones and IP Pools and was wondering if that is still the case? Or is it only the destination that can't be a zone, that I would understand.

"Internal Trusted" is a Zone containing two interfaces, destination is a vlan interface:

 

The vlan interface has an ip of 196.33.152.186/30 and next hop is 196.33.152.185.

 

dst-osfw-pri-mi-2543

IP Prefix: 196.33.152.184/30

[ul]
  • FW IP: 196.33.152.186
  • PE IP: 196.33.152.185

  • So if I need to SNAT the traffic destined to 196.23.189.171 so that it looks like it's coming from 196.34.224.128/32 they would also need to have that (196.34.224.128/32) in their routing table pointing towards the fortigate right?

     

    [/ul]

      • 2 replies

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      March 24, 2020

      First, FGT's zone is just an "alias" to represent multiple interfaces with one name in policies. Nothing more than that, which is different from Palo Alto's zone, or Juniper SRX's zone, or some other server vased FWs as far as I know.

      Then SNAT with ippool shouldn't be affected if you use interfaces or zones for src/dst interfaces in policies. As a matter of fact we use zone for an outing interface on one of our FGTs while SNAT/ippool is applied to the policies.

      Is it not working?

      Of course if there is returning traffic toward the SNAT IP from the destination side, there needs to be a route on the other end to point the traffic destined to the SNAT IP to the real interface.

      ShawnZA
      ShawnZAAuthor
      New Member
      March 24, 2020

      Thanks for the info. It's not working at the moment but suspect the other company hasn't added the route back to me yet. If I remove the SNAT and just NAT it on the interface IP it works fine, so suspect it's the route that's missing on the other side.

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      March 24, 2020

      If you run "flow debug" against the destination IP, you would see the SNAT is swapping the source IP before forwarding to the interface.

      ShawnZA
      ShawnZAAuthor
      New Member
      March 24, 2020

      Thanks, the flow does show it's changing the the source NAT to the correct IP, did this test over another source interface, can only do the test over the zone later today but suspect the issue is on the other side

       

      Telnet test to 196.23.189.171 on port 7805, so my side looks fine at least.

       

      Terms & ConditionsAccessibility statement