pfSense

Duplicate of #1835

The daemon appears to have IPv6 active now and it sees an IPv6 SSDP message but it doesn't like it for some reason. May be the setup I'm using (not static IP, track6 LAN), claims the sending system isn't in LAN

Nov 13 14:50:54     miniupnpd[70037]: write: Invalid argument
Nov 13 14:50:54     miniupnpd[70037]: SSDP packet sender [2001:db8:1:ee30:2dde:9d99:912d:3acb]:35998 not from a LAN, ignoring

Though that is in the same /64 as the LAN interface miniupnpd is set to listen upon so I'm not sure what it's complaining about. Needs more testing.

Could it be trying to prefix-match against the link-local address?

It's possible. I can't find a local client program that claims IPv6 UPnP support to test with aside from upnpc and it doesn't select the link-local when sending, and does not have a way to nudge it that I can see. I even tried backing off a client to have link-local only and then send SSDP but miniupnpd didn't show any sign it saw the packets.

May be the fault of the client here -- we need a lead on a proper piece of client software that will actually send IPv6 UPnP how the daemon expects to see it.

There's this but it's commercial stuff, though they offer some trial:

http://www.qacafe.com/products/cdrouter/
http://support.qacafe.com/knowledge-base/upnp-testing-guide/#upnp-over-ipv6

Looks like a bug in miniupnpd to me: https://github.com/miniupnp/miniupnp/issues/160

Fixes for this and a few other BSD-related issues have been accepted upstream. They're included in the most recent tarball on the miniupnp download page (miniupnpd-1.9.20151118.tar.gz), but I don't believe the FreeBSD port has been updated yet.

Filed PR 204694 to update the FreeBSD port.

Behavior is slightly different with upnpc now, though it's still not working.

Server log is the same saying the client IP address is no on a LAN, client now shows that it found a UPnP device on the network but then says "No valid UPNP Internet Gateway Device found" after listing the server.

Strange, works fine here (albeit on 2.2.5):

$ upnpc -m lagg0 -S
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2015 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://172.20.0.1:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://172.20.0.1:2189/ctl/IPConn
Local LAN ip address : 172.20.3.3
FirewallEnabled: 1 & Inbound Pinhole Allowed: 1
GetFirewallStatus:
   Firewall Enabled: Yes
   Inbound Pinhole Allowed: Yes
Bytes:   Sent: 1765229673    Recv: 1856554871
Packets: Sent: 52641488    Recv: 103007220
$ upnpc -6 -m lagg0 -S
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2015 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
setsockopt(IP_MULTICAST_TTL,...): Invalid argument
List of UPNP devices found on the network :
 desc: http://[2601:646:x:x:x:x:x:x]:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://[2601:646:x:x:x:x:x:x]:2189/ctl/IPConn
Local LAN ip address : 2601:646:x:x:x:x:x:x
FirewallEnabled: 1 & Inbound Pinhole Allowed: 1
GetFirewallStatus:
   Firewall Enabled: Yes
   Inbound Pinhole Allowed: Yes
Bytes:   Sent: 1766304397    Recv: 1863805814
Packets: Sent: 52649204    Recv: 103017871

Can you manually restart miniupnpd in foreground mode (-d)? That gives a bit more info beyond what's in the log.