Problem with dumb AP?

Hi guys, i have this diagram:

I have a VPN configured with WireGuard but i have encountered one problem, like diagram shows, from B point i can ping/traceroute from Proxmox host to all wired devices in A point but not the wireless ones.

It is understandable to think that 192.168.2.2 (OpenWRT dumb AP) or 192.168.2.3 (TP-Link repeater) are causing this but the TP-Link repeater is just a wifi extender (it comes without firewall) so i can understand this is not the problem (since I can't configure anything on it).

The OpenWRT Dumb AP works fine as AP but i dont know if it comes with a configuration that is rejecting the pings/traceroutes (and more things) to the wireless devices.

At this point my questions are:

  • Can the Dumb AP be configured to let all packets pass through it?
  • Why can I ping/traceroute to the wired devices but not the wireless ones?

Here I show the Dumb AP firewall configuration:

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option synflood_protect '1'
        option forward 'ACCEPT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option output 'ACCEPT'
        option masq '1'
        option mtu_fix '1'
        option input 'REJECT'
        option forward 'REJECT'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

root@OpenWrt:~#

Here is one traceroute from Proxmox host at B site to one wired host on A site:

root@proxmox:/# traceroute 192.168.2.4
traceroute to 192.168.2.4 (192.168.2.4), 30 hops max, 60 byte packets
 1  www.adsl.vf (192.168.1.1)  0.727 ms  0.971 ms  1.181 ms
 2  192.168.1.7 (192.168.1.7)  2.365 ms  2.836 ms  3.276 ms
 3  192.168.9.2 (192.168.9.2)  24.520 ms  24.514 ms  24.480 ms
 4  192.168.2.4 (192.168.2.4)  25.359 ms  24.777 ms  25.229 ms
root@proxmox:/#

And here is one traceroute from Proxmox host at B site to one wireless host on A site:

root@proxmox:/# traceroute 192.168.2.226
traceroute to 192.168.2.226 (192.168.2.226), 30 hops max, 60 byte packets
 1  www.adsl.vf (192.168.1.1)  1.711 ms  2.277 ms  4.102 ms
 2  192.168.1.7 (192.168.1.7)  5.295 ms  5.970 ms  6.570 ms
 3  192.168.9.2 (192.168.9.2)  30.377 ms  30.341 ms  30.304 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@proxmox:/#

I would appreciate any help

First, realize that when configured at default, Windows PCs will not answer pings. The Windows Firewall may also restrict connections from RFC1918 (private) IP addresses that are outside the machine's LAN, which is the case with a site to site VPN. I don't think this blocking is enabled by default though.

What happens inside a TP-Link or other off the shelf wifi repeater is actually not simple, as the wifi standard does not allow for a simple "wifi repeater." AP to STA connections only allow one MAC address on the STA side, for the original intended usage where the STA is always an endpoint device such as a laptop. The wifi repeater does some tricks so that everything on the far side of the repeater appears to the source AP to have the same MAC address (you can see this in the site A main router's ARP table). In order for this to work, a device on the far side has to originate a connection to get the addressing tables set up before an incoming connection can be passed through.

If you can run OpenWrt on both sides of the repeater link you can use the WDS protocol, which does preserve the original MAC addresses across the link, and gives much more consistent repeater performance.

A few things could be ruled out if you have a way to originate the test pings at Site A rather than sending them through the tunnel from a B machine.

I cant :confused:

From A (and from opossite side of the repeater), i can ping 192.168.2.226 correctly, even from 192.168.2.226 i can ping 192.168.1.116 (at B site).

EDIT: Ok... i am the dumb, i didnt test if it could work deactivating Windows Firewall before posting. I apologise. And thanks @mk24 for your light in this...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.