Problem Blockin Linkedin - What is the best practice ?

[FabioGarcia]

Dears,

I am stuck with this problem since the lasts 2 weeks...

We have a default rule in our company blocking any social networking, but for some HR users, linkedin should be allowed.

I am trying to make a rule to allow some users to access only the linkedin website.

Decided this way

source zone > trust

src add > any

user > specific user

dst zone > untrust

destination add > FQDN objetcts ".linkedin.com" and ".licdn.com"

application > linkedin ssl

service > any

profile > none

Results

I can open the page but that is not well formatted...

In monitor > url filtering I see that traffic going to

"s.c.lnkd.licdn.com/scds/concat/common/js........"

Is not being recognized at this "allow linkedin rule" then traffic got blocked in the end (where social-networking traffic is blocked by default)

- How would be the best practice to get this problem solved ?

- Is the FQDN objects correct ?

- why FQDN object ".linkedin.com" is OK but ".licdn.com" is not ok ?

Thanks in advance for any reply... if you guys want some screens shots I can provide as well... thanks thanks thanks!

[wesa]

Hi Essilobr

Screenshot would help

Thanks

[sraghunandan]

When you use FQDN what happens is the mp resolves the domain listed in the fqdn and lists the ip addresses so this fqdn is related to the ip's belonging to linkedin and not the actual url that you visit.

So i would suggest using www.linkedin.com under fqdn's and use a url category/profile with s.c.lnkd.licdn.com/*

[FabioGarcia · Accepted solution]

Dears,

We found out that apps LINKEDIN uses SSL, but that dependencies is not yet mapped by Palo Alto... that was the problem....

If we check at applipedia, linkedin apps only has web-browser dependencie... and during the initial authentication, the site uses ssl.....

Then we solve the problem creating 2 rules as per below image

1st one an rule allow some users to any destination but only for app LINKEDIN

after the first access (www.linkedin.com) users will login... that time an application shift will occur (from linedin to ssl)

2nd rule allows that same users go to specific destination FQDN (www.linkedin.com) with app ssl

That worked for us....

Maybe later when PA realize that they need to put SSL as a default dependency for linkedin app... maybe I can delete the 2nd rule... by now we need that...

thanks everyone who helped us!!!