Messages

"Nearly all" doesn't mean all, right? Turn the AP off, repeat the tests with the remaining devices. If this works, you know it's the AP's fault.

You are correct; however, I assume it's the AP's fault.

I've swapped OPT1 to 192.168.20.0/24 and everything is working fine now.

I highly suspect it has something to do with how orbi handles its guest network, which is hardcoded to 192.168.2.0/24. To be clear, the guest network is disabled, but I think some other things are going on under the hood causing it to treat this traffic differently.

Thanks all of you for the help, I really appreciate it.

"Nearly all" doesn't mean all, right? Turn the AP off, repeat the tests with the remaining devices. If this works, you know it's the AP's fault.

You are correct; however, I assume it's the AP's fault.

I've swapped OPT1 to 192.168.20.0/24 and everything is working fine now.

I highly suspect it has something to do with how orbi handles its guest network, which is hardcoded to 192.168.2.0/24. To be clear, the guest network is disabled, but I think some other things are going on under the hood causing it to treat this traffic differently.

Thanks all of you for the help, I really appreciate it.

Could be some guest Wifi feature going rogue. Can you temporarily turn that AP off? Or are all devices in LAN connected to it?

Unfortunately, nearly all of my LAN devices are connected to that Orbi

do a tcpdump (it is a Linux in LAN, right?) and catch the ICMP packets which come in while trying to ping from OPT1. Post it here.
/KNEBB

Okay, this is a bit interesting.

My laptop is 192.168.1.161. I confirmed OPT2 can ping it, and that OPT1 is still having issues with it.

192.168.1.184 is the Netgear Orbi that is used to provide WiFi on 192.168.1.0/24.

Code Select Expand

sudo tcpdump -i en0 -n icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
19:01:06.826675 IP 192.168.1.184 > 192.168.1.161: ICMP echo request, id 1, seq 3102, length 40
19:01:06.826831 IP 192.168.1.161 > 192.168.1.184: ICMP echo reply, id 1, seq 3102, length 40
19:01:07.422731 IP 192.168.1.184 > 192.168.1.161: ICMP host 192.168.1.184 unreachable, length 68


I've confirmed that the unit is in AP mode with the following settings:
- DHCP   Off
- IP Address   192.168.1.184
- IP Subnet Mask   255.255.255.0
- Gateway IP Address   192.168.1.1
- Domain Name Server   192.168.1.1

However, when pinging from 192.168.3.2, we get what we want:

Code Select Expand

sudo tcpdump -i en0 -n icmp
Password:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
19:06:44.518423 IP 192.168.3.2 > 192.168.1.161: ICMP echo request, id 49793, seq 9, length 64
19:06:44.518548 IP 192.168.1.161 > 192.168.3.2: ICMP echo reply, id 49793, seq 9, length 64

It looks like only 192.168.2.0/24 is being "converted" into 192.168.1.184; this is not the case for the other subnets.

I haven't done anything like what you've mentioned. Since I've reset opnsense it's nearly all default settings except for users/interfaces/fw rules/dhcp

The device 192.168.1.89 is just a printer; however, I can try pinging my laptop. I'll reply with the results.

By the way, I had included a zip containing the packet capture results in my previous post; the link is a bit small at the end of the post. Just mentioning in case you may find it useful.

I will attempt pinging my laptop and report back.

[only requests, no replies]

Thanks for working with me on this; you have no idea how frustrated I am  :-[

To summarize the below, it looks like devices on OPT1 cannot communicate with LAN but only in the OPT1 -> LAN direction. LAN -> OPT1 ping works. Everything else seems to work.

It's logged these pings I've tried (on OPT1, promiscuous=true)
192.168.2.100 -> 192.168.1.89 (I see only requests, no replies)
OPNsense -> 192.168.2.100 (I see both request and replies)

Here's screenshots:

OPT1 firewall rules


OPT2 firewall rules


Ping from opnsense works for both devices


Ping LAN from OPT1 and OPT2 devices
- OPT1 fails
- OPT2 succeeds


ping OPT1 <--> OPT2 works in both directions


ping LAN gateway from OPT1 succeeds


Finally, I can ping OPT1 (192.168.2.100) from my phone on LAN

Hi Knebb,

Just the default NAT rules, I haven't added any


LAN rules are the default allow any:


Firewall log shows traffic being allowed:


Not working means OPT1 can't ping LAN
Ping 192.168.2.100 --> 192.168.1.89 fails

However, OPT2, with the same rules as OPT1 works:
Ping 192.168.3.2  --> 192.168.1.89 succeeds

Also, OPT1 can ping OPT2, for whatever reason:
Ping 192.168.2.100 --> 192.168.1.89 succeeds

The only other peculiarity I saw was that when I did packet capture, only the 192.168.2.100 request was caught; there was no response from 192.168.1.89 as there was with 192.168.3.2.

Hey, I'm having a similar issue, but this did not work for me.

I want OPT1 to communicate with LAN, but it's not working, even with rules to allow anything:
   Protocol   Source   Port   Destination   Port   Gateway   Schedule      Description       
        IPv4 *   *   *   *   *   *   *      Allow to any      
        IPv6 *   *   *   *   *   *   *      Allow to any

I have the same rules on OPT2 and it's working; if I switch my device to OPT2 everything is fine. Any idea?

[not]

I'm pulling my hair out trying to figure this out; I've gone as far as resetting my opnsense unit to try and resolve it.

I have:
LAN - 192.168.1.0/24
OPT1 - 192.168.2.0/24
OPT2 - 192.168.3.0/24

OPT1 -> LAN does not work (i.e. pinging 92.168.200 -> 192.168.1.89 works)
OPT1 -> OPT2 works
OPT2 -> LAN works

I have nearly identical setups for each of these;
- The rules are set to allow any traffic into the respective interface
- the firewall log shows that traffic is being allowed
- packet filter shows the ping request
- packet filter does not show the ping reply

I haven't set anything else up since I reset my unit. There's no groups, floating rules, VLANs, etc.