UPnP Port Forwarding with PFsense

stephenw10

Ok before anything else. That table of upnp entries is almost certainly showing that your NAS has opened firewall holes for all those services out on to the internet. You may not want this! ;)

Steve

Edit: The UPNP daemon in pfSense supports only the Internet Gateway Device part of the specification not anything to do with DLNA. See: http://miniupnp.free.fr/

kcleveland

Good call - I just disabled it while we try to figure this out ;)

stephenw10

Hmm, this is still interesting! ;D

The fact that your two devices are on different subnets should not matter. Once the client has found the server pfSense will route traffic between the two subnets quite happily, as long as you have firewall rules to allow it.

The problem is the discovery process:
http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol

It should be possible to allow this multicast address to reach both subnets, I would have thought. However I am not at all familiar with multicast.

Steve

kcleveland

Okay I found a similar thread in the forum by searching, but it still didn't solve my problem:

http://forum.pfsense.org/index.php/topic,36832.0.html

His problem was essentially the same as mine, he needed to access a upnp server (like my NAS) that resided in a different VLAN than he was in (and does not have the ability to punch in the IP of the NAS into the app - it has to "discover" it).

Apparently IGMP Proxy solved it for him, but I enabled it, with VLAN10 upstream and VLAN20 downstream, and I still cannot see the NAS - do I need a multicast rule or something else? Would someone be able to step me through this?

I have to believe there is someone out there who knows how to do this ???

Edit: This time I posted while you were typing lol! So it looks like multicast may be the issue here!

stephenw10

Ah! Yes I see.
What does your IGMP proxy rule look like?
What firewall rule do you have on each VLAN?

Steve

Edit:

You also need a firewall rule on the downstream side (typically LAN) that matches/passes this traffic which has the advanced option checked to allow packets with IP Options.

So edit the rules on each VLAN and check this advanced option.

kcleveland

The firewall rules for the VLAN's look like this (this is VLAN10 but each VLAN is the same except for the IP i.e. VLAN20 is 192.168.20.0/24 instead - you get the drift):

My LAN firewall rules are:

My IGMP rule looks like this:

Does this look right? Should I enable the advanced "packet with IP options" feature on LAN firewall rule for the VLAN 20 (192.168.20.0/24) since it is set as the downstream in the IGMP Proxy rule? Or should it be on the actual VLAN 20 firewall rules tab?

stephenw10

If this doesn't work, but I think it will, it may be possible to use the miniSSDPd daemon to proxy upnp requests and announcements across subnets. It doesn't mention that in it's documentation but it seems as though it should be possible. Hmm.

Steve

stephenw10

You should have the 'allow packets with IP options' setting checked on the firewall rules on each VLAN.

You shouldn't have the LAN interface at all! ;)
It is presumably still assigned the ethernet card directly which is bad. That can lead to VLAN tagged and non-tagged traffic on the same interface which can cause problems. When you have VLANs on a NIC the NIC itself should be unassigned.

If it's not causing problems though I'd leave it for now and rearrange stuff later.

Steve

kcleveland

I enabled the advanced ip options on every firewall rule (except the wan of course) - but still no luck :(

I wonder if I need a specific rule for the ssdp multicast address (239.255.255.250)?

Any other ideas? I wonder how that other guy got it working.

stephenw10

Are you seeing anything in the firewall logs?
You may want to try swapping the upstream and downstream interfaces.
Is this the same wifi access point that previously worked fine when everything was on the same subnet?
You could change the source address in your firewall rules to 'any'.

Sometimes you have to clear the states or reboot the box after large changes for everything to come up correctly.
Diagnostics: States: Reset states:

Steve

kcleveland

I went ahead and changed the source address on the rules to any, still no luck.

Seeing a lot in the logs, looking like it could be blocking it even though the rules are wide open:

The logs may indicate what you mentioned in that it may need a reboot - it is saying em0 is still 192.168.0.1 and I changed it to 192.168.5.1 several hours ago.

It is the same access point, and my PC is on it right now - I can ping all VLAN's and other clients on the VLAN's so I'm confident everything is good there - I just think were missing some mundane detail when it comes to the multicasting.

Edit: I'm going to reboot pfsense and see what happens

kcleveland

still no luck after a reboot, but the logs are starting to look cleaner.

I'm officially stuck. This is a bummer!

Can anyone help Steve and I out here?

stephenw10

@kcleveland:

it is saying em0 is still 192.168.0.1 and I changed it to 192.168.5.1 several hours ago.

No it isn't. It's saying that packets are arriving on the interface em0 from 192.168.0.1.
Possibly because your switch is sending them there. Why is your switch sending untagged packets to em0?
That's a good point though. Is your switch handling multicast correctly?

This could be one of those problematic situations I mentioned with tagged and untagged traffic on the same interface.

Steve

marcelloc

Just few question to clarify.

Do your switch support vlans?
Did you configured and applied this vlan setup on switch?

kcleveland

Good point - I fixed that by enabling the "discard all untagged frames" feature on my switch for the trunk port to pfsense - should be good there now.

Marcelloc- yes, it does. i have them setup and working, and can ping between all of the vlans and clients within them. I believe everything is good there - Like I said it all works well, I just need to access the NAS in VLAN20 from the VLAN10 wireless network via apps that "discover" the upnp on the NAS.

I think that i need to take another look at the switches multicast config and get back in the morning.

Thanks again for all of the excellent help!

kcleveland

Ok so I finally had some time to get back to this, and at this point I'm pretty sure everything is setup correctly for multicast (pfsense and the switch).

However, it still doesn't work.

In my switch I see an active querier on each VLAN (the IGMP querier being the L3 device, in this case pfsense), on the port that PFsense is at:

But it still won't flood multicast traffic between the subnets.

I'm all out of ideas at this point.

Surely someone out there has had to enable multicast routing between subnets on pfsense - can somebody PLEASE enlighten me on how to do this? I'm struggling here :'(

Thanks!

trunix

kcleveland - realize it's been awhile, but did you ever get your multicast issues sorted? I worked on a similar multicast setup, and in addition to enabling the advanced firewall rule to allow packets with IP options to pass, we had to install the Avahi package to get two devices in separate subnets communicating successfully.

Might be worth a try if your wife hasn't already thrown her iPhone at you. Or perhaps because she has. Ensure Avahi is bound to the two interfaces/VLANs that the phone & NAS are a part of if you want to give this a try. That's the only Avahi settings I think were needed – it was pretty easy to get running.

stephenw10

So you are suggesting that the iphone may be using an Apple protocol for device discovery rather than DLNA (IGMP multicast)?
Wouldn't that imply it couldn't find DLNA devices? :-
Good suggestion though.

Steve

Edit: Actually the iphone app. in question is specifically upnp/dlna. You can see in this post the multicast traffic on port 1900 that is part of the SSDP protocol.
Still worth trying though. ;)

trunix

I think it'd be a worth a shot to see if it works. I suspect there may be some overlap in many of the UPnP/Zeroconf protocols. I agree that it's a little ironic that we're discussing SSDP in conjunction with an Apple product, as I'd expect to see this protocol more in Microsoft-related gear. I suppose it's been around long that it's an accepted standard.

And while I'm on the topic, I'll personally add that I don't think DLNA is deserving of the title of "standard" or "protocol" or anything that even hints at interoperability. I think DLNA abuses the term "standard" the same way the financial community abuses the term "security" – misleading to the point of outright lying. I had to plow through too many software transcoders for a client's video project searching for something to work with their available Sony hardware. A lesson in frustration as all their hardware & all the available software I came across claimed to support the identical version of DLNA. I found Conceiva's Mezzmo the best if anyone cares. I'll stop ranting now since it's not pertinent to the OP's topic & this thread.