Wi-Fi, subnets and cabled devices

[pmh]

We have a splitted subnet:

LAN2: (physical interface)

172.29.6.1/255.255.255.128 for FortiAP's

Wi-Fi SSID:

172.29.6.129/255.255.255.128

I have connected a cabled physical device and given static ip details:

ip:  172.29.6.201

gw: 172.29.6.129

sub: 255.255.255.128 

Was hoping I could reach this device from the Wi-Fi clients, but no good. All good when connected to cable though. Where am I going wrong here?

-PM

*edited LAN1 to LAN2

[Markus_M]

Hi pmh,

It sounds like are missing a firewall policy.

You can test whether that is the case:

diag debug console timestamp enable
diag debug flow filter proto 1 (=icmp)
diag debug flow filter addr 172.29.6.201
diag debug flow show iprope enable
diag debug enable
diag debug flow trace start 20

Run a second SSH session with a packet capture to show which interface the packets are arriving at and leaving at (if any).

diag sniffer packet any 'host 172.29.6.201' 4 0 a

Then run a ping to that device.

- the flow trace will show if there is a policy match and what routing decisions are taken.

- the sniffer will show you the incoming interface of the traffic as well as the outgoing. If there is no policy match, there won't be outgoing traffic.

Best regards,

Markus

[pmh]

Hi Markus,

Thanks for your reply. Tried this now and got the below result:

fgt-name (crew) # diag sniffer packet any 'host 172.29.6.201' 4 0 a
interfaces=[any]
filters=[host 172.29.6.201]
2021-12-23 17:50:58.496217 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:50:59.921865 lan2 in 172.29.6.201.12345 -> 255.255.255.255.12345: udp 450
2021-12-23 17:51:00.583504 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:01.163824 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:01.599185 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:01.921638 lan2 in 172.29.6.201.12345 -> 255.255.255.255.12345: udp 450
2021-12-23 17:51:02.005358 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:02.622811 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:03.012420 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:03.920836 lan2 in 172.29.6.201.12345 -> 255.255.255.255.12345: udp 450
2021-12-23 17:51:04.194155 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:04.199888 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:05.007252 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:05.213791 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:05.921636 lan2 in 172.29.6.201.12345 -> 255.255.255.255.12345: udp 450
2021-12-23 17:51:06.026824 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:06.237475 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:07.603104 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:07.921265 lan2 in 172.29.6.201.12345 -> 255.255.255.255.12345: udp 450
2021-12-23 17:51:08.199220 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
2021-12-23 17:51:08.604550 lan2 in arp who-has 172.29.6.129 tell 172.29.6.201
2021-12-23 17:51:09.001465 CrewName in arp who-has 172.29.6.201 tell 172.29.6.186
^C
25 packets received by filter
0 packets dropped by kernel

Didn't really make me any wiser unfortunately. 

-PM

[Markus_M]

Hi PM,

one device of yours, 172.29.6.186 is asking via arp where 172.29.6.201 is or which MAC it has because it is not known on which interface it is. This is happening on interface "CrewName". I suppose, this is your SSID name.

Then 172.29.6.201 is asking the same for its own subnets' gateway IP on "lan2" (your initial post doesn't mention lan2, but lan1 and the address is outside it).

I would want to say that FGT is being asked this but not responding to it; However, you want to check why the same subnet is known on 2 different interfaces.

That configuration isn't possible without enabling an "overlapping subnet".

Explanation:

The range you have here is from 172.29.6.128-172.29.6.255; .128 being the network address, .255 being the broadcast address.

All other 126 addresses in between belong to the same subnet and must be on the same interface as it handles one defined subnet.

172.29.6.129 is your configured gateway for the devices in the same network and the interface IP for the SSID interface.

172.29.6.186 is in that same network supposedly, so is 172.29.6.201.

If the 172.29.6.201 is on a different interface, you should check why it seems to be there and why it has that IP (statically assigned?).

Best regards,

Markus

[pmh]

Hi again Markus and thank you so much for helping me on this. 

You are correct, it should be LAN2 (not LAN1).

"CrewName" is indeed the SSID for the Wi-Fi.

Also, yes 172.29.6.186 is the Wi-Fi connected client I am pinging the LAN2 connected device 172.29.6.201 (static ip) from. Both devices are in the same subnet 255.255.255.128

I was initially thinking that it should be possible to comunicate as long as the devices were in the same subnet, but if I understand you correctly they also have to be connected to the same interface (Wi-Fi "CrewName" clients cannot connect to devices physically connected to cabled devices on LAN2)  

That basically correct?

[Debbie_FTNT · Accepted solution]

Hi pmh,

yes, you are correct. FortiGate implicitly denies traffic between separate interfaces, even if they should be in the same subnet. You would have to create a policy from lan2 to your SSID, and would have to ensure that the server IP is within the subnet for lan2, not the SSID subnet, otherwise traffic will fail on the reverse routing check.

One way around the policy requirement would be to create a software switch out of the interfaces (the SSID and lan2 interface) and have a single interface IP and subnet on those two interfaces. You would have to roll back some IP configuration to put lan2 and the SSID into a switch interface, though.

Another option would be to switch the SSID to bridge mode (instead of tunnel mode), that way the SSID is essentials considered part of the physical interface the access point is connected on (it achieves the same result as creating a software switch).
In tunnel mode, the SSID is considered an entirely separate (virtual) interface from LAN2, and communication from anything in WiFi is tunnelled via CAPWAP; you essentially have two completely different connections on LAN2.

You could also put the SSID and lan2 into a zone, and allow intra-zone traffic, that would also eliminate the need for a policy. However, as there is no shared subnet between lan2 and the SSID, you would still need to update the server IP to ensure it is within the lan2 /25 subnet to prevent traffic failing on a routing check.

If you are unsure what the routing check is:
When FortiGate receives the first packet in a session, it does a basic sanity check to verify that a reply to that IP would go back out the interface it received the packet on.
In your case:

- FortiGate receives a packet with source IP .201 on lan2

- it checks its routing table to determine where it would send replies TO the IP .201
- it sees that the .201 IP belongs to the SSID subnet, not lan2, so the routing does NOT check out
- it denies the packet based on reverse path check failure
- this is intended as a basic check to prevent IP spoofing

I hope this helps :)

[pmh]

Hi Debbie and thank you for your explanation.

I already have the two interfaces in a zone, and I'm not blocking intra-zone-traffic, so if I understand you correctly I can simply change the IP details on my server from .201 to .121 and I should be able to reach the server from my Wi-Fi clients?

If so, do I also need to change my gateway on the server from .129 to .1 ?

[Debbie_FTNT]

Hey pmh,

yes and yes, that should allow you to ping clients in the wifi subnet.
If you are pinging Windows clients, make sure their firewalls allow the ping :)

[pmh]

Just wanted to let you know that after changing mentioned IP details and adding a policy:

Source interface: My_ZONE
Destination interface: My_ZONE
SourceIP: SERVER
DestIP: DEVICES

all is working :)

Thank you so much for al your help @Debbie_FTNT and @Markus_M !