Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
billp
Contributor

Skype doesn' t work with SSL/SSH Inspection selected

I have a 600C running 5.0.7. Skype is an allowed/monitored app in the Application Control policy. Ports 80 and 443 are allowed. SSL inspection is enabled on port 443 so we can inspect certificates, but deep scanning is not selected for websites. If port 443 is selected for inspection, however, the Skype app cannot login. If it is deselected, then Skype will run. I saw an earlier post with a similar complaint, but there was no resolution. Has anyone else had problems running Skype with certificate inspection? I need to find a way to run Skype while still scanning other SSL certificates, so any suggestions would be welcome. Thanks.

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1
3 Solutions
billp
Contributor

I' m replying to my own post in case anyone else finds this useful. I have an open ticket with FTNT on this issue. I have a workaround in place for now by whitelisting all the IP' s associated with Skype logins. There appears to be a Skype login problem (at least with my config) if SSL certificate inspection is turned on. These Skype IPs can be found by running this BASH script:
 #!/bin/bash
 for i in {0..20} ; do dig +short dsn$i.skype-dsn.akadns.net; done | sort | uniq
If you don' t want to enter all 107 unique Skype addresses into the firewall, you can come close by using these class C' s: 111.221.74.0/24 111.221.77.0/24 157.55.130.0/24 157.55.235.0/24 157.55.56.0/24 157.56.52.0/24 213.199.179.0/24 64.4.23.0/24 65.55.223.0/24 (Credit to http://pingtool.org/block-skype-connection/ for the script and address info.) Just put them as destination addresses in a separate policy that does not have SSL inspection turned on. I realize these are static addresses and that Skype addresses are potentially dynamic. However, the above addresses have been stable for at least the last year or two. For me, that' s good enough for a temporary work-around.

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1

View solution in original post

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1
billp
Contributor

I've been in a dialog with tech support on this issue. 

 

There are some issues with scanning SSL connections using a proxy connection. If you switch to using flow mode for your scanning, Skype will work. This is for 5.0.7, but I imagine this works for 5.2 as well.

 

You can also turn off port 443 scanning in 5.0.7, and it should default to certificate scanning at that point.

 

Ultimately, there will be changes coming down to 5.4 and beyond that will address some of these issues. We need a function to whitelist an app (like Skype), and I believe this is in the works. 

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1

View solution in original post

Bill ========== Fortigate 600C 5.0.12, 111C 5.0.2 Logstash 1.4.1
ikoimecs
New Contributor II

Hi, The 5.2 and 5.4 versions already have exempts for microsoft and skype in the default SSL inspection profile, but the address *.messenger.live.com for skype seems to be outdated. Please try following: 1. Create additional Wildcard FQDN addresses: *.skype.com *.skype.net

*.trouter.io 2. Add these addresses to the exempt address list of your SSL inspection profile along with existing 'skype', 'live.com' and 'microsoft' 3. Assign this SSL inspection profile to your policy It works for me on v5.4.2

 

Microsoft may change IPs and DNS names, so if this happen again, open a Wireshark, set filter to 'dns' and monitor DNS requests, then add new wildcards to your exempt list.

Best regards, Ivo

View solution in original post

20 REPLIES 20
ikoimecs
New Contributor II

Hi, The 5.2 and 5.4 versions already have exempts for microsoft and skype in the default SSL inspection profile, but the address *.messenger.live.com for skype seems to be outdated. Please try following: 1. Create additional Wildcard FQDN addresses: *.skype.com *.skype.net

*.trouter.io 2. Add these addresses to the exempt address list of your SSL inspection profile along with existing 'skype', 'live.com' and 'microsoft' 3. Assign this SSL inspection profile to your policy It works for me on v5.4.2

 

Microsoft may change IPs and DNS names, so if this happen again, open a Wireshark, set filter to 'dns' and monitor DNS requests, then add new wildcards to your exempt list.

Best regards, Ivo

MikePruett
Valued Contributor

Yeah, skype is smart and used it's own certs at the application level....it knows when we are snooping.

Mike Pruett Fortinet GURU | Fortinet Training Videos
mokaz
New Contributor

ikoimecs wrote:

1. Create additional Wildcard FQDN addresses: *.skype.com *.skype.net

*.trouter.io

Ivo

Thanks for that, works like a charm !!!

emnoc
Esteemed Contributor III

Yes what   ikoimecs  post is good even  FTNT has a kb out that uses known ranges &  even a script that does this.

 

http://kb.fortinet.com/kb/documentLink.do?externalID=FD37470

 

Keep in mind  thet  *.wildcard-FQDN  iirc are not doable in  FortiOS 5.0 or 5.2

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ahelal
New Contributor

Dear all

Kindly, This post is old but there is something wrong in the Skype Call.

i have added the Skype IP Address and the WildCard FQDN (Which Skype works) but in the Skype Call sometime is wrong

it keeps connecting and then stop.

ahelal
New Contributor

I know that I'm replying on my post;

i found that the application Skype Call is going out through implicit deny rule.

i don't know why?

 

Alby23
Contributor II

Perhaps "strange" ports non specifically allowed in the upper policies?

ahelal
New Contributor

i have applied all Services.

still the same; Connecting sign and stop.

 

Alby23
Contributor II

Perform a debug flow 'till you find the session blocked by the implicit deny.

ahelal
New Contributor

Hello Again

i tried the web.skype.com; it works perfect every time.

 

so there is something with the application and the SSL/SSH Inspection.

if anyone know how to fix it. please help.

thanks

 

 

 

Labels
Top Kudoed Authors