[SOLVED] Wifi client cannot ping to router or internet

mv7137

I am running in circles right now, can please someone help me? I am trying to access internet from wifi-connected client. It fails, while internet access is fine from wired Lan clients.

The setup (the important bits):

network (nn): 192.168.102.xx

desktop – switch -- ubiquityAP ~~ laptop
nn.12 nn.3 nn.66
|
|
Netgate-SG-4860 -- BTRouter -- internet
nn.1 192.168.101.254

The wifi connection is marked with ~~. The rest is wired.

I cannot ping from laptop to netgate, or BTRouter.
I can ping from laptop to desktop.
I can ping from desktop to netgate and BTRouter and internet.
I CAN ping from ubiquityAP (using the terminal) to the router and the internet.
I tested that UDP connection also works from laptop to a server on internet, using "nc -u" command and sending messages from laptop to the server.

These are the packages detected on the WAN interface (192.168.101.68, xx:xx:xx:xx:xx:dd) when pinging from the laptop to internet server (ss.ss.ss.97) (xx and ss has been put by me):
(xx:xx:xx:xx:xx:d5 is MAC of the BTRouter interface)

14:53:56.255135 xx:xx:xx:xx:xx:dd > xx:xx:xx:xx:xx:d5, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 21082, offset 0, flags [none], proto ICMP (1), length 84)
192.168.101.68 > ss.ss.ss.97: ICMP echo request, id 32169, seq 5, length 64
14:53:56.336663 xx:xx:xx:xx:xx:d5 > xx:xx:xx:xx:xx:dd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 45, id 4141, offset 0, flags [none], proto ICMP (1), length 84)
ss.ss.ss.97 > 192.168.101.68: ICMP echo reply, id 32169, seq 5, length 64
14:53:56.336711 xx:xx:xx:xx:xx:dd > xx:xx:xx:xx:xx:d5, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 7463, offset 0, flags [none], proto ICMP (1), length 56)
192.168.101.68 > ss.ss.ss.97: ICMP host 192.168.101.68 unreachable, length 36
(tos 0x0, ttl 45, id 4141, offset 0, flags [none], proto ICMP (1), length 84)
ss.ss.ss.97 > 192.168.101.68: ICMP echo reply, id 32169, seq 5, length 64

I have attached the firewall rules for WAN and LAN to this post. I am not 100% sure it is the firewall(?), though… When the firewall was disabled, as far as I can tell, it did not help.

Also, I have other APs, running ddwrt (set up into AP mode), directly connected to the netgate router to interfaces OPT1 and OPT2 and their clients work fine...

Does anyone have any clues where to look for solutions...?

Thank you

UPDATE: I have tried also connecting one of the ddwrt wifi access points to the switch, instead of the ubiquityAP and is still did not work. However, that same AP works when connected directly to OPT2 interface. What am I missing...?

wan.png_thumb

lan.png_thumb

SammyWoo

U created a second subnet on the WIFI router, is this intentional? because using a WIFI router in bridge mode (as Access Point), keeps the same subnet as the rest and simpler wo further issues.

mv7137

Thank you. The ubiquityAP is in AP mode, it does not create a subnet. The wired BTRouter does and it is intentional yes. I am not sure if that is an issue thoug, because even ping from 192.168.102.66 (laptop) to 192.168.102.1 (netgate) does not work.

mv7137

I also tried now connecting the ubiquity AP directly to the pfsense router, but that has not changed anything. No surprise here…

Btw the leds on the WAN and LAN ports are green-orange, while on other ports green-green. What would the orange color indicate?

UPDATE: when the ubiquity AP is connected to the OPT3KIDS interface (directly), it works fine, clients can access internet and dns queries work. (the leds are green-orange but that does not affect the connection). What should I look at on the LAN interface to make it working on LAN??

Added the attachment. Please ignore the Description column - should say "block all traffic to IOT network".

opt3.png_thumb

moikerz

What are your DHCP rules on LAN vs KIDS? Your gateway address should be pfSense not the BTrouter.

What are your floating firewall rules?

Did you accidentally set a gateway address on the LAN interface?

mv7137

Thank you for the question. The DHCP comparison is what would be needed but I had focused on the firewall instead too much. My cousin helped me a lot (remotely) this evening and eventually it was down to the silly thing that I had set: Enable Static ARP entries which allows only the listed clients to communicate with the firewall. I wanted static ARP but not for that price.

After unticking the setting (i.e. after disabling static arp entries), all works perfectly fine.

It was tricky to find out, because I set all the wired clients as static ARP and on the list. Almost everything worked… I've created a backup and from now on, will try to read more and click less.

:) :) :)