Messages

I am trying to remove a host from the Live View display. I have set host != IP but it is still showing up.

Is this a bug or am I doing something wrong?

I actually need to forward these broadcast packets to another VLAN, since these are sent by my camera client software and need to find the camera on another VLAN.  I installed UDP Broadcast Relay thinking that it was able to do so...  Is there any alternative?


EDIT: Both VLANs can see each other, and I tested the packet to x.x.x.255 was forwarded. But the packet to 255.255.255.255 does not seem to be forwarded

I need to access some cameras on a VLAN, and they are contacted via broadcast packets on a random UDP port (e.g. UDP/2230 for 255.255.255.255 - although I think OPNsense will translate this to x.x.x.255?)

Is there a way to use UDP broadcast relay for this?  I only see options for fixed ports and broadcast address 255.255.255.255 is not valid.

Or is there any forwarding solution for OPNsense?

I have analysed the packets from a computer on the same LAN as the device and from a computer in a different VLAN with udp broadcast relay. The only difference I see is that the legitimate one sends an additional broadcast packet to 255.255.255.255 (apart from X.X.X.255). However, I can't use these broadcast IPs on udp broadcast relay because it marks them in "yellow" colour instead of "green", as if they were not valid.

Yes, I think I have my rules OK. I was in the Live View and capturing packets on the interface (that's how I saw that the UDP packet was correctly delivered) but I did not receive any response from the device. I thought that maybe it's because the packet came from another network, not from its same LAN. Then I changed the "source" in the udpbroadcastrelay plugin to an address in the same LAN, and I could see the packet was forwarded with the "spoofed" IP. No answer either.

So I have no idea at the moment.  I will continue tests tomorrow since I opened the firewall to let the device connect to its external server and now the apps have learn the device IP, so everything works even if I enable the firewall. However, after some time they will forget the IP again and I will have the same problem.

That is why being able to VPN into the same local VLAN was the easiest for me.

BTW, this is probably a long shot, but have you looked into whether the udpbroadcastrelay plugin works across VPN interfaces?

I was exactly looking into this before reading your post.

I came along to this post:
https://forum.opnsense.org/index.php?topic=15721.0

And I installed the plugin. It seems to do what is expected, but the device is not answering me back...

Unfortunately, TAP mode is not supported on Android OpenVPN.... : (  So not a solution for me.

I wonder how people do this... to check IoT devices away from home via VPN. Many of them don't use mDNS so there must be a way.

I will check tap and get back here.

By the way, does it make sense that when I use as source "VPN net" the rule is not triggered at the firewall but when I use the VPN net explicity (192.168.100.0/24) it does?

PASS IPv4 VPN net   *   *   IOT net   *   *   *   --> Not triggered, so next rule blocks access
Log:
ovpns1      Apr 2 15:58:16   192.168.100.6   192.168.3.200   icmp   Block VLAN

PASS IPv4 192.168.100.0/24   *   *   IOT net   *   *   *  --> Triggered
Log:
ovpns1      Apr 2 15:58:41   192.168.100.6   192.168.3.200   icmp   

I thought "net" means every host in the VPN network

Is there no other way than tap? I suppose many people run IoT devices on a different VLAN, and many devices don't use mDNS but only simple broadcasting... There must be a way.

I always thought VPN could make you part of the internal network, using the same DHCP and policies as if you were connecting via a LAN cable.

Mmm.. But this does not give me an address in the VLAN as if I was another member of the VLAN...

And this then I suppose is not relevant: IPv4 Local Network = 192.168.3.0/24

Another point that makes this solution not valid for me is that there are some devices broadcasting their service, and even though the VPN client is allowed to access the 192.168.3.0 network and ping the device, it does not get the needed broadcast packets.

This should be an easy one, but I can't make it work.

I am trying to connect as a client to the OpenVPN server. What I want is to connect as if I was in one of my VLANs, transparently, let's say 192.168.3.0/24, and get an IP address from there as everyone else in the network.

So I use:
IPv4 Tunnel Network = 192.168.100.0/24
IPv4 Local Network = 192.168.3.0/24
Dynamic IP   unchecked
Address Pool   checked
Topology   unchecked

However I always get a 192.168.100.0 IP address and I am not able to access the VLAN. How can I configure this?

Thanks :-D

This happened to me when I had no Internet connection.

Verify these:

1 - DNS is OK
Services - Unbound DNS - General - Enable Unbound (checked) and Enable Forwarding Mode (checked).
System-Settings-General-DNS servers (e.g. 1.1.1.1, 8.8.8.8  use gateway WAN).

2 - Correct Gateway
Systems - Gateways - Single
"Upstream Gateway" in WAN

Mmmm.. Actually I didn't observe that, it is an assumption. I thought that connecting to the VLAN 10 on interface 1 and to the VLAN 10 on interface 2 was going to exchange packets between them.

You are right about that - I actually remember I had to create a bridge in the past to connect two networks from different interfaces. Just thought that having the same VLAN will trigger the same behaviour as a switch, which is not true.

Yes, there are separated physical interfaces, my concern is that, in the same way that if I set the same VLAN in two different physical LAN interfaces they will be "connected", this will happen somehow with the WAN interface. Not sure if the behaviour would be to share a broadcast domain between my LAN VLAN20 and the WAN.

I know that there are a lot of VLAN IDs to choose from, but I had already set my network with certain VLANs before. It is just that my ISP has required me a specific VLAN to connect to its fiber afterwards, and it just happened to be one that I had already assigned and configured.