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.



  • @sullrich:

    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)



  • @n6mod:

    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 -d

    I 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.



  • @n6mod:

    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:5060
    
    

    So 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.



  • @rsw686:

    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.



  • @n6mod:

    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?



  • @rsw686:

    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!!


Log in to reply