Bouncing a tunnel on ScreenOS

So the tunnels down and the head resides on an SSG520 and you have no idea how to bounce it. Well you're in luck, this'll show you how to do it!

First! Connect to the SSG520. Make sure you don't muck around in this box because you can break many many things if you're not careful.

You'll need to connect via telnet or SSH depending on what's configured

Information Gathering

You'll need three commands to find VPN Tunnel information.

The first is:

get ike gateway

You'll be shown the IKE gateway configurations and the Phase 1 proposals as seen below.

SSG520-1(M)-> get ike gateway
 Id  Name            Gateway Address Gateway ID      Mode Proposals
---- --------------- --------------- --------------- ---- ---------
   2 foobardevice    192.168.1.2                     Main pre-g2-3des-sha

The second is:

get vpn

To see the VPN association with the IKE gateway and the Phase 2 proposals

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr        tunl No    g2-esp-3des-sha      on            0 eth3/0    

And lastly;

get sa

To examine the security association information.

SSG520-1(M)-> get sa | i 192.168.1.2

00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

Insight

Now we have a plethora of information, but we still haven't bounced the tunnel. Lets use the information we've gathered to do that.

There's two things you'll need to clear, Phase 1 and Phase 2.

Since the editors at Wikipedia can explain this better than I can, I've provided a snippet below detailing Phase 1 and 2 for those who are unfamiliar with the process:

IKE consists of two phases: phase 1 and phase 2. IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA). The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does not. During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode.

Tear Down

So you're a little bit smarter, and know what we'll be clearing. Let us proceed!

Phase 1 comes first.

The first command we issued provided us with an "IKE Gateway". This is just the public address of the peer (a peer is the other end of the tunnel).

Phase 1 is stored in an IKE cookie (not chocolate chip, think a browser cookie and you'll have a better understanding of how it works). We'll have to get rid of this cookie to wipe out Phase 1 information for the specific peer.

clear ike-cookie 192.168.1.2 

Sometimes just clearing Phase 1 will cause the tunnel to rebuild. If it does not we'll have to clear Phase 2 information (it's usually safer to tear the entire tunnel down anyway).
Onward to Phase 2!

We need to clear the security association for the tunnel.

If you remember when we input get sa, on the left-hand column we saw a bunch of numbers. These are hexidecimal labels used to identify a specific association.

SSG520-1(M)-> get sa | i 192.168.1.2 
00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

No we won't be doing hex conversions, don't worry. But you will notice that there are two associations for one peer. One is for inbound, and the other for outbound. You can see which is which by looking at the arrow next to the hex ID.

We'll be using that hex ID to clear that specific association.

clear sa 0x07

If you've never used hex codes before, the preceeding 0x just identifies what proceeds as hexidecimal. We don't need to provide the entire ID as it's all zeros.

And that's it! You've successfully bounced the tunnel from an SSG520.

Rebuild

We tore down the tunnel but it's not coming back up. Probably because the user thinks it's down and isn't trying to use it. A tunnel won't be established until we flood it with interesting traffic. And what could be more interesting than pings!

ping 192.168.1.10 from e3/0

Where the IP address is the VPN address at the remote site, and the interface is the one used with the tunnel.

You can find the tunnel's interface in the output from get vpn command we input earlier.

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr         tunl No    g2-esp-3des-sha      on            0 eth3/0