Upnp/nat stopped working with recent update.
-
I'm getting these errors in my upnp logs, and port forwarding is not working either
May 28 13:07:08 miniupnpd[31608]: SSDP packet sender 172.16.3.1:40811 not from a LAN, ignoring
May 28 13:07:18 miniupnpd[31608]: SSDP packet sender 172.16.3.1:2255 not from a LAN, ignoring
May 28 13:07:18 miniupnpd[31608]: SSDP packet sender 172.16.3.1:21684 not from a LAN, ignoring
May 28 13:07:18 miniupnpd[31608]: HTTP peer 172.16.3.1:64163 is not from a LAN, closing the connection
-
Well, is 172.16.3.1 actually inside your LAN subnet?
EDIT: Or, put another way, if you relax your allow rule and/or disable the "default deny" rule, does it work then?
-
I disabled the default deny rule, it is still rejecting all requests.
I then decided to do a fresh install of pfsense, I have a very basic setup on this particular network. Only changes I have made so far are as follows
1. change lan from 192.168.0.1/24 to 172.16.0.1/16
2. change wan monitoring IP
3. Enable DHCP, set up static entries for known systems. these are outside of default pool.
4. enable upnp, default deny all, add same allow rule as listed previously.
5. Restart upnpd
6. clear state table
7. rearrange dashboard to preferred layout
8. create a new user, and disable default admin user.Went and tested again, port is still blocked, checked logs, same error.
I've verified this mac/IP is being recognized as LAN interface in the ARP tables. Just in case I had a cable installed incorrectly. Where else would this be defined?
-
These were taken after preforming a fresh install and above mentioned changes
-
Just taking a stab at it, but your allow rule doesn't have the CDIR after the IP. You only have "172.16.0.0" instead of "172.16.0.0/24"
-
Just taking a stab at it, but your allow rule doesn't have the CDIR after the IP. You only have "172.16.0.0" instead of "172.16.0.0/24"
Thanks, I set the rule to "allow 0-65535 172.16.3.1/32 0-65535" still with no luck.
-
After a day of researching, and tons of testing, it appears that this was an issue back in 1.x which has made its way back into the system somehow. It was fixed in 2.0 where enabling upnp would auto create a filter to allow multicast traffic. Now it is denying any multicast traffic and stating it is not part of LAN.
Next step is to find a way to allow this traffic on the LAN. Anyone have ideas?
EDIT: Another thing I noticed int he logs. miniupnpd[98059]: HTTP listening on port 2189. Why isn't this port 1900?
EDIT2: More entried I happened to find in the logs, likely irrelevant, but seeing as I know nothing about IPv6, i'm including anyways.
May 28 21:49:44 radvd[38020]: attempting to reread config file
May 28 21:49:44 radvd[38020]: no auto-selected prefix on interface em0, disabling advertisements
May 28 21:49:44 radvd[38020]: resuming normal operationWhere em0 is my LAN interface
-
Was this going from 2.1.2 to 2.1.3?
Have a read through this thread: https://forum.pfsense.org/index.php?topic=76538.0
Though razzfazz's patch may not be the issue here it's easy to revert the change for a test.Steve
-
Awesome find.
If I am understanding this correctly, it is binding to my (non existant?) ipv6 address? Hence any other traffic on the lAN interface is ignored, including ipv4 traffic.
Simply changing it to bind to interface or ipv4 address will resolve the issue? I will check later and post results.
-
Have a read through this thread: https://forum.pfsense.org/index.php?topic=76538.0
Steve
If you're on 2.1.3, you can use the "System Patches" package to either either revert the original commit, or to apply my fix until a new build is released.
I went in and changed the two files in https://github.com/pfsense/pfsense/commit/d973a602abeab78803fce467198c571ba25ec0cb
Everything is working perfectly now.
Thanks again everyone. This case can be closed and marked as solved. Remember to make note of this if others come in with the same issue.
