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

Not getting subnet translation to work

We are trying to replace a Cisco router with a FortiGate running 5.4 but are unable to get subnet translation to work as before. Here's the scope:

[ul]
  • It's an internal router used to route traffic between three different interfaces:[ul]
  • This branch office's VLAN 192.168.100.0/24 with FortiGate's IP 192.168.100.254.
  • Server VLAN 172.24.0.0/24 (connected through an IPSEC tunnel on a different FortiGate and reached with static route 172.24.0.0 255.255.255.0 192.168.100.1).
  • MPLS network to HQ 10.100.0.0/24 with FortiGate's IP 10.100.0.254. Static route 10.3.0.0 255.255.255.0 10.100.0.1.[/ul][/ul]

    The subnet translation comes into play when HQ doesn't want to use 192.168.100.0/24 and 172.24.0.0/24 in their end to avoid risk of overlapping subnets so they have assigned subnets for each:

    [ul]
  • 192.168.100.0/24 = 10.100.1.0/24
  • 172.24.0.0/24 = 10.100.2.0/24[/ul]

    In the Cisco router this was simply managed at our end with these two lines:

     

    ip nat inside source static network 192.168.100.0 10.100.1.0 /24 ip nat inside source static network 172.24.0.0 10.100.2.0 /24

     

    We've tried lots of different ways of doing it in the FortiGate (NAT on policy, virtual IPs etc) but not getting the same result.

     

     

  • 1 Solution
    ede_pfau
    SuperUser
    SuperUser

    hi,

     

    shouldn't be too difficult in FOS either.

    You've got both methods:

    - source NAT is done via IPpools

    - destination NAT is done via VIPs (plus arp proxy plus translation of reply traffic)

     

    So, in the outgoing policy 'internal'->'HQ', use an IPpool with netmask /24.

    In the incoming policy 'HQ'->'internal', use a VIP for the whole subnet.

    For 2 translations/subnets you need 2 policies in each direction.

     

    I hope this is more clear now. Shows us what you've tried/configured and what your results are if it doesn't work as expected.

    Ede Kernel panic: Aiee, killing interrupt handler!

    View solution in original post

    Ede Kernel panic: Aiee, killing interrupt handler!
    4 REPLIES 4
    ede_pfau
    SuperUser
    SuperUser

    hi,

     

    shouldn't be too difficult in FOS either.

    You've got both methods:

    - source NAT is done via IPpools

    - destination NAT is done via VIPs (plus arp proxy plus translation of reply traffic)

     

    So, in the outgoing policy 'internal'->'HQ', use an IPpool with netmask /24.

    In the incoming policy 'HQ'->'internal', use a VIP for the whole subnet.

    For 2 translations/subnets you need 2 policies in each direction.

     

    I hope this is more clear now. Shows us what you've tried/configured and what your results are if it doesn't work as expected.

    Ede Kernel panic: Aiee, killing interrupt handler!
    Ede Kernel panic: Aiee, killing interrupt handler!
    MikePruett
    Valued Contributor

    Ede is right (at least from what I'm reading on your issue). Do what he says and it should work out for you. If you have issues give us a shout.

    Mike Pruett Fortinet GURU | Fortinet Training Videos
    Grosch

    Thanks, it worked! I was pretty close since I tried and IP pool and I tried VIP. I just didn't try them both at the same time.

    ede_pfau

    Good to know you've got it working!

    there's a lot of features in FOS, some of them malfunctioning at times, but NAT (and routing) never has let me down over the past 12 years...

    Ede Kernel panic: Aiee, killing interrupt handler!
    Ede Kernel panic: Aiee, killing interrupt handler!
    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors