Hi everybody, I've got a FortiWiFi (which I think it's pretty similar to a FortiGate but with a WiFi interface, correct me if I'm wrong) and it's in NAT mode, so I'm wondering if has this something to do with the fact that I have had to enable NAT for some policies, to be able to reach equipments in one VLAN from another different VLAN.
I mean, to clarify, here a table with info about these VLANs
+-----------+-----------+-----------------+--------------------------------+---------------------------+ | VLAN ID | interface | IP/Netmask | DHCP Range | Related address object | +-----------+-----------+-----------------+--------------------------------+---------------------------+ | 10 | internal5 | 10.100.0.1/12 | 10.100.0.2-10.100.255.253 | 10.96.0.0/12 | +-----------+-----------+-----------------+--------------------------------+---------------------------+ | 20 | internal1 | 172.20.1.1/24 | 172.20.1.2-172.20.1.254 | 172.20.1.0/24 | +-----------+-----------+-----------------+--------------------------------+---------------------------+
So I've created a policy with the '172.20.1.0/24' address object as source and '10.96.0.0/12' address object as destination but apparently I have to enable NAT for that policy if I want to reach hosts in the VLAN 10, is this right? Why is this?
Thank you all, and excuse my ignorance with networking topics if so.
PS: Obviously VLAN ID is just a way to tag every VLAN and it's more related with the switches in my network, but that's the setup that I've got.
The term "NAT mode" is used in a context describing the system (or VDOM) operation that is capable handling IPs (layer 3) against "Transparent mode", which doesn't have IPs in the user plane. For any internal IPs, like your VLAN to VLAN policies, generally you don't want to enable NAT(SNAT), which would hide the source IP and replace with the outgoing interface IP.
So what could explain that apparently I'm not able to reach any host in VLAN 10 from VLAN 20 if NAT is not enabled?
jfernandz wrote:On VLAN20, are all the hosts using interface "internal1" using 172.20.1.1 as their default gateway?So what could explain that apparently I'm not able to reach any host in VLAN 10 from VLAN 20 if NAT is not enabled?
If NAT is enabled in the policy, then the host on VLAN20 is responding to a host on the local subnet (172.20.1.1), and that doesn't care about the default gateway, but if NAT is off, then the hosts *do* need to reply via the gateway.
As SJFriedl said - the Fortigate is well aware of both subnet and has all information to route in between even when not masquerading the real source IP (NAT off) - there for you have to have the fortigate-interfaces in the given subnets configured as gateways on the clients.
All hosts in VLAN 20 are using DHCP (at least the hosts from where I'm trying to reach the hosts in VLAN 10), so I think they have the default gateway is 172.20.1.1, yes; only in VLAN 10 there are a few hosts statically configured.
But I'd like to focus (by the moment, at least) on a particular scenario where both hosts have their default gateways set as the IP/Netmask of their corresponding fortigate-interfaces.
I don't get your point of:
SJFriedl wrote:If NAT is enabled in the policy, then the host on VLAN20 is responding to a host on the local subnet (172.20.1.1), and that doesn't care about the default gateway, but if NAT is off, then the hosts *do* need to reply via the gateway.
Could you be more explicit?
What do you mean with:
SJFriedl wrote:the host on VLAN20 is responding to a host on the local subnet (172.20.1.1)
I'm trying to reach hosts in VLAN10 from VLAN20, so the responding hosts are in the VLAN10(?)
also ... what hosts "*do* need to reply via the gateway"? the hosts in VLAN10 or the hosts in VLAN20?
Apparently according what you are saying with both (NAT enabled or disabled for the policy) I should be able to reach hosts in VLAN10 from a host in VLAN20 if both have their interfaces properly configured (I mean with their default gateways in their interfaces set using the IP/Netmask for their corresponding Fortigate-interface), is this right?
jfernandz wrote:All hosts in VLAN 20 are using DHCP (at least the hosts from where I'm trying to reach the hosts in VLAN 10), so I think they have the default gateway is 172.20.1.1, yes; only in VLAN 10 there are a few hosts statically configured.
But I'd like to focus (by the moment, at least) on a particular scenario where both hosts have their default gateways set as the IP/Netmask of their corresponding fortigate-interfaces.
I don't get your point of:
SJFriedl wrote:If NAT is enabled in the policy, then the host on VLAN20 is responding to a host on the local subnet (172.20.1.1), and that doesn't care about the default gateway, but if NAT is off, then the hosts *do* need to reply via the gateway.
Could you be more explicit?
What do you mean with:
SJFriedl wrote:the host on VLAN20 is responding to a host on the local subnet (172.20.1.1)
I'm trying to reach hosts in VLAN10 from VLAN20, so the responding hosts are in the VLAN10(?)
also ... what hosts "*do* need to reply via the gateway"? the hosts in VLAN10 or the hosts in VLAN20?
Just because you enabled DHCP doesn't mean they get the correct Gateway. Your statement "I think they have the default gateway" is pretty vague. Please ensure everything is set up correctly. Try pinging the gateways in each VLAN (after enabling PING on the given interfaces).
Please also make sure to familiarize with the concept of NAT. In your case, I think SJFriedl mixed the VLans up a bit.
When using NAT and talking from VL20 to VL10, the Hosts in VL10 respond locally (L2) to a host in their own subnet instead of routing packets via gateway to an IP out of their subnet.
jfernandz wrote:Yes, you are right. As long as there is a Firewall policy allowing exactly this communication
Apparently according what you are saying with both (NAT enabled or disabled for the policy) I should be able to reach hosts in VLAN10 from a host in VLAN20 if both have their interfaces properly configured (I mean with their default gateways in their interfaces set using the IP/Netmask for their corresponding Fortigate-interface), is this right?
janwee wrote:Just because you enabled DHCP doesn't mean they get the correct Gateway.
What's the correct Gateway? When some host is having its interface configuration via DHCP, the gateway IP matches with the IP/Netmask of the fortigate-interface.
Also, excuse me, I meant
..., so I think their the default gateway is 172.20.1.1, ...
which I think it's correct.
janwee wrote:When using NAT and talking from VL20 to VL10, the Hosts in VL10 respond locally (L2) to a host in their own subnet instead of routing packets via gateway to an IP out of their subnet.
You mean when you enable NAT for the policy, right?
Basically what jan wrote is this two ways:
- using NAT (Network Address Translation): if you use NAT that means that traffic coming from an IP in one vlan will be "translated" and reach the destination with an ip of the destination net. This is the most common use of NAT and called destination NAT (dnat).
You usually use this when you need to access subnets or hosts you do not have any direct (i.e. connected or static) routing to. One of the most common expamples is your traffic to somewhere on the internet ;)
However this still requires some way to reach the destination. If the client e.g. does not have a connected or static route to that it will still take the default route.
- not using NAT: this is what one usually does if there is connected or static routing or a reachable gateway that knows the routing.
This would require the client to have a route to the gateway. So client in vlan1 has to have the FortiGate vlan1 interface ip als default gateway (or a static route that has that gw). So traffic that goes from this client to vlan2 must go through the fortigate as gw. The FGT then knows the ongoing route as it has in interface in vlan2. All the FGT in this case needs is a policy to allow that traffic to flow :)
So as long as your Clients use the FGT as default Gateway or have a static route to the other subnet(s) with the FGT as Gateway you do not need any NAT. Just a policy on the FGT to allow the traffic is fine...
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
sw2090 wrote:I have found that in order to talk between vlans (a management vlan and a home network), I have to have NAT enabled. I still don't understand why if I have a static route and my pc has a gateway that points to the firewall, and I have policies between vlans, that I have to have NAT enabled. Can anyone explain? ex. VLAN 1 - Server - 10.10.10.5/24, GW 10.10.10.254, VLAN 2 - PC - 10.10.20.1/24, GW 10.10.20.254.Basically what jan wrote is this two ways:
- using NAT (Network Address Translation): if you use NAT that means that traffic coming from an IP in one vlan will be "translated" and reach the destination with an ip of the destination net. This is the most common use of NAT and called destination NAT (dnat).
You usually use this when you need to access subnets or hosts you do not have any direct (i.e. connected or static) routing to. One of the most common expamples is your traffic to somewhere on the internet ;)
However this still requires some way to reach the destination. If the client e.g. does not have a connected or static route to that it will still take the default route.
- not using NAT: this is what one usually does if there is connected or static routing or a reachable gateway that knows the routing.
This would require the client to have a route to the gateway. So client in vlan1 has to have the FortiGate vlan1 interface ip als default gateway (or a static route that has that gw). So traffic that goes from this client to vlan2 must go through the fortigate as gw. The FGT then knows the ongoing route as it has in interface in vlan2. All the FGT in this case needs is a policy to allow that traffic to flow :)
So as long as your Clients use the FGT as default Gateway or have a static route to the other subnet(s) with the FGT as Gateway you do not need any NAT. Just a policy on the FGT to allow the traffic is fine...
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.