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

Fortigate - Dont allow Traffic between Networks on same physical Interface / Secondary IP Address

Hello!

We have an interface on our Fortigate which has multiple secondary IP addresses. Is there a way to stop the traffic between the networks?

 

For example:

Interface with IP 10.0.0.254/24
Same interface with secondary IP address 172.16.0.254/24
Same interface with secondary IP address 192.168.0.254/24

 

Unfortunately, it is currently possible for devices in the respective subnets to reach each other via the interface. However, I would like to prevent traffic between them and define exceptions.

 

We also do not have enough ports to bring the individual networks into their own interface.

Thanks for your help!

9 REPLIES 9
fg_muc
New Contributor III

Hi Martin,

 

try to create a firewall policy from the interface to the interface where those IPs are located.
So let's say you have all those IPs on port1 then create a firewall policy source interface "port1" and destination interface "port1", then just put the source/destinations which you don't want to communicate and set the action to deny.

 

Regards,

Fabian

"Latency is just your network being dramatic."
"Latency is just your network being dramatic."
Martin_Austria

Hello Fabian,

 

ive tried that already a few months ago. However, to be on the safe side, I have created this policy again as you have described it. Unfortunately, the traffic is still allowed. The Policy is at the top of the rules and blocks any communication between 10.1.42.0 and 10.1.44.0.

Maybe I should have mentioned that we also have secondary IPs on a 2nd interface. But the communication between these networks is blocked without us having policies there.

 

You see here a debug flow between the networks 10.1.42.0 /24 and 10.1.44.0 /24 (which are on the same interface).

 


11:02:12
vd-root:0 received a packet(proto=1, 10.1.42.100:1->10.1.44.100:2048) tun_id=0.0.0.0 from port15. type=8, code=0, id=1, seq=47.
11:02:12
allocate a new session-0024083b
11:02:12
in-[port15], out-[]
11:02:12
len=0
11:02:12
result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000
11:02:12
find a route: flag=00000000 gw-0.0.0.0 via port15
Packet Trace #74
2
11:02:12
vd-root:0 received a packet(proto=1, 10.1.44.100:1->10.1.42.100:0) tun_id=0.0.0.0 from port15. type=0, code=0, id=1, seq=47.
11:02:12
find a route: flag=00000000 gw-0.0.0.0 via port15

 

Here is the interface on which communication between the networks is automatically not allowed. We did not have to set anything extra for this

 

This is wrong, ive just tested it and it also allows the traffic between the subnets

 

edit "port9"
set vdom "root"
set ip 10.100.100.254 255.255.255.0
set allowaccess ping
set type physical
set alias "LAN-9"
set snmp-index 20
set secondary-IP enable
config secondaryip
edit 1
set ip 10.114.94.254 255.255.255.0
set allowaccess ping
next
edit 2
set ip 10.200.100.254 255.255.255.0
set allowaccess ping
next

end
next

 

Here is the interface on which communication between the networks is allowed for some reason

 

edit "port15"
set vdom "root"
set ip 10.216.12.254 255.255.255.0
set allowaccess ping https http
set type physical
set alias "LAN-15"
set snmp-index 71
set secondary-IP enable
config secondaryip
edit 1
set ip 10.1.42.254 255.255.255.0
set allowaccess ping
next
edit 2
set ip 10.1.44.254 255.255.255.0
set allowaccess ping
next
end

 

Martin_Austria

Sorry, the answer was not quite correct. The other interface with multiple secondary IP addresses also allows traffic between the networks

fg_muc

It seems that there is no policy checking which takes place in the first debug, I'M not sure if this is the desired behavior for traffic on the same physical interface...

result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000


Is this interface member of a zone or something?

"Latency is just your network being dramatic."
"Latency is just your network being dramatic."
Martin_Austria

No, is not a member of a zone.

I have now tested the same thing with a Fortigate 60F (the other firewall is a cloud firewall). Here, too, the networks can reach each other in the same interface, even if you explicitly create a deny rule that prevents it

FranFisc1
New Contributor III

Hello Martin,

you seem to have all 3 IP Layer 3 networks in the same layer 2 domain.
With that setup, you cannot control direct communication between 2 devices on the layer 2.

The solution is to configure Virtual LANs on the switch and the firewall. (VLANs)

Configure 1 VLAN per IP Subnetwork on the switch and use 802.1Q tagging
to seperate the VLANs on the single Link to the firewall.
This may help:
  https://docs.fortinet.com/document/fortigate/6.2.9/cookbook/402940/vlans

You will have a VLAN interface for each Network on the firewall.

This virtual interface can be used in Policies as source and destination interfaces. 

If configured correctly, it works. The reverse conclusion does not apply necessarily.
If configured correctly, it works. The reverse conclusion does not apply necessarily.
Martin_Austria

Hello!

Unfortunately it's a cloud firewall in a data center, we can't create VLAN interfaces on the switches. We get a VLAN interface through which we have multiple servers connected.

Is there any other way to prohibit this traffic? It flows through the firewall.

fg_muc

I think the problem that FrankFisc1 described applies exactly to your case, I just had a knot in my head here...
If it is a cloud environment, it may be a bit more complicated, as there is no “classic” Layer2 traffic (e.g. Azure).
But maybe a solution could be to put the networks on dedicated physical ports on the firewall and then use different vNics on the VM.

"Latency is just your network being dramatic."
"Latency is just your network being dramatic."
Martin_Austria

Maybe that could work. Whereby we then unfortunately come up against the 24 port limit which is for cloud VMs. I would need almost double that.

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors