IPSec traffic being treated as "ciscovpn" applicatoin

[allarm]

Hi,

Having an issue with IPSec tunnels. Sometimes (not all the time), phase 1 can't be established because IKE traffic is being treated as "ciscovpn" instead of ike and being discarded. Once I clear the session, the next session establishes correctly and works perfectly fine. Both sides of ipsec tunnel are terminated on Cisco routers. Is there anything we can do about it (aside from allowing ciscovpn application)?

Details:

--------------------------------------------------------------------------------
ID          Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])
Vsys                                          Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
8889         ciscovpn       DISCARD FLOW  NS   x.x.x.x[500]/LAN-CORP/17  (y.y.y.y[500])
vsys1                                          z.z.z.z[500]/UNTRUST-L3  (z.z.z.z[500])

> clear session id 8889

--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
27654 ipsec-esp ACTIVE FLOW NS x.x.x.x[20033]/LAN-CORP/50 (y.y.y.y[20033])
vsys1 z.z.z.z[20033]/UNTRUST-L3 (z.z.z.z[20033])
26671 ike ACTIVE FLOW NS x.x.x.x[500]/LAN-CORP/17 (y.y.y.y[500])
vsys1 z.z.z.z[500]/UNTRUST-L3 (z.z.z.z[500])

[pankaku]

We can create rule based on source ip and destination ip and port number instead of application. If application is causing issues.

One single rule will have source ip add x,y and destination as x,y and underservice tab we can specifiy udp port 500.

Here x,y are the ip address of the IPSec peers.

[allarm]

Well, why would we have L7 firewall then? 🙂

As from I see, this issue is quite old and have not been fixed for quite a long period of time. Is it possible to have a response from Palo Alto engineers on this? Or maybe there is a way to create a feature request/bug report which I don't know?

ps

I am the topic starter, had to switch between accounts, sorry for this mess.

[allarm]

Anyone?

[reaper]

Since it is a tunnel between 2 cisco devices, the behavior may be similar to 'ciscovpn' client traffic which is why it could hit on that application instead of simply 'IKE'

You could either add the application to your security policy to allow it through, or if you believe the AppID is not working as expected, you can open a support case with TAC and the content team will take a look at the session's packetcaptures and update the application if possible

[kiwi]

Hi,

All feature requests need to go via your local SE.  

They can create the FR for you and can add votes to it to add more weight to it.

As for bug reports, these can only be opened by TAC via a support case.  If you are planning to open a support case then I'd recommend to have some PCAPs ready so the engineers can investigate the payload.

[allarm]

The problem is that the behavior isn't uniform. Most of the time this traffic is being treated as ike and sometimes it starts being treated as ciscovpn and we have to clear the session to let ipsec terminators negotiate again.

[allarm]

Please remove personal data from your message. Not sure why did it get in your reply, could be a problem with my account, but anyway.

[reaper]

The fact this behavior isn't uniform would be a good reason to open a support case and have TAC investigate. you'd need to try and get a packetcapture of the moment the session is identified as ciscovpn, which may take some time, but then the content team will be able to use that data to finetune the AppID

[nextgenhappines]

I recently ran into a similiar issue with sflow traffics got identifed as bittorrent application.    I provided show session, external packet capture, debug log, clear session.   The issue is addressed via a threat signature updated.

[allarm]

Thanks, will try it.