Cisco ASAv site-to-site VPN to Symantec Web Security Service (WSS)

[davinder2010]

Hi all, 

I'm having some serious technical issues with establishing a site-to-site VPN to Symantec's Web Security Service (WSS). Getting technical support to help is also really really painful. After three months of pulling my hair out I finally had a WebEX troubleshooting session, but unfortunately it was unsuccessful and we didn't get anywhere. 

This is my setup 

                                            Customer FW              NAT - Edge FW                                                              ep.threatpulse.net

{Multiple DMZ s / LANS}-----(>|) ASA FW ---------- (FGT-FW)-----------(Internet)---------(Symantec WSS)---(Proxy)

The customer firewall is the  ASAv Firewall 

The Fortigate is a perimeter firewall for all customers and NATs the outside interface of the ASA firewall  to a Public IP address and in terms of security policy its wide open (any any). The ASA is more restrictive. 

I followed the following KB from Symantec (or Broadcom as they are currently known as) but with some tweaks. I will explain: 

KB: https://knowledge.broadcom.com/external/article/174263/web-security-service-legacy-ipsec-connec.html

> Note: in other articles they have variations in config which i had to follow such as 

NAT-T when used, you need to change the IKE ID to the public IP address that the upstreat fw is natting the ASAs outside IP to. I had to do this on the ASA via ASDM, but it can be done on the CLI as 

crypto isakmp identity key-id <Public IP Address> 

I also didn't follow their advise on 'any' local encryption domain and 'any' remote encryption domain - I caused an outage whilst the firewall tried to bring up the tunnel. instead i used the classless RFC 1918 address as my local encryption domain and ep.threatpulse.net (ip address used) as the remote, i.e. the symantec proxy ip address. 

I have other VPN tunnels setup on this firewall and even if my local encryption domain was set to 'any' it would have overlapped with the other tunnels - the firewall did grumble at this!

I did NAT exempt for traffic headed for the proxy ip address for http and https. 

I used the same phase 1 and phase 2 settings and whats interesting is that Symantec in Phase 1 tries to negotiate 3DES / SHA DFH grp5.... strange.... The ASA didnt like.. 

I went through the setup with Symantec over the WebEx and they said it looked ok, however they didnt see any errors or messages that would indicate that phase 1 was unsuccessful. At my end though all i ever got when running show crypto ikev1 sa was the message telling me it was waiting for a response from symantec:

State : MM_WAIT_MSG6

Even if i change the phase 1 params to 3des sha DFH group 5 it still doesn't come up. 

Its not successfully negotiating phase 1

Anyone else experiencing this issue and the lack of support from Symantec?

[HaydenRoss27912]

Were you able to get this issue resolved in the end? Would appreciate any potential guidance you could offer.

[davinder2010]

Hi, 

No. Its been a nightmare. I had a case open with Cisco but I could only troubleshoot at my end of the VPN with TAC. Symantec or Broadcom just kicked us to the Curb. Now I have a third party consultant who is going to help me with the VPN - sounds like a bit of a joke considering i had this working absolutely fine with a Fortigate FW. 

Cisco TAC seem to think its the Pre-shared Key, however it was pasted from the broadcom portal > notepad > VPN config on the ASA. 

Will update soon as things are progressing. Once i get this working i will provide full details. 

Are you facing the same issue? 

[davinder2010 · Accepted solution]

Got this working via Certificate authentication.

You can't use firewall/vpn with preshare key behind a NAT. 

The FQDN option didnt work for me, changing the ike id as the docs suggest dont work plus didnt have time to debug fully. Was getting auth errors.

Follow this guide if behind a NAT:

https://knowledge.broadcom.com/external/article/174854/web-security-service-legacy-ipsec-connec.html

The cert from entrust mentioned in the link above didnt work for me. However another symantec article mentions to use this cert, this worked:

Entrust Root Certificate Authority

Valid Until: 11/27/2026

Serial Number: 45 6b 50 54

Thumbprint: b3 1e b1 b7 40 e3 6c 84 02 da dc 37 d4 4d f5 d4 67 49 52 f9

[davinder2010 · Accepted solution]

An update to this post, Symantec as of the 9th April 2021 are now no longer using the certificate based authentication method, it has been deprecated. 

The best way to get this working is if your device is not behind a NAT. Have your external interface on a public facing transit