Skip to main content
leif
leif
New Member
December 9, 2014
Solved

Routing / "public ip"

  • December 9, 2014
  • 9 replies
  • 47019 views

Hi! I'm trying to crack the code behind this Fortigate, and must admit I'm not there yet.

Given the schematic below, how do I get a public IP behind a fortigate in NAT mode without adding a second transparent v-dom.

Thanks!

 

    Best answer by Adrian_Buckley_FTNT

    Well i guess just break it down step by step.

     

    Step 1) Get packets routing from Cisco to FortiGate wan1

    Step 2) Get packets through FortiGate.

     

    So assuming there's no issue on the cisco side i will assume you have packets coming from the Cisco and reaching the FortiGates WAN1 interface.

    That can be double checked with a packet sniff -- diag sniff packet any 'net 192.168.3.0 mask 255.255.255.0' 4

     

    Using your diagram what you need in addition to this on the FortiGate is

    1) A firewall policy WAN1->Port2 (to allow communication from the outside)

    2) A firewall policy Port2->WAN1 (to allow communication from that device to the internet)

    3) A route to the hosts subnet behind port2

    Destination IP/Mask: 192.168.1.0/255.255.255.0 Device: Port2

    Gateway: (none) - Give Port2 a 192.168.1.x/255.255.255.0 IP address that doesn't match the host and the route will be added automatically

    9 replies

    Adrian_Buckley_FTNT
    Staff
    Adrian_Buckley_FTNT
    Staff
    December 9, 2014

    Your diagram has no public IPs behind the FortiGate.  This needs to be done on the router in front of the FortiGate obviously.

     

    Once the packet reaches the FortiGate there are 2 possibilities depending on what you need

    1) You need to change that public IP to a private destination

    Configure a Virtual IP on Wan1,  set it to translate the public IP to a private IP and create a firewall policy using that VIP as a destination.

     

    2) You need the leave the destination IP unchanged

    This requires 2 simple steps.

         i) A firewall policy to allow the packes to grom from WAN1->(whatever interface the public IP is behind)

         ii) a route to that public IPSince the default gateway is going to be out WAN1, then you need to route that IP another way.

     

     

    leif
    leifAuthor
    New Member
    December 9, 2014

    Sorry for not clarifying enough.

     

    In the diagram I used 192.168.1.x/24 as the "public" ip. I know the 192.168.x.x are not public, but the routing / nat / setup should be the same. So I'm pretending the 192.168.1.x is my real address here. And sure enough I don't have a /24 public ip range here at home ;)

     

    I wan't the ip to be left unchanged so, option two

     

    I've setup a firewall rule without NAT from WAN1 to Port10(policy number one)

    From wan1

    To port10

    Soure All

    Destination all

    Schedule always

    service all

    action accept

    nat disable

     

    What I'm struggling with is the route.

    Destination IP/Mask: 192.168.1.3/255.255.255.0 (I guess thats wrong)

    Device: Wan1

    Gateway: 192.168.1.1

    Edit: I've changed a little the diagram to try to get it as close the the real world as possible. I could have solved this with adding a vdom in transparent, but wan't to solve this with shouldn't have been easy. Well, it doesn't work, and it bugs me.

     

    Edit2: Superthanks for your answers and taking your time to solve my mess.

    Adrian_Buckley_FTNT
    Staff
    Adrian_Buckley_FTNTAnswer
    Staff
    December 10, 2014

    Well i guess just break it down step by step.

     

    Step 1) Get packets routing from Cisco to FortiGate wan1

    Step 2) Get packets through FortiGate.

     

    So assuming there's no issue on the cisco side i will assume you have packets coming from the Cisco and reaching the FortiGates WAN1 interface.

    That can be double checked with a packet sniff -- diag sniff packet any 'net 192.168.3.0 mask 255.255.255.0' 4

     

    Using your diagram what you need in addition to this on the FortiGate is

    1) A firewall policy WAN1->Port2 (to allow communication from the outside)

    2) A firewall policy Port2->WAN1 (to allow communication from that device to the internet)

    3) A route to the hosts subnet behind port2

    Destination IP/Mask: 192.168.1.0/255.255.255.0 Device: Port2

    Gateway: (none) - Give Port2 a 192.168.1.x/255.255.255.0 IP address that doesn't match the host and the route will be added automatically

    leif
    leifAuthor
    New Member
    December 10, 2014

    So lets see.

     

    I don't have a 192.168.3.x network. The wan side has the 192.168.1.x network. And I'm trying to get the same 1.x network to one (or many) hosts behind the firewall with the only vdom in use in NAT-mode.

     

    When I try to set the ip addess for the port 2 to ex 192.168.1.199/24, I get the error-message "IP address is in same subnet as the others". The interface is of type physical and is not tagged to any vlans. Tried to add the interface to a new vlan as well, but I got the same error. 

     

    When I try to add a static route with 192.168.1.0/255.255.255.0 and leave the gateway empty I get the error message "Blank or incorrect address entry". 

     

    I guess I have to read (even more). Tried to find a video that covers routing on the fortinet, but didn't find any, just many videos of other topics, that I'm looking forward to watch, once I solve this one.

    Adrian_Buckley_FTNT
    Staff
    Adrian_Buckley_FTNT
    Staff
    December 10, 2014

    Normally you can't have multiple route to the same IP that are the same distance out different interfaces. The FortiGate won't let you.

    In order to do this you need to enable overlapping subnets. 

    As long the same IP does not exist behind both interfaces at the same time you won't have a problem.  If you do, then your going to have an issue since the MAC address table will show whichever host last sent a packet.

     

    config system setting

       set allow-subnet-overap enable

    end

     

    You only need to have a gateway IP in your route if the IP address/range you're trying to connect to is outside the range of the interface itself.

    You diagram doesn't include Port IP addresses of the FortiGate, but i would assume that Wan1 has an IP in the 192.168.1.0/24 subnet.  Not sure what IP port 2 has right now, but it's not ia 192.168.1 IP obviously.

     

    Once you enable the subnet overlapping you could assign a 192.168.1.0/24 IP to port2 or setup port2 with a secondary ip in the 192.168.1.0/24 range.  Once you associate a 192.168.1.0/24 IP to port2 (through either method) you probably won't need to add a route. (not 100% certain about that ... say 80%)

     

    Pretty sure that you can do a secondary IP from the GUI in any firmware version.

     

     

    Dave_Hall
    Dave_Hall
    New Member
    December 11, 2014

    Still find Leif's description/diagram of the request to be confusing.  lol.

     

    If both WAN1 and port2 (shown in diagram) are suppose to be on the same subnet, I would consider just adding a secondary IP to WAN1 and route through that to the server on port2.  Alternately, create either a hard or soft switch combining WAN1 and port2... but I don't like this method because of the CPU load on the Fortiate (if it is a soft switch).

     

    Closest real life situation I have encountered to Leif's request was installing VC units (that needed pubic IP addresses) in sites we have deployed Fortiates at -- in those cases we just install a small network switch between the Fortigate and WAN device -- we then connected the VC unit to another port on the same switch.

     

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    December 11, 2014

    I wonder why nobody mentioned that routing only occurs between different networks, per definition. And the FGT is in Routing/NAT mode.

     

    There have already 2 solutions been proposed:

    - use a small switch in front of the FGT,  feeding the FGT WAN port and the device needing the public IP address

    - create a transparent VDOM

     

    If you want the traffic to be protected you will have to use the VDOM approach. This isn't really difficult and done in 10 minutes. At least less time than this thread is already going on...just my 2 ct.

    Jan_Scholten
    Jan_Scholten
    New Member
    December 11, 2014

    I do not really get the issue.. creating overlapping subnets sounds like a pain in the eh... 

     

    Most of the time i am asked for a similar solution, you can either convince the people that a natted address is fine, as they need a device being reachable by the offical IP, but do need to have the offical IP configured at the device.

     

    Therefore instead of 192.168.1.3 you give a 172.16.1.1 and map this IP to the offical/public IP.

     

    If they insist on a public ip configured at device level you simply can't have the (nat) firewall in between -> a internet Switch (or a VLAN on a existing switch) depending on your needs/security policys (e.g. Internet traffic may not reside on the same switch even if vlan sepearted) should do.

     

     

     

     

    leif
    leifAuthor
    New Member
    December 11, 2014

    Really thanks for all your answers! 

     

    So why do I want't this? Well, it's a learning by doing, one has to fail (or learn by others faults) to get the knowledge of why and how. And I do agree that subnet overlapping doesn't sound like a good idea. I just thought that the fortigate could route without NAT and it wouldn't be this messy.

     

    In the end it sounds like I should use the vdom (or vodka as my autocorrection says) and use a tagged vlan to the wan as suggested above (the solution that we uses today).

     

    It feels that all of you got a solid amount of experience witch I seems to lack. Well, I'll get there hopefully one day. Just have to study more...

     

    Oh, and no, I didn't get it to work even when I activated the subnet overlapping. I write that to my fault, and I guess it would have worked if I just could figure out how. Though I'm now scratching this design, and will start all over again :)

    Jan_Scholten
    Jan_Scholten
    New Member
    December 12, 2014

    I guess some have longer experiences but i doubt that anyone knows the perfect solution for everything.

    Often i encounter setups where someone "has heard something" and not propagates this without any knowledge: 

     

    e.g. a Citrix Admin has problems with his servers and he found a KB Article about spanning tree problems with citrix servers. The server Admins soultion: have STP disable for the citrix network, not realising that this is a "very brave" decision.. 

    In the KB Article it was about port-fast as stp may take to long for DHCP request to go into forwarding. 

     

    Result: loops in the ctrix networks as stp was disabled. Enabling STP and everything was fine (Portfast by default, the citirx problem was never related to any stp.. but hey thats the way it rolls pointing to others if any errors occur).

     

    therefore: Ask yourself/your customer whether he really wants such a strange solution. And keep in Mind: while fortinet does not do routing of same IP Networks through another interface Cisco ASA do not do this as well - as this is just a [strike]stupid[/strike] unusual Idea.

     

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    December 12, 2014

    Yeah, I agree, not your fault OP.

     

    Just to clarify: there simply is no routing between the same networks. Full stop.This is just the way the IP protocol is designed.

     

    And no, the FGT can route quite well without NAT. Just an example: it does so all the time when traffic crosses between local ports. That's what the automatic static routes ('connected') are for. There is no NAT involved in this.

    Terms & ConditionsAccessibility statement