Messages

1

General Discussion / Re: SSDP/DLNA and UDP Broadcast Relay

« on: November 02, 2022, 08:42:55 pm »

I have news, still not working though.

If I put 1.1.1.1 as source address, I can see one additional packet :
Nov  2 20:28:10 192.168.1.3 Nov  2 20:28:10 Cerbere.ocean.local filterlog[32648]: 69,,,6125cb207f65033775d1069fdf6d0ccf,lo0,match,pass,out,4,0x0,,65,4660,0,none,17,udp,325,192.168.1.3,192.168.2.1,1900,1900,305

It's an additional packet from OPNSense internal engine, which appears only after the media server answers to the SSDP M-SEARCH request, and after the packets I indicated in my previous post.

This packet appears on local 0 interface (lo0), authorized, applied on the "out" going, but the source is 192.168.1.3 (WAN Address of OPNSense) and the destination 192.168.2.1 (LAN Address from OPNSense). Both source and dest port are 1900.
I don't understand why this packet has this behaviour. It can't be routed back to the client if dest is on the Media Server LAN.

Still searching...

2

General Discussion / SSDP/DLNA and UDP Broadcast Relay

« on: November 02, 2022, 12:29:33 am »

Hello there,

I browsed many topics, but didn't find a similar problem as I have.

I want my OPNSense relay SSDP discovery packets and permits DLNA to work through it. I don't have any VLAN.
After many readings and tests with PIMd or IGMP Proxy, I tried to use UDP Broadcast relay or udp-proxy-2020.

It turns out that UDP Broadcast Relay seems to be the best one BUT :
I use 1.1.1.2 address in settings so packets from a WAN Net address (client, 192.168.1.33) gets the LAN Address outgoing IP interface (192.168.2.1) when relaying broadcast to LAN Net where Media Server (miniDLNA) is hosted.

From my Splunk I can see the following logs (see screenshot):
- source 192.168.1.33 sends broadcast on WAN Net to 239.255.255.250, source port 56192, dest port=1900

Then I see :
- source 192.168.2.1 sends broadcast on LAN Net to 239.255.255.250, source port 56192, dest port=1900. This is stating that UDP Brodcast Relay is working as expected at this point: packet is relayed on the LAN side.

After that I've got the Media Server answer, that sends unicast packet from source port 1900 to the very IP that sent the broadcast
- source 192.168.2.18 sends unicast answer to dest=192.168.2.1, source port 1900, dest port=56192

And then...nothing. Packet never goes through the firewall back to the original client (192.168.1.33).
The provided screenshot has to be read from bottom to the top (most recent logs are displayed first).

It seems that OPN Sense doesn't know what to do with the packet when it reaches the firewall engine (IN -> Firewall -> OUT).
The route to get back to the originating IP is the WAN Net, so no route problem.
There is no blocked packet and I do log every rule in order to be sure.

From a pure firewall perspective, it's normal : 192.168.2.1 is the destination of the unicast packet. So it won't get further.
But if that's the case, I don't know how other people are making this work (marjohn56 or bertofurth on this thread : https://forum.opnsense.org/index.php?topic=15721.0).

I think I'm missing something but don't find what... Please if someone has an idea...

PS : I thought it was due to my multiple WAN Virtual IPs, so that the firewall didn't know on which Adress route the packet, but I removed all other Virtual IPs, it didn't correct the problem.

3

Web Proxy Filtering and Caching / SQUID ACL category filtering logging

« on: July 06, 2020, 10:36:28 pm »

Hello there,

Is there someone able to explain me how to enhance SQUID logs  to add the category that was filtered in the logs ?
I'm using ACLs from Lille University and filtering some categories. But when a connection is dropped/blocked by SQUID, I'm only getting TCP_DENIED. I want to know which category was blocked. Is this only possible ? And if yes, how ?
I receive my logs by syslog to my Splunk.
Thank you.