Hi,
I am having a internal LAN on 192.168.1.0/24 - which is getting too small slowly.
Now I created a second LAN for 192.168.2.0/24.
On this subnet all the IOT-devices should reside and they only should have internet access occasionally (for updates).
As my OPnsense is running on a VM, I bound an additional IP within 192.168.2 and created a new interface in OPnsense.
How can I let this two interfaces communicate without any restrictions (MQTT, web and so on), but only open WAN access on the second subnet (192.168.2) for special IPs temporarrily?
Best regards and thanks in advance,
Otto
Create three firewall rules on LAN2:
pass in any, destination LAN2 address (for DNS etc.)
pass in any, destination LAN1 net (for accessing primary LAN)
pass in any, destination any (for Internet access)
Simply disable the last rule to disable Internet access for LAN2.
Cheers
Maurice
Hi!
works like a charm! THANKS a lot!
cheers,
Otto
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?
Hi,
somewhere NAT enabled?
Any rules on LAN to direction OPT2 blocked?
Waht means "is not working"? Can you ping between the two networks?
Check firewall logs for blocked packets.
/KNEBB
Hi Knebb,
Just the default NAT rules, I haven't added any
(https://i.postimg.cc/4KntC06w/brave-Vh-U5a-HXZd0.png) (https://postimg.cc/4KntC06w)
LAN rules are the default allow any:
(https://i.postimg.cc/rRJFwSxg/brave-Sgx-Ip36-Eyi.png) (https://postimg.cc/rRJFwSxg)
Firewall log shows traffic being allowed:
(https://i.postimg.cc/dZZHwKX9/brave-l-HVu-CBf-Pu-O.png) (https://postimg.cc/dZZHwKX9)
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.
Sound strange, indeed.
What are your rules for OPT1 and OPT2?
Let us see!
So far as I can see at the moment the icmp request is allowed and goes out to opt1. But I can not see the answer from the 192.168.89.1 device because of filtering.
Can you do a packet capture on the opt1 for all icmp packets? Can the OPNSense ping the 89.1 host?
/KNEBB
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
(https://i.postimg.cc/87N48gmL/opt1-rules.png) (https://postimg.cc/87N48gmL)
OPT2 firewall rules
(https://i.postimg.cc/kVhvt63y/opt2-rules.png) (https://postimg.cc/kVhvt63y)
Ping from opnsense works for both devices
(https://i.postimg.cc/jwHCYmXJ/ping-from-opnsense.png) (https://postimg.cc/jwHCYmXJ)
Ping LAN from OPT1 and OPT2 devices
- OPT1 fails
- OPT2 succeeds
(https://i.postimg.cc/ZBBFPbJz/ping-lan-from-opt2-and-opt3.png) (https://postimg.cc/ZBBFPbJz)
ping OPT1 <--> OPT2 works in both directions
(https://i.postimg.cc/ygMhvMNg/ping-both-opt2-opt3.png) (https://postimg.cc/ygMhvMNg)
ping LAN gateway from OPT1 succeeds
(https://i.postimg.cc/svR9SC8b/ping-lan-gateway-from-opt1.png) (https://postimg.cc/svR9SC8b)
Finally, I can ping OPT1 (192.168.2.100) from my phone on LAN
Hi,
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.
You do not have configured any arp poisoning? No static arp entries or weird stuff like this?
/KNEBB
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.
Quote from: knebb on December 03, 2023, 09:54:17 PM
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.
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:
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 64It 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.
Could be some guest Wifi feature going rogue. Can you temporarily turn that AP off? Or are all devices in LAN connected to it?
Quote from: Maurice on December 04, 2023, 01:26:48 AM
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
"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.
Quote from: Maurice on December 04, 2023, 01:41:34 AM
"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.
Quote from: Maurice on December 04, 2023, 01:41:34 AM
"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.