IChat without extensive port forwarding?
-
One of the things that was reported to me as broken when I replaced DD-WRT with pfSense was iChat AV.
Apparently it doesn't work without a litany of port forwards. This also means that it will only work for one host, which is not the ideal solution (we have about 8 people in the office here).
What's different here? I believe that iChatAV uses STUN or similar to get connections working. Is pfSense doing something to keep STUN from working, and if so, can I turn it off?
Thanks.
-Zandr
-
Enable miniupnp which is available in recent snapshots and iChatAV will automatically negotiate needed ports.
-
Enable miniupnp which is available in recent snapshots and iChatAV will automatically negotiate needed ports.
I'll give that a shot, though the notion of UPnP makes my skin crawl.
Curiously, UPnP was disabled on the old firewall.
-
pfSense/PF scrambles the source port on outgoing connections. This can cause issues with VOIP and Video chat type applications.
UPNP used to make my skin crawl as well but I think we have one of the best UPNP experiences out there right now.
-
Please note that you not only can turn on/off UPnP but that you even can monitor and control it. Give it a try.
-
So, it's not working.
iChat works for text, but video doesn't.
The pf scrambling of ports is likely responsible for breaking STUN. Can that be disabled?
Further, while iChat seems to be able to open the ports it uses for the text chat using uPnP, the video stuff doesn't work. I do see a 'SUBSCRIBE not implemented' in the log, but the logging from miniupnpd is pretty minimal. Can that be turned up? (I didn't see anything in the config, nor did I find anything documented at miniupnp.free.fr)
-
So, it's not working.
iChat works for text, but video doesn't.
The pf scrambling of ports is likely responsible for breaking STUN. Can that be disabled?
Further, while iChat seems to be able to open the ports it uses for the text chat using uPnP, the video stuff doesn't work. I do see a 'SUBSCRIBE not implemented' in the log, but the logging from miniupnpd is pretty minimal. Can that be turned up? (I didn't see anything in the config, nor did I find anything documented at miniupnp.free.fr)
You can run miniupnpd in debug mode which will give you detailed logging at the console. From the console
/usr/local/etc/rc.d/miniupnpd.sh stop
/usr/local/sbin/miniupnpd -f /usr/local/etc/miniupnpd.conf -dI don't have a mac so I can't test out iChat with miniupnpd. If you can get me the debug output where iChat tries to map the ports and fails I can see what I can do to get this resolved.
-
The pf scrambling of ports is likely responsible for breaking STUN. Can that be disabled?
Search the forum for "static port". However it would be nice if you could report back with the miniupnp debug info that rsw686 requested so we can make miniupnp work with ichat.
-
OK, here's the miniupnpd output:
# /usr/local/etc/rc.d/miniupnpd.sh stop rules cleared nat cleared # /usr/local/sbin/miniupnpd -f /usr/local/etc/miniupnpd.conf -d miniupnpd[81455]: listening on 192.168.69.1:2189 miniupnpd[81455]: SSDP M-SEARCH from 192.168.69.252:49186 ST: upnp:rootdevice miniupnpd[81455]: SSDP M-SEARCH from 192.168.69.252:49186 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 miniupnpd[81455]: SSDP M-SEARCH from 192.168.69.252:49186 ST: urn:schemas-upnp-org:service:WANIPConnection:1 miniupnpd[81455]: HTTP connection from 192.168.69.252:49498 miniupnpd[81455]: HTTP REQUEST : GET /rootDesc.xml (HTTP/1.1) miniupnpd[81455]: HTTP connection from 192.168.69.252:49499 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[81455]: HTTP connection from 192.168.69.252:49500 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: HTTP connection from 192.168.69.252:49501 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 5060 to 192.168.69.252:5060 protocol UDP for: iC5060 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: redirecting port 5060 to 192.168.69.252:5060 protocol UDP for: iC5060 miniupnpd[81455]: creating pass rule to 192.168.69.252:5060 protocol UDP for: iC5060 miniupnpd[81455]: HTTP connection from 192.168.69.252:49502 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: HTTP connection from 192.168.69.252:49503 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 16384 to 192.168.69.252:16384 protocol UDP for: iC16384 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: redirecting port 16384 to 192.168.69.252:16384 protocol UDP for: iC16384 miniupnpd[81455]: creating pass rule to 192.168.69.252:16384 protocol UDP for: iC16384 miniupnpd[81455]: HTTP connection from 192.168.69.252:49504 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: HTTP connection from 192.168.69.252:49505 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 16385 to 192.168.69.252:16385 protocol UDP for: iC16385 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: redirecting port 16385 to 192.168.69.252:16385 protocol UDP for: iC16385 miniupnpd[81455]: creating pass rule to 192.168.69.252:16385 protocol UDP for: iC16385 miniupnpd[81455]: HTTP connection from 192.168.69.252:49506 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: HTTP connection from 192.168.69.252:49507 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 16386 to 192.168.69.252:16386 protocol UDP for: iC16386 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: redirecting port 16386 to 192.168.69.252:16386 protocol UDP for: iC16386 miniupnpd[81455]: creating pass rule to 192.168.69.252:16386 protocol UDP for: iC16386 miniupnpd[81455]: HTTP connection from 192.168.69.252:49508 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: HTTP connection from 192.168.69.252:49509 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 16387 to 192.168.69.252:16387 protocol UDP for: iC16387 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: redirecting port 16387 to 192.168.69.252:16387 protocol UDP for: iC16387 miniupnpd[81455]: creating pass rule to 192.168.69.252:16387 protocol UDP for: iC16387 miniupnpd[81455]: HTTP connection from 192.168.69.252:49512 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping miniupnpd[81455]: DeletePortMapping: external port: 16384, protocol: UDP miniupnpd[81455]: removing redirect rule port 16384 UDP miniupnpd[81455]: HTTP connection from 192.168.69.252:49513 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping miniupnpd[81455]: DeletePortMapping: external port: 16385, protocol: UDP miniupnpd[81455]: removing redirect rule port 16385 UDP miniupnpd[81455]: HTTP connection from 192.168.69.252:49514 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping miniupnpd[81455]: DeletePortMapping: external port: 16386, protocol: UDP miniupnpd[81455]: removing redirect rule port 16386 UDP miniupnpd[81455]: HTTP connection from 192.168.69.252:49515 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping miniupnpd[81455]: DeletePortMapping: external port: 16387, protocol: UDP miniupnpd[81455]: removing redirect rule port 16387 UDP miniupnpd[81455]: HTTP connection from 192.168.69.252:49516 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[81455]: HTTP connection from 192.168.69.252:49517 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry miniupnpd[81455]: GetSpecificPortMappingEntry: rhost='(null)' 5060 UDP found => 192.168.69.252:5060 desc='iC5060' miniupnpd[81455]: HTTP connection from 192.168.69.252:49518 miniupnpd[81455]: HTTP REQUEST : POST /ctl/IPConn (HTTP/1.1) miniupnpd[81455]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[81455]: AddPortMapping: external port 5060 to 192.168.69.252:5060 protocol UDP for: iC5060 miniupnpd[81455]: no permission rule matched : accept by default (n_perms=0) miniupnpd[81455]: port 5060 protocol UDP already redirected to 192.168.69.252:5060So it appears to set up 5060 plus 4 ports from 16384-16387, and then tear down the high ports after it fails. I'll keep poking around, as I now have a setup where I control both firewalls. Stay tuned.
-
Miniupnpd is correctly mapping and removing the ports at the request of iChat. What I don't understand is why iChat decides to remove them.
-
Miniupnpd is correctly mapping and removing the ports at the request of iChat. What I don't understand is why iChat decides to remove them.
Because it isn't using them any more. (Good net citizen…imagine that!)
Digging further, I found that iChat AV is trying to open a SIP connection. It's trying to connect to the remote end on some bizarre high port, which I believe (though I didn't have the monitors close enough together to catch it all) is an artifact of pf scrambling port numbers in NAT.
Turning on static port in the Advanced NAT setting solved the problem, though iChat still opens 5060 for itself if it can.
-
Because it isn't using them any more. (Good net citizen…imagine that!)
I meant why it was failing to connect and thus removing the ports. I know how UPnP apps work as I added and fixed a good amount of code in miniupnpd. What does iChat give you as the error message?
-
I meant why it was failing to connect and thus removing the ports. I know how UPnP apps work as I added and fixed a good amount of code in miniupnpd. What does iChat give you as the error message?
I'd have to break a bunch of things to reconstruct that situation again, and it was an intermediate step. I believe that at that time, there were static forwards on the remote end, (which I believe is a Linksys box running stock firmware), and I didn't have static NAT enabled. The problem seemed to be caused by the port scrambling.
I know that what finally tipped me off to that was that my end was trying to make a connection to the remote WAN IP address, but on a very high port number (56000+), as well as trying to connect to private addresses on 5060. But at that point, iChat was only using uPnP to open 5060 before it failed. The logs indicated it was trying to make a UDP SIP connection, btw.
I think the end of the story is that uPnP works fine, but iChat AV really requires static ports to work correctly.
-
I have the same problem with my brother's pfsense.
Here, it works OK with ports 6890-6900 open. He have the same config as me with the same ports opened but it don't works with him. We're not using the Advanced Outbound NAT.
I really don't know what's wrong on his side.
Thanks!!
-
Now, i know what the problem is.
My brother's isp is using SIP and ichat is also using SIP so there's conflict.
I don'y know if someone have a solution ?
Thanks!!