Port triggering?

what are you trying to do?

It' s for Ringcentral phones a colleague of mine is helping install in a few of our remote locations. Vendor gave us a list of ports and mentioned this functionality was needed. I didn' t see anything in any KB' s on the fortinet support site or the manuals. The process is where an outbound connection is initiated on port A by one of the phones and an inbound connection is requested on one of a range of ports.

It maybe that the requirements are to not block certain ports from the phone to the PBX (offsite/hosted PBX presumably). In a few proprietary phone services I' ve witnessed the phones are SIP but there is an initial ' lock and key' protocol that opens the PBX for subsequent traffic to be allowed passage. It maybe that they operator is simply unable to articulate the above and has chosen to give a blanket set of ports and protocol with no mention of the state machine or direction of communication as things step their way through the process of connecting, maintaining connectivity and receiving asynchronous events. FortiOS, unless you have a helper already in the OS that suits, doesn' t have a a manual means of supporting triggered opening of additional ports or other protocol-ports. Nor does it have uPnP, the generally assumed successor to the functional ability to supply triggered port type passage (conduits). Port triggering, in summary is a means of allowing reverse connectivity (usually on one or more protocols that are different to the trigger itself) to occur. It is a weak type of authentication, ie passwordless authentication and is inherently security through obscurity in the manner that once it is understood it could be exploited. The closest technique in FortiOS to being able to provide port triggering is to engage the application control function with a custom application. You' d need to have a protection profile on your policy that hooked in at least at the level of the port that was first used by the phone to reach out to the PBX. So a deny rule would be beneficial below this policy for any of the inbound ports the phones might then use. If this phone is SIP, beware that the FortiOS SIP helper and sip/rtp engine (currently) assumes you are using legacy non-SIP aware phones and PBXs. So generally you' ll do best to turn it off if it is in anyway based on opensource software (which is usually more universal with regards to the network topologies it lends itself to). So if behind the esoteric port triggered functionality there is a more general purpose SIP stack do be prepared to tread carefully with your interop/integration plans.

Nothing fancy needed for Ringcentral. Just create a rule to allow all the phones access to the internet via Nat and set priority to high Ring central depends on using dhcp so either map a range of Macs in the DHCP or filter by by Ringcentral sip destinations to prioritize traffic. you will need to set your default priority to low or medium for all other traffic as your biggest problem will be that the bandwidth gets chewed up and the calls drop or get choppy. A few phones are ok, lots of phones are not great.