How to make multicast work within the OpenVPN tunnel network?

[kevindd992002]

So I have an OpenVPN remote access server setup and the clients connect just fine. The only problem is that Upnp does not work because the client -> server multicast traffic is not being received by the server. On the other hand, the server -> client multicast traffic is received by the client perfectly. I've been reading and realized that multicast traffic is not sent through the tunnel network natively. If that's the case, what do I do to make this work? I don't believe I need an IGMP proxy because I'm not trying to make multicast traffic in between networks. I only need it within the OpenVPN tunnel network. I'm currently using tun instead of tap.

[chpalmer]

I played with this for about a day and never had success..

Love to see it figured out.

[kevindd992002]

Maybe @jimp has some ideas?

[JKnott]

@kevindd992002

Multicasts don't pass through routers, unless specifically enabled. When you go from your LAN to a VPN, you're passing through a router.

[chpalmer]

I guess I should add I tried to do this using the PIMD package.

[kevindd992002]

@JKnott said in How to make multicast work within the OpenVPN tunnel network?:

@kevindd992002

Multicasts don't pass through routers, unless specifically enabled. When you go from your LAN to a VPN, you're passing through a router.

The client to server multicast packets are generated from the VPN network adapter itself (I did a packet capture). So although the packets from LAN to VPN technically passes through the client's gateway (router), they get to the point where they they try to go from the client VPN adapater's IP to the VPN gateway (VPN server).

What gives?

[JKnott]

@kevindd992002 said in How to make multicast work within the OpenVPN tunnel network?:

The client to server multicast packets are generated from the VPN network adapter itself (I did a packet capture).

Did you check the IP or MAC address? I've never heard of an adapter doing anything like that. Generally the various services advertise themselves and the client looks for that. For example, I have a Yamaha A/V receiver, which I can connect to with an Android app. The receiver sends out multicasts, which the Android app on my phone or tablet receive. If you checked the IP address, you'll see the IP address of device that sent the multicast. If you check the MAC, you'll only know that it came through that NIC.

Here's some info on UPnP.

[kevindd992002]

@JKnott said in How to make multicast work within the OpenVPN tunnel network?:

@kevindd992002 said in How to make multicast work within the OpenVPN tunnel network?:

The client to server multicast packets are generated from the VPN network adapter itself (I did a packet capture).

Did you check the IP or MAC address? I've never heard of an adapter doing anything like that. Generally the various services advertise themselves and the client looks for that. For example, I have a Yamaha A/V receiver, which I can connect to with an Android app. The receiver sends out multicasts, which the Android app on my phone or tablet receive. If you checked the IP address, you'll see the IP address of device that sent the multicast. If you check the MAC, you'll only know that it came through that NIC.

Here's some info on UPnP.

Yes, yes, I did confirm that it was the IP address of the client and the destination is a multicast address at port 1900. This happens even without the VPN too. I have to double check the MAC though.

The miniupnpd author himself confirmed that that is the problem, see my post here:

https://github.com/miniupnp/miniupnp/issues/444

I know that the pfsense UPnp service does a broadcast notify which my client pc receives. What'a missing is an m-search broadcast by the client. The client does it but the server never receives it.

[kevindd992002]

Here are some packet capture examples that explains what I'm trying to say:

1. Without any OpenVPN connection on the client:

Packet capture from pfsense LAN interface: https://controlc.com/b34e1351
Packet capture from client LAN interface: https://controlc.com/38f2ed2a

192.168.10.1 -> pfsense LAN interace IP
192.168.10.13 -> client LAN interface IP

• You can clearly see the upnp NOTIFY method packets flowing from pfsense to the client.
• You can also clearly see that the upnp M-SEARCH method packets flowing from the client to pfsense.
• Everything works here. Even with the upnpc test client:

C:\Users\Charmaine\Downloads\win32-miniupnpc-2.1>upnpc-static.exe -s
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.10.1:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.10.1:2189/ctl/IPConn
Local LAN ip address : 192.168.10.13
Connection Type : IP_Routed
Status : Connected, uptime=78271s, LastConnectionError : ERROR_NONE
  Time started : Mon May 11 02:34:58 2020
MaxBitRateDown : 1000000000 bps (1000.0 Mbps)   MaxBitRateUp 1000000000 bps (1000.0 Mbps)
ExternalIPAddress = <External IP>
Bytes:   Sent: 3861912465       Recv: 3058787218
Packets: Sent: 337795450        Recv: 497591141

2. With the OpenVPN connection turned on in the client and all traffic redirected to the openvpn gateway IP

Packet capture from pfsense OpenVPN interface: https://controlc.com/09170dfa
Packet capture from client OpenVPN interface: https://controlc.com/afbbe912 (I did check that the frames source MAC address for these are of the OpenVPN client interface)

10.0.1.1 -> pfsense OpenVPN interaface IP
10.0.1.101 -> client OpenVPN interface IP

• You can clearly see the upnp NOTIFY method packets flowing from pfsense openvpn server to the client openvpn interface.
• You can also clearly see that the upnp M-SEARCH method packets are being generated by the client on the openvpn interface but are not being received by the pfsense openvpn server. THIS IS THE PROBLEM!
• As expected, the upnpc test client fails:

C:\Users\Charmaine\Downloads\win32-miniupnpc-2.1>upnpc-static.exe -s
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
No IGD UPnP Device found on the network !

@JKnott , I hope these clear things up and that I was able to explain the issue fully.

[JKnott]

@kevindd992002

It would have been better to post the actual capture file, so that it can be examined in Wireshark. Also, I don't like having to go to a site where I'm told to turn off my ad blocker. It's very easy to attach files to this site.

[kevindd992002]

I had to find alertnatives to pastebin because it is currently down. Here are the packet capture files:

Packet capture from pfsense LAN interface: https://www.dropbox.com/s/f92vxyd6muuecas/packetcapture_server_1.cap?dl=0
Packet capture from client LAN interface: packetcapture_client_1.pcapng

Packet capture from pfsense OpenVPN interface: https://www.dropbox.com/s/u8mh6vg24hw77g7/packetcapture_server_2.cap?dl=0
Packet capture from client OpenVPN interface: packetcapture_client_2.pcapng

The .cap files are not supported for direct attachment to this site.

[JKnott]

@kevindd992002

I see both IPv4 & IPv6 multicast with stuff like printers, multiDNS, some Chrome device looking for something etc.. What service are you having issues with? The things I see won't normally be passed by a router and also are not coming from your VPN interface. For example, I see at least 2 different IPv4 source addresses. I can see something from FreeBSD at 10.0.1.1, which I assume is your pfSense box and I also see an IPv6 link local address for an MDNS request, which happens to have the same MAC address as that FreeBSD box.

So, what are you seeing on the LAN side, but not elsewhere? Please only attach the files here and not use some external site, as I won't go them.

Also, you don't need pastebin, Dropbox or anything other than attaching the files here. I had no problem reading the files you posted here, but Dropbox wants me to download the file first etc.. When you capture a file with Packet Capture, you save it to your computer and then click on the upload file button, above at right.

[kevindd992002]

@JKnott said in How to make multicast work within the OpenVPN tunnel network?:

@kevindd992002

I see both IPv4 & IPv6 multicast with stuff like printers, multiDNS, some Chrome device looking for something etc.. What service are you having issues with? The things I see won't normally be passed by a router and also are not coming from your VPN interface. For example, I see at least 2 different IPv4 source addresses. I can see something from FreeBSD at 10.0.1.1, which I assume is your pfSense box and I also see an IPv6 link local address for an MDNS request, which happens to have the same MAC address as that FreeBSD box.

So, what are you seeing on the LAN side, but not elsewhere? Please only attach the files here and not use some external site, as I won't go them.

Also, you don't need pastebin, Dropbox or anything other than attaching the files here. I had no problem reading the files you posted here, but Dropbox wants me to download the file first etc.. When you capture a file with Packet Capture, you save it to your computer and then click on the upload file button, above at right.

Just concentrate on the IP addresses that I posted on my earlier post. Like I said, I don't have issues with my other devices in the LAN. I just showed you that there is indeed multicast traffic coming from both sides (pfsense server and client) whether they are using the VPN connection or not. Specifically, concentrate on source IP addresses 10.0.1.1 (pfsense openvpn interface) and 10.0.1.101 (client openvpn interface).

So on the LAN side, I see packets from the client (with source IP: 192.168.10.13 and destination socket: 239.255.255.250:1900) reaching the LAN interface in pfsense. But with openvpn, I see these same "M-SEARCH" packets (src ip: 10.0.1.101 and destination socket: 239.255.255.250:1900) being generated from the client side but not reaching the openvpn interface. Did you read the github link I sent you? Thomas (author of upnp) says it there too.

Not sure what kind of proof you want from me when I said that .cap files are not supported for direct attachment to this site and is the reason why I used dropbox. Here's a screenshot of the error:

So there's no other way for me to upload those .cap files that I downloaded from pfsense other than what I have, dropbox.

[kevindd992002]

If it helps, apply this wireshark filter on packetcapture_client_1:

(ip.src == 192.168.10.1 || ip.src == 192.168.10.13) and ip.dst == 239.255.255.250

And this filter on packetcapture_client_2:

(ip.src == 10.0.1.1 || ip.src == 10.0.1.101) and ip.dst == 239.255.255.250

[kevindd992002]

You can also use this as a miniupnp test client: https://github.com/miniupnp/miniupnp/releases/download/miniupnpc_2_1/win32-miniupnpc-2.1.zip

Just run upnp-static.exe -s in the cmd prompt to see if upnp is working. This test client also generates M-SEARCH method SSDP packets (which again are not reaching the openpnv server interface).

[JKnott]

@kevindd992002 said in How to make multicast work within the OpenVPN tunnel network?:

destination socket: 10.0.1.1:1900

That's not a multicast address, nor is 192.168.10.1:1900. Mulitcast destination addresses are in the 224. to 239. range on IPv4 and ffxx: on IPv6.

As for the file extension, this site can be fussy. A while ago we had to get the native Packet Capture PCAP files accepted. A work around is to rename the extension to pcap or pcapng.

[kevindd992002]

@JKnott said in How to make multicast work within the OpenVPN tunnel network?:

@kevindd992002 said in How to make multicast work within the OpenVPN tunnel network?:

destination socket: 10.0.1.1:1900

That's not a multicast address, nor is 192.168.10.1:1900. Mulitcast destination addresses are in the 224. to 239. range on IPv4 and ffxx: on IPv6.

As for the file extension, this site can be fussy. A while ago we had to get the native Packet Capture PCAP files accepted. A work around is to rename the extension to pcap or pcapng.

I'm sorry, it was 3AM when I posted my last reply earlier and that was a typo. I edited my last post. It's supposed to read:

(src IP: 192.168.10.13 and destination socket: 239.255.255.250:1900)
(src ip: 10.0.1.101 and destination socket: 239.255.255.250:1900)

And this coincides with my post regarding the Wireshark filters.

As for the packet capture files, here you go:

1. Without OpenVPN:

Packet capture from pfsense LAN interface: packetcapture_server_1.pcap
Packet capture from client LAN interface: packetcapture_client_1.pcapng

• Server (192.168.10.1) sends multicast packet (NOTIFY method) to 239.255.255.250 and client receives it
• Client (192.168.10.13) sends multicast packet (M-SEARCH method) to 239.255.255.250 and server receives it

2. With OpenVPN:

Packet capture from pfsense OpenVPN interface: packetcapture_server_2.pcap
Packet capture from client OpenVPN interface: packetcapture_client_2.pcapng

• Server (10.0.1.1) sends multicast packet (NOTIFY method) to 239.255.255.250 and client receives it
• Client (10.0.1.101) sends multicast packet (M-SEARCH method) to 239.255.255.250 and server DOES NOT RECEIVE it

If it helps, my OpenVPN remote access server settings are posted here: https://forum.netgate.com/post/911141

[JKnott]

@kevindd992002

I just did a search and came across this: How to get multicast to work with OpenVPN clients?

See the comments about using an IGMP proxy.

[kevindd992002]

@JKnott said in How to make multicast work within the OpenVPN tunnel network?:

@kevindd992002

I just did a search and came across this: How to get multicast to work with OpenVPN clients?

See the comments about using an IGMP proxy.

See my first post. IGMP proxies are not needed because I don't want to make the multicast traffic to LAN behind the pfsense openvpn server. I only need the multicast traffic from the client to reach the openvpn server interface which are both on the same network (the tunnel network).

[kevindd992002]

@JKnott any other ideas?