Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IChat without extensive port forwarding?

    Scheduled Pinned Locked Moved NAT
    15 Posts 5 Posters 9.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      n6mod
      last edited by

      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)

      1 Reply Last reply Reply Quote 0
      • R
        rsw686
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • H
          hoba
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • N
            n6mod
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • R
              rsw686
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • N
                n6mod
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • R
                  rsw686
                  last edited by

                  @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?

                  1 Reply Last reply Reply Quote 0
                  • N
                    n6mod
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • R
                      Ricky
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • R
                        Ricky
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.