UDP Broadcast Relay

[marjohn56]

Just as a side note to anyone reading this thread. I reconfigured my network and lost my relay. Now it turns out that the switch my PC is connected to did not have IGMP snooping turned on, once I did that, everything started working again. So if you've tried everything else, check your switches.

[thexy]

The reply packet is not 239.255.255.250, try adding a specific rule to allow the reply packets to get back to the LAN where the client is.

I temporarily removed all restrictions except for port 1900 and got a match just as well so I'm almost sure the old rule was sufficient as well:

Code: [Select]

pass in quick on igb0_vlan1042 inet proto udp from {10.10.42.16} to {10.10.42.1} port {1900} keep state
Or in config/XML style:

Code: [Select]

<?xml version="1.0"?>
<opnsense>
  <filter>
    <rule>
      <type>pass</type>
      <interface>opt10</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>udp</protocol>
      <source>
        <address>10.10.42.16</address>
      </source>
      <destination>
        <address>10.10.42.1</address>
        <port>1900</port>
      </destination>
    </rule>
  </filter>
</opnsense>
One curious thing I noticed is that the TV sends SSDP response packets to 10.10.42.1.1900 which then show up on interface lo0. File '/var/log/filter.log' confirms:

Code: [Select]

Apr  4 21:09:33 fw-a filterlog[33972]: 123,,,0,lo0,match,pass,out,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
Apr  4 21:09:33 fw-a filterlog[33972]: 122,,,0,lo0,match,pass,in,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
So first these response packets come out of the firewall into lo0, then go in to the firewall never to emrge again - at least not according to tcpdump.

Firewall log live view shows the first out with comment "let out anything from firewall host itself", the in with comment "pass loopback":


At the end of the day if I'm being particularly dense here I can always link Youtube smartphone apps with the TV via the Watch YouTube on TV with a TV code feature; I'm guessing that just establishes comms via YouTube's servers.

Am I missing something obvious? Anything I should be trying?

//edit: Oh I also played around with port forwards and outbound NATting for packets to show up where I'm guessing the Youtube smartphone app is expecting them. Didn't do me any good so far. While testing over time I've seen the TV send out four different types of HTTP NOTIFY requests (also all via 239.255.255.250:1900). It's letting everyone kow that it has:

• http://10.10.42.16:7678/nservice/
• http://10.10.42.16:7676/rcr/
• http://10.10.42.16:9119/screen_sharing
• http://10.10.42.16:9197/dmr

I haven't seen the Youtube smatphone app try to reach any one of those endpoints once so I'm pretty sure it doens't care about those specific SSDP replies.

[marjohn56]

From a  couple of minutes research this is more complex than a simple UDPR, for example:
https://community.ui.com/questions/How-do-I-set-up-my-network-so-that-I-cast-to-an-LG-TV-on-an-isolated-network/dbb36518-d720-452a-b640-fc234f11474f

[xboarder56]

@MarJohn56

What's the recommended solution to use both UPNP - 1900 and having UDPbroadcast relay handle forwarding 1900 to different subnets. I get port conflicts and surprised not more people have mentioned this as an issue.

[marjohn56]

This is not an issue, you cannot have both daemons  using port 1900, if you read this entire thread  ( not for the faint hearted ) from the beginning you'll find it is mentioned.

[Ricardo]

Subscribe
and hoping if I can find a solution for relaying DLNA windows10 server media through an IPSEC tunnel to a remote network

[marjohn56]

Subscribe
and hoping if I can find a solution for relaying DLNA windows10 server media through an IPSEC tunnel to a remote network

You might find help in the VPN section, UDPR only forwards multicast between LANs and VLANs, not VPNs.

[toxic]

I've been out of luck to use this amazing UDP Broadcast Relay for WS-Discovery across VLANS...

It works well for mDNS with my chromecasts

But for WS-Discovery, no matter what source IP I use, "empty", "1.1.1.1" or "1.1.1.2" it just does not manage to let WS-Discovery work from one vlan/subnet to another.

In fact, with "empty", it almost works : probe requests reached the other subnet, that answsers with a probe-match. But Windows has the good idea to see the probe-match packet, but since the source IP is outside it's subnet, it doesn't try to resolve it...

I would like/need this UDP to act like a proxy for WS-discovery, and replace do something similar to NAT, which I thought could be the 1.1.1.1 or 1.1.1.2 source, but in fact sadly no...

Would you be willing to look at the ws-discovery protocol and implement some other mechanism to be able to act as a ws-discovery proxy (lots of documentation show this is allowed by the protocol but I could find no implementation of this anywhere).

Thanks in advance for your reading.

[verasense]

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?

[mkuech]

Just wanted to share something that confused me as it might help others with their firewall rules. My home network is set up with my primary LAN network (most trusted devices) having access to all VLAN machines. My firewall rules for this are on the LAN interface. However, broadcasts weren't getting through to the VLAN and I couldn't figure out why (source and multicast addresses were left blank, so the broadcasts still appeared to be coming from the original machine). I discovered I needed an additional rule on my VLAN interface to specifically allow broadcasts from my LAN network, despite that rule already being in place on my LAN interface. It seems the source interface's rules aren't being looked at in the event the firewall box itself is generating the traffic or something? I understand why if that's the case, it's just something to be aware of for this plugin.

Hopefully this helps someone else.

[marjohn56]

UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.

[mkuech]

forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.

Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.

I was having this issue too. If I try to use the multicast address of 255.255.255.255 (port 987, PS4 device discovery but only sometimes), it'd silently fail and I had no idea if it was actually running or not. Restarting it from shell, or starting the binary manually with the same options (thanks to the config file for making it a copy/paste ordeal) gave me the

Code: [Select]

IP_ADD_MEMBERSHIP on rcv: Invalid argument message. It wasn't until I saw this part of the thread and got rid of the multicast option that it was able to start up successfully. I suppose it probably won't matter to me if I leave it like that but I like to be explicit in my rules.

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

[mkuech]

UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.

This where I'm confused. I'm actually seeing 2 broadcasts on the vlan interface in the firewall log live view, one in the OUT direction (which is allowed through, "let out anything from firewall host itself") and one in the IN direction (which is being blocked via a default deny rule). The IN is what I needed an additional rule for. Both broadcasts are from the same IP on LAN. If I disable the rule, the PS4 Second Screen application doesn't find my PS4. It's only when I re-enable it that it works.

I also have a rule allowing broadcast traffic back from the VLAN to LAN, and that was enabled the entire time while testing all this.

[marjohn56]

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Correct,  that's not multicast it's broadcast.

[mkuech]

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Correct,  that's not multicast it's broadcast.

Thanks for clarifying, so if it's broadcast, users are meant to leave that field blank? I mean I know it's labeled "multicast addresses" but it wasn't super clear to me what should be done in that case.