If you need to connect to your wireless network with a new machine and have forgotten the key, you can view the WEP or WPA key in cleartext using the following procedure on a machine that has connected before.
2. To show all the wireless profiles stored on this machine, issue the following command;
[box]
netsh wlan show profiles
[/box]
3. From the output above, the wireless profile I want the key for, is called SMOGGYNINJA-N. Note: This is the same as the Wireless networks SSID. To view the wireless key in clear text use the following command;
[box]netsh wlan show profiles name=”SMOGGYNINJA-N” key=clear[/box]
You can also export the profile from one PC to another one, (so you don’t have to enter the key on the new PC), with the following two commands.
Copy the WiFi folder you created in the step above, to the new PC/Laptop. Then execute the following command. Note: Change the section in red to match the path to your XML file.
I’ve spent years setting up VPN tunnels between firewalls. The only time I’ve ever dealt with GRE is for letting VPN client software though firewalls. GRE’s job is to ‘encapsulate’ other protocols and transport those protocols inside a virtual point to point link. Below is the topology, I’m going to use.
The tunnel will run form Router R1 to Router R3, once complete I should be able to ping Host2 from Host1.
Solution
Configure Router R1 for GRE
1. Create and configure a tunnel interface on the R1 Router. It will need an IP address, (here I’m using 10.0.0.1/30). Then you need to specify the source and destination of the GRE tunnel. Finally I’ve changed some MTU settings because typically MTU’s are set to 1500 and GRE adds an overhead, I’m dropping the MTU to 1400 and setting the maximum segment size to 1360.
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Tunnel0
*Mar 1 00:01:27.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#ip mtu 1400
R1(config-if)#ip tcp adjust-mss 1360
R1(config-if)#tunnel source 1.1.1.1
R1(config-if)#tunnel destination 2.2.2.1
R1(config-if)#exit
[/box]
2. Then we need to add a static route to the router’s routing table so it knows to use that tunnel for traffic destined for the 192.168.2.0/24 network.
3. This is simply a mirror image, of the configuration you carried our on router R1.
[box]
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface Tunnel0
*Mar 1 00:01:30.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip address 10.0.0.1 255.255.255.252
R3(config-if)#ip mtu 1400
R3(config-if)#ip tcp adjust-mss 1360
R3(config-if)#tunnel source 2.2.2.1
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#exit
R3(config)#ip route 192.168.1.0 255.255.255.0 Tunnel0
[/box]
Verify GRE Tunnel
4. Use the following command to check the status of the GRE tunnel.
[box]
R1# show interface tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.0.0.1/30
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 1.1.1.1, destination 2.2.2.1
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
[/box]
5. Then make sure that traffic passes over the tunnel.
[box]
R1#ping 192.168.2.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/64/88 ms
R1#
[/box]
Securing the Tunnel with IPsec
6. Our traffic is now going where we want it to, and it’s encapsulated, but it’s still being ‘sent in clear’ if traffic is intercepted ‘in flight’ it can be read. So we need to secure that traffic by encrypting it. First Job is to create an ISAKMP policy that will establish ‘phase-1’ of our secure tunnel. I’m using AES, with Diffie Hellman group 2, and SHA hashing. Ive specified that I will be using a pre-shared-key so that’s been created with the last command, and is assigned to the IP of the ‘other end’ of the VPN tunnel.
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption aes
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha
R1(config-isakmp)#exit
R1(config)#crypto isakmp key 0 Sh@reds3cret address 2.2.2.1
[/box]
7. Phase 2 of our tunnel (IPsec) is encrypted and hashed with a ‘transform set’ again I’m using AES and SHA, then I create a profile that uses my transform set.
8. The last job is to apply the profile I created above, to our GRE tunnel interface.
[box]
R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
*Mar 1 00:20:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:20:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:20:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]
9. Again configure router 3 as a mirror image.
[box]
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption aes
R3(config-isakmp)#group 2
R3(config-isakmp)#hash sha
R3(config-isakmp)#exit
R3(config)#crypto isakmp key 0 Sh@reds3cret address 1.1.1.1
R3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
R3(cfg-crypto-trans)#exit
R3(config)#crypto ipsec profile PF-PNL
R3(ipsec-profile)#set transform-set TFS-PNL
R3(ipsec-profile)#exit
R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
R3(config-if)#
*Mar 1 00:25:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:25:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:25:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]
Cisco IOS Verify IPsec VPN Tunnel Is Up
Note: To bring up the tunnel simply send some traffic over it by pinging something on the other side of the tunnel. If you get a reply then the tunnel is up! But to check it status firstly make sure phase 1 has established.
[box]
R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
1.1.1.1 2.2.2.1 QM_IDLE 1001 0 ACTIVE
IPv6 Crypto ISAKMP SA
R3#
[/box]
QM_IDLE means that phase 1 has established (in Quick Mode), and is in an idle state (this is what you want to see, if you see any other state message you may need to start debugging things).
Once you know phase 1 is established you need to check phase 2.
[box]
R3#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 2.2.2.1
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 1.1.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 2.2.2.1, remote crypto endpt.: 1.1.1.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
current outbound spi: 0x3AA3F6B0(983824048)
inbound esp sas:
spi: 0x5C5C5EF1(1549557489)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: SW:1, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4559832/3506)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x3AA3F6B0(983824048)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: SW:2, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4559832/3506)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
[/box]
Related Articles, References, Credits, or External Links
I had a client the other week with about 25 sites, his core site was changing ISP and therefore changing its IP address. On the main site this is pretty straightforward, just change the outside interfaces IP address, sub net mask and the default route (That’s the default gateway for non cisco-ites).
All well and good, but what about his other 24 sites? They all had VPN’s back to the main site, and all these VPN’s were “hairpinned” together for “spoke to spoke” communication.
Well you can simply delete the VPNs and recreate them, but multiply that by 24 – then add on all the extra config for the hairpins and that’s a massive amount of work (and for the client a LOT of downtime.) So a swift config change on the remote sites is a much better idea.
For Cisco PIX firewalls running version 6 click here.
3. To see all the cryptomaps issue a “show run crypto map” command. (you may see more or less depending on the amount of VPN tunnels you have.
[box]
RemoteSite(config)# show run crypto map
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs
crypto map outside_map 1 set peer 111.111.111.111
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map 2 match address outside_2_cryptomap
crypto map outside_map 2 set pfs
crypto map outside_map 2 set peer 123.123.123.123 <<<< Here it is!!!
crypto map outside_map 2 set transform-set ESP-3DES-SHA
crypto map outside_map 3 match address outside_3_cryptomap
crypto map outside_map 3 set pfs
crypto map outside_map 3 set peer 133.133.133.133
crypto map outside_map 3 set transform-set ESP-3DES-SHA
crypto map outside_map 4 match address outside_4_cryptomap
crypto map outside_map 4 set pfs
crypto map outside_map 4 set peer 144.144.144.144
crypto map outside_map 4 set transform-set ESP-3DES-SHA
RemoteSite(config)#[/box]
4. From the example above we can see the tunnel we want to change is using “outside_map 2” so lets remove the entry for the old IP address and put one in for the new IP address.
[box]
RemoteSite(config)# no crypto map outside_map 2 set peer 123.123.123.123
WARNING: The crypto map entry will be incomplete!
RemoteSite(config)# crypto map outside_map 2 set peer 234.234.234.234
RemoteSite(config)#[/box]
5. That’s the cryptomap changed, now for the tunnel group. You can see all your tunnel groups with a “sho run tun” command.
[box]
RemoteSite(config)# sho run tun
tunnel-group DefaultL2LGroup ipsec-attributes
isakmp keepalive threshold 20 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
isakmp keepalive threshold 20 retry 2
tunnel-group DefaultWEBVPNGroup ipsec-attributes
isakmp keepalive threshold 20 retry 2
tunnel-group 111.111.111.111 type ipsec-l2l
tunnel-group 111.111.111.111 ipsec-attributes
pre-shared-key *****
tunnel-group 123.123.123.123 type ipsec-l2l <<<< Here it is!!!
tunnel-group 123.123.123.123 ipsec-attributes
pre-shared-key *****
tunnel-group 133.133.133.133 type ipsec-l2l
tunnel-group 133.133.133.133 ipsec-attributes
pre-shared-key *****
isakmp keepalive threshold 20 retry 2
tunnel-group 144.144.144.144 type ipsec-l2l
tunnel-group 144.144.144.144 ipsec-attributes
pre-shared-key *****[/box]
6. To delete a tunnel group, you use the “clear config tunnel-group” command.
Note: Before you delete it, make sure you know the pre shared key / shared secret – to see this, issue a “more system:running-config” command.
RemoteSite(config)# write mem
Building configuration...
Cryptochecksum: f3645705 ae6bafda c5606697 ecd61948
9830 bytes copied in 1.550 secs (9830 bytes/sec)
[OK]
RemoteSite(config)#
[/box]
9. Job done!
Well that didn’t seem very quick? No, but for the sake of explanation I did go a little deep, if you have multiple sites, just have the following in notepad.
configure terminal
no crypto map outside_map 2 set peer 123.123.123.123
crypto map outside_map 2 set peer 234.234.234.234
clear config tunnel-group 123.123.123.123
tunnel-group 234.234.234.234 type ipsec-l2l
tunnel-group 234.234.234.234 ipsec-attributes
pre-shared-key 123456789
write mem
Then simply jump from site to site changing the cryptomap name and shared secret for each one. If you get all this info first, you can migrate hundreds of sites in minutes, (That’s why I prefer command line to GUI ASDM).
Option 2 From ASDM
1. Connect to the ASDM, Configuration > Site-to-Site VPN > Advanced > Crypto Maps > Select the cryptomap going to 123.123.123.123 > Edit > Add the new IP Address.
2. Remove the old one > OK > Apply.
3. Configuration > Site-to-Site VPN > Advanced > Tunnel Groups > Select the old one > Delete > Apply.
4. Then to add a new one > Add > Set the Tunnel group name to the new IP > Enter the shared secret > OK > Apply.
5. Finally Save the changes > File > Save running configuration to Flash.
Cisco PIX (Version 6)
For older firewalls you will notice there is no “Tunnel-Group”, these came in with version 7. The process is similar, again you have to change the peer entry in the cryptomap, but you also need to set an isakmp peer.
no crypto map outside_map 20 set peer 123.123.123.123
crypto map outside_map 20 set peer 234.234.234.234
no isakmp key ******** address 123.123.123.123 netmask 255.255.255.255
isakmp key 123456789 address 234.234.234.234 netmask 255.255.255.255
Related Articles, References, Credits, or External Links
In the example below I’ve reset ALL my tunnels. I had a constant ping running across the VPN, and it only dropped one packet before the tunnel established again.
WARNING: This will reset ALLISAKMPVPN tunnels (both site to site, and client to gateway).
Cisco ASA Reset One VPN Tunnel
1. If you just want to reset one site to site VPN then you need to reset the IPSECSA to the peer (IP Address of the other end of the tunnel). Use the following command;
[box] clear ipsec sa peer X.X.X.X [/box]
Unlike above, in the example below I’ve reset just ONE tunnel. I had a constant ping running across the VPN, and it only dropped one packet before the tunnel established again.
Cisco ASA Check VPN Uptime
Just to prove this isn’t all smoke an mirrors, after the tunnel has re-connected you can check its uptime with the following command;
[box] show vpn-sessiondb detail l2l [/box]
Related Articles, References, Credits, or External Links
I’m running Chrome 11.0.696.25 beta (At time of writing) and I’ve seen this error a few times, usually with Facebook, and it’s been more of an annoyance than anything else. I’ve seen it on my Windows 7 machine, and on my Ubuntu 10.10 Netbook.
Solution
1. Launch Chrome and click the Spanner Icon > Options > Under the hood > Content Settings.
2. Select “All cookies and site data.”
3. Select Remove All >Restart your browser and you should be fine.
Related Articles, References, Credits, or External Links
