Discover what is initiating a site-to-site VPN?

[darren_g]

Hi folks.

I have a situation with site-to-site VPN's on my Palo Alto's which I could use some help diagnosing.

I have a number of remote teleworkers who have a company-provided Cisco 887 router, which is used to run a site-to-site, IPSEC VPN to link into our internal network.

This works fine in 99% of cases, but there's always one with an issue.

One of the remote users has a "naked DSL" service (unbundled local loop) - which means that she has no associated POTS phone line - and the Cisco 887 router doesn't do VoIP.

This means is that when she's *not* working, she unplugs our company Cisco and plugs in the ISP-provided router so she can use the VoIP phone. This ISP provided device doesn't support IPSEC VPN's, so it doesn't attempt to initiate one.

However, *something* this remote worker is doing is leaving a process running *somewhere* in our internal network which causes the PAN device to try and initiate the VPN tunnel constantly - continually timing-out, and trying again, vis-a-vis (IP addresses obfuscated)

IKE phase-1 SA is deleted SA: AAA.BBB.CCC.DDD[500]-WWW.XXX.YYY.ZZZ[500] cookie:10c77cfa24089c96:0000000000000000.	03/04 11:55:34
IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: AAA.BBB.CCC.DDD[500]-WWW.XXX.YYY.ZZZ[500] cookie:10c77cfa24089c96:0000000000000000. Due to timeout.	03/04 11:55:34
IKE phase-1 negotiation is started as initiator, main mode. Initiated SA: AAA.BBB.CCC.DDD[500]-WWW.XXX.YYY.ZZZ[500] cookie:10c77cfa24089c96:0000000000000000.

As you can see, this is being initiated by my PAN device, not by the remote end.

Is there some command 9CLI or GUI, I don't care) I can use to try and determine WHAT is causing the tunnel initiation? Exactly what interesting traffic is being used to kick of this negotiation?

I suspect she's leaving a connection running to *something* in the network which generates regular traffic at the other end (quite possibly a streaming audio source), but I need to find out what before I can get onto her and say "before you unplug your router, can you make sure you disconnect <THIS>, please, because it's causing additional load on the firewall".

Thanks for any help!

[DavePalo]

Hi Darren,

How are you managing your routing please?  Do you have a static route in your virtual router for a particular subnet pointing to the tunnel interface associated with the site-to-site VPN in question?

If so, wouldn't any traffic to that subnet be deemed interesting enough to cause the Palo to try to initiate a VPN tunel?

What traffic to/from that subnet do you see in your logs and session browser once the user has disconnected their Cisco 887?

Regards,

Dave

[darren_g]

hi Dave.

Yes, I have a static route in my VR pointing to the tunnel interface for the remote VPN - but the point is there shouldn't *be* any traffic initiated from "inside" to the remote - there are no servers or devices which require constant data transfers on the remote end - when the user workstation is turned off, there should be no traffic going across the VPN at all.

That's the entire issue - I can't *see* any sessions which are active while the VPN is supposedly negotiating - or not that I can see from the GUI (getting through 40 pages of session table looking for an address in a single /29 is a bit difficult. :-))

I got lucky, and managed to capture a flow packet while the thing was trying to setup using the CLI command "show session all filter egress-interface <interface>", but it wasn't easy. Turns out there was some Microsoft crud active - port 137, from memory (Microsoft netbios name service) from one of my Windows DC's to the workstation at the other end, which indicates that most likely she didn't shut down before unplugging the router - an so left a hanging active authentication session to the DC which was trying to terminate by connecting to the other end.

I'll get o to the remote user and ask them to be sure to log off/shut down their PC before disconnecting the router and see if it makes any difference.

[DavePalo]

Hi Darren,

There should be no need to go through all 40 pages of active sessions - you can filter on the egress interface to show the relevant sessions.

If your user works fixed hours then maybe you could use PBF to route the traffic away from the tunnel interface out of hours?  Or if you can find a way of remotely determining whether the Cisco router or the user's router is connected (say the external interface pings on Cisco but not on user's router) then you could use monitoring within PBF to automatically make the routing decision for you.

Regards,

Dave