UPNP?
-
Issue still persists. This is getting frustrating because the only reason I have this firewall installed to begin with is to protect the seedbox, not to restrict legitimate clients!
Latest transmission client tested on 2 separate LAN PC's with UPNP enabled.
Still both report ports closed and canyouseeme.org reports them as closed as well.This worked before with no issues and changes other than pfsense snapshot upgrades… one of the snapshots in the past while has broken this.
The only changes to a default pfsense install are selecting "6to4 tunnel" for IPv6 on the WAN, and "track interface" for ipv6 on the LAN. Everything else is set at installer default.
Would like to think that with 120+ ppl viewing this that at least one of them can either replicate the same issue or make a guess as to what has changed to affect this...
-
Well I was able to duplicate the issue..
I normally don't use upnp - but had set it up for my sons xbox limiting it to just his xbox IP..
So I edited the allow rules to allow my test box at 192.168.1.210 to use UPnP.. And so I create a rule via UPnP from the test box for couple different things rdp 3389, didn't work and brought up webserver on 8080 and didn't work
but according to the status in pfsense upnp had created the rule - see attached, just showing the 8080 test here. But firewall log shows these connections blocked? See second attached
running
2.1-BETA1 (i386)
built on Sun Feb 10 22:04:57 EST 2013
FreeBSD 8.3-RELEASE-p5With gitsync of earlier this morning with the dyndns widget fix (other thread)
-
Thanks for taking the time to verify and document this issue John, Was hopeing that we could do this to prove that there indeed is a problem so that it does not go ignored as user error as my first post did…
Let's hope it gets priority over grammatical corrections in one of the upcoming snapshots ;) -
No problem I don't have a use for UPnP myself, not really a fan - I had set it up for my sons xbox more just for reason to play with it and the rules of limiting UPnP access to specific devices for any possible future need (unlikely)
I normally would just setup nat for his specific ports for his xbox.. But figure this would give some exp with UPnP - not a fan ;)
But yeah if its going to be included as an option - it should work ;) Which from my testing is not currently.
-
There were some recent pf changes so I may need to rebuild the UPnP daemon again.
I just did it now, try the next new snap (not up yet, will be dated later today) and see if it works.
-
There were some recent pf changes so I may need to rebuild the UPnP daemon again.
I just did it now, try the next new snap (not up yet, will be dated later today) and see if it works.
Just ran up:
2.1-BETA1 (amd64)
built on Thu Feb 14 16:30:41 EST 2013There is now an additional entry on the table for Teredo that was not there in the last snapshot , however the results are the same as described previously. Both App and external client report closed port :-\
-
Any errors at all in the system log?
-
Ok running
2.1-BETA1 (i386)
built on Fri Feb 15 04:06:54 EST 2013
FreeBSD 8.3-RELEASE-p5Gitsync of couple of minutes ago.. Still seeing the same issue, rules look like there in place via upnp status, but blocked in the firewall. I am not seeing anything in the system log about it. Or any other odd errors.
BTW that Teredo is not related – thats just that you have not turned that off on your clients, unless you have some reason to be using it?? I for sure can not see one if your running ipv6 on your wan?
-
Anything listed in "pfctl -sn -a miniupnpd" and "pfctl -sr -a miniupnpd"?
-
Anything listed in "pfctl -sn -a miniupnpd" and "pfctl -sr -a miniupnpd"?
2.1-BETA1 (amd64)
built on Fri Feb 15 04:33:17 EST 2013
FreeBSD 8.3-RELEASE-p5
Second IP (192.168.1.110) is a user with skype on his iphone, 192.168.1.105 is the seedbox with UPNP port closed issues. -
Is igb0 actually your WAN/default route?
-
Is igb0 actually your WAN/default route?
Yep, igb0 is hooked to the cable router (WAN). Its a simple setup, Intel Gigabit ET2 Quad port server adapter (only using 2 ports -.-) in a HP Proiliant DL380 server.
igb0 for WAN and igb1 for LAN. No errors show in system log at all.
As i noted in an earlier post, The only changes to a default pfsense install are selecting "6to4 tunnel" for IPv6 on the WAN, and "track interface" for ipv6 on the LAN. Everything else is set at installer default. -
Hi
I can confirm this issue. The "transmission" torrent application is a good tester because it both asks UPnP to open the port, then has it probed from the outside to confirm that the port has actually been opened.
[2.1-BETA1][root@xxx.xxx.xxx]/root(1): pfctl -sn -a miniupnpd rdr log quick on vr0 inet proto tcp from any to any port = 63839 keep state label "Transmission at 63839" rtable 0 -> 192.168.1.120 port 63839 rdr log quick on vr0 inet proto udp from any to any port = 63839 keep state label "Transmission at 63839" rtable 0 -> 192.168.1.120 port 63839 [2.1-BETA1][root@xxx.xxx.xxx]/root(2): pfctl -sr -a miniupnpd pass in log quick on vr0 inet proto tcp from any to any port = 63839 flags S/SA keep state label "Transmission at 63839" rtable 0 pass in log quick on vr0 inet proto udp from any to any port = 63839 flags S/SA keep state label "Transmission at 63839" rtable 0The best way I can describe the issue is that miniupnpd claims to have performed the requested operation, but didn't actually do it. Or, perhaps pf is now behaving differently (ignoring?) miniupnpd's request.
My version with issue: 2.1-BETA1 (i386) built on Fri Feb 15 15:43:49 EST 2013
Reverting back to: 2.1-BETA1 (i386) built on Thu Jan 24 19:53:22 EST 2013
…resolves the issue
Same commands in the earlier snapshot (that works):
[2.1-BETA1][root@xxx.xxx.xxx]/root(1): pfctl -sn -a miniupnpd rdr log quick on vr0 inet proto tcp from any to any port = 59130 keep state label "Transmission at 59130" rtable 0 -> 192.168.1.120 port 59130 rdr log quick on vr0 inet proto udp from any to any port = 59130 keep state label "Transmission at 59130" rtable 0 -> 192.168.1.120 port 59130 [2.1-BETA1][root@xxx.xxx.xxx]/root(2): pfctl -sr -a miniupnpd pass in log quick on vr0 inet proto tcp from any to any port = 59130 flags S/SA keep state label "Transmission at 59130" rtable 0 pass in log quick on vr0 inet proto udp from any to any port = 59130 flags S/SA keep state label "Transmission at 59130" rtable 0NOTE: Port numbers are different because Transmission is assigning random port numbers each time I test.
I'm happy to run further tests. Let me know what you want done.
Thanks
-
I updated to the latest snapshot (yesterday's) and I have no problem on i386. uTorrent opens a port and the port test succeeds.
If the rules are there, it should be working. When UPnP was really broken, there were no rules added there.
-
Still not working - showing it blocked in the firewall
Canyouseeme saying closed.. But clearly the firewall is blocking it - even thouse the pfctl shows rules should be there?
running
2.1-BETA1 (i386)
built on Sat Feb 16 10:53:05 EST 2013
FreeBSD 8.3-RELEASE-p5[2.1-BETA1][root@pfsense.local.lan]/root(1): pfctl -sn -a miniupnpd
rdr log quick on em1 inet proto tcp from any to any port = 3389 keep state label "test" rtable 0 -> 192.168.1.210 port 3389
[2.1-BETA1][root@pfsense.local.lan]/root(2): pfctl -sr -a miniupnpd
pass in log quick on em1 inet proto tcp from any to any port = 3389 flags S/SA keep state label "test" rtable 0yes em1 is my wan
WAN (wan) -> em1 -> v4/DHCP4: 24.13.snipped/21
v6/DHCP6: 2001:558:6033:12c:snippedf:a3d3/128
-
Installed "2.1-BETA1 (amd64) built on Sat Feb 16 10:55:42 EST 2013"
Still no go on upnp opening ports.tested with:
www.grc.com (shields up!)
www.canyouseeme.org
and
utorrent internal testing option…$ pfctl -sn -a miniupnpd rdr log quick on em0 inet proto udp from any to any port = 24927 keep state label "Skype UDP at 192.168.0.50:24927 (2238)" rtable 0 -> 192.168.0.50 port 24927 rdr log quick on em0 inet proto tcp from any to any port = 24927 keep state label "Skype TCP at 192.168.0.50:24927 (2238)" rtable 0 -> 192.168.0.50 port 24927$ pfctl -sr -a miniupnpd pass in log quick on em0 inet proto udp from any to any port = 24927 flags S/SA keep state label "Skype UDP at 192.168.0.50:24927 (2238)" rtable 0 pass in log quick on em0 inet proto tcp from any to any port = 24927 flags S/SA keep state label "Skype TCP at 192.168.0.50:24927 (2238)" rtable 0em0 is my WAN
-
Still not working - showing it blocked in the firewall
John, If you set a static port map do you still see packets being blocked as indicated in your screenshot?
If so this would indicate an issue outside of the miniupnp daemon itself…I updated to the latest snapshot (yesterday's) and I have no problem on i386. uTorrent opens a port and the port test succeeds.
If the rules are there, it should be working. When UPnP was really broken, there were no rules added there.
Do you think a clean install would make a difference Jim?
-
Unlikely, but possible.
-
Jim,
Please don't think I'm being confrontational, but what would it take to prove this issue exists for some of us?
-
A few things:
1. A screenshot of the UPnP status screen showing the client ports that should be open. Use uTorrent or similar that has a built-in test.
2. The pfctl commands mentioned above.
3. The parsed and raw firewall log entries for the packets that should be matching the rule, but are not.
4. The full contents of /tmp/rules.debug, pfctl -vvsr, and pfctl -vvsn
5. The contents of netstat -rn
6. A screenshot showing that the test failed.
7. Repeat the same test with a manual port forward instead of UPnP and see if that works.I don't doubt that it's not working, but given the rest of the context, I'm not entirely sure it's UPnP and not something else just getting blamed on UPnP.
