Forwarding SSDP/UPnP through L3 switch VLANs

[Blue)(Fusion]

I have a Brocade ICX 6610 as my core L3 switch on VLAN routing duty. All internet-bound traffic is routed through OPNSense. UPnP is becoming a requirement for the amount of game systems I and my house-mates have.

Is there any way to get SSDP multicast traffic from one VLAN to another on Fastiron 8.0.30? I've been reading docs for the better part of 8 hours and tried what I found but nothing conclusive and, so far, nothing worked.

SSH@sw1(config)#show run int ve 2315
interface ve 2315
port-name GUEST
ip address 172.23.15.1 255.255.255.0
ip pim-sparse passive
ip helper-address 1 172.23.1.2
ip helper-address 2 172.23.1.3
ip helper-address 5 172.23.9.2
ip ospf area 0
ipv6 address 2603:1234:4567:6b15::1/64
ipv6 address fdc6:389a:3739:8215::1/64
ipv6 enable
ipv6 ospf area 0
!

SSH@sw1(config)#show run int ve 2309
interface ve 2309
port-name LANXFER
ip address 172.23.9.1 255.255.255.252
ip pim-sparse passive
ip ospf area 0
ipv6 address 2603:1234:4567:6b09::1/64
ipv6 address fdc6:389a:3739:8209::1/64
ipv6 enable
ipv6 ospf area 0
ipv6 nd suppress-ra

SSH@sw1(config)#show run | in multicast
ip multicast passive
ip multicast version 3
ip multicast-routing

SSH@sw1(config)#show run | in igmp
ip igmp version 3

 

[DavidWJohnston]

I think what may be happening is the packets have TTL=1 - Which means routers will drop them even if PIM is enabled to route multicast traffic. Can you do a Wireshark capture and check the TTL? If it is being dropped, you should see an ICMP time exceeded response.

Maybe you could set up a Linux VM to intercept, mangle the TTL value, and forward it. Once pfSense opens the port forward the packets should flow. This might work but would be a pain.

Honestly I don't have a good answer to this question - If someone else does, I am interested as well.

 

[Blue)(Fusion]

The TTL was my first thought, too. I installed miniupnpc on a Linux laptop and a FreeBSD PC on the same VLAN.

Monitoring the outbound traffic when I run upnpc -r <somerandomport> I see a TTL of 2 in the SSDP packets. Interestingly, I do not see the packets on the opposite device on the same VLAN - perhaps this is because the multicast address has to be registered somehow with the router/IGMP?

I should also note that I set the interfaces to promiscuous.

 

[Blue)(Fusion]

FWIW, here is the packet capture from the device sending out the UPnP request:

tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:43:53.076757 IP (tos 0x0, ttl 2, id 5906, offset 0, flags [none], proto UDP (17), length 165
)
172.23.10.15.27055 > 239.255.255.250.ssdp: UDP, length 137
18:43:55.076838 IP (tos 0x0, ttl 2, id 5909, offset 0, flags [none], proto UDP (17), length 160
)
172.23.10.15.27055 > 239.255.255.250.ssdp: UDP, length 132
18:43:57.077861 IP (tos 0x0, ttl 2, id 26915, offset 0, flags [none], proto UDP (17), length 16
1)
172.23.10.15.27055 > 239.255.255.250.ssdp: UDP, length 133
18:43:59.079835 IP (tos 0x0, ttl 2, id 5910, offset 0, flags [none], proto UDP (17), length 129
)
172.23.10.15.27055 > 239.255.255.250.ssdp: UDP, length 101

 

[DavidWJohnston]

Are those packets the ones generated by the game, or by miniupnpc? The TTL could be different. To see what's really going on it'll be necessary to packet capture the game and see any ICMP responses.

The switch will snoop the IGMP memberships and only forward packets to member ports.

I wonder if you could also add your gaming VLAN as an interface to your pfSense - Not to route through, just to speak upnp.

 

[Blue)(Fusion]

Are those packets the ones generated by the game, or by miniupnpc? The TTL could be different. To see what's really going on it'll be necessary to packet capture the game and see any ICMP responses.

The packet capture is from the laptop running miniupnpc which I am using to emulate a gaming console requesting UPnP. I figure I won't be getting a console to work before I get this to work and I can control this much easier.

I wonder if you could also add your gaming VLAN as an interface to your pfSense - Not to route through, just to speak upnp.

I thought about doing this, too, but was hoping to avoid it. The main reason I still want it routed on the L3 switch is I have a Lancache server on a different subnet and I don't think my virtualized OPNsense is going to be very effective at routing that traffic during my LAN Parties.

 

[sic0048]

I thought about doing this, too, but was hoping to avoid it. The main reason I still want it routed on the L3 switch is I have a Lancache server on a different subnet and I don't think my virtualized OPNsense is going to be very effective at routing that traffic during my LAN Parties.

There is more than one way to "skin that cat". Obviously there is nothing wrong with continuing to troubleshoot the problem and see if you can't get it working. This is probably what most people on this forum would say is the "correct" way of handling the routing.

I'm not a professional IT person, so I tend to implement what is easiest in my home network rather than what is considered industry standard practices for a large network environment (because I don't have one). I'll simply say that adding another NIC to your lanserver and putting it in your gaming VLAN would also be an easy way to fix your issue. You can set up the gaming VLAN in OPNsense and only do L2 on the switch. Traffic on the same VLAN will be handled at this L2 level and not have to transverse the firewall, so it shouldn't be a bottle neck during LAN parties.