If you're not making mistakes, then you're not doing anything.
+
+
+
+
+
+
Over the weekend i was forced to replace the old 7200 rpm 1Tb HDD on the Mac. My first thoughts were, where do I start ? After doing a little research it all came down to suction cups; required to remove the front glass cover, as it’s held on with magnets (what the…but a slick design). Once that was done you’re pretty much inside. HDD replaced with a Samsung Pro 512Gb… Zoom, zoom….
Here are a few guides that helped me out.
+
+
+
+
+
+
I decided to use cisco’s EEM Scripting Engine to activate and deactivate the cellular interface to support a Primary link failure of our MPLS Link combined with an IP SLA:
ip sla auto discovery
ip sla 100
icmp-echo 1.1.1.1 source-interface GigabitEthernet0/1
threshold 1000
frequency 15
ip sla schedule 100 life forever start-time now
EEM Scripts
event manager applet Activate-3G
event track 60 state down
action 1 cli command “enable”
action 2 cli command “configure terminal”
action 3 cli command “interface cellular0/1/0”
action 4 cli command “no shutdown”
action 5 cli command “end”
action 99 syslog msg “Primary Link Down – Activating 3G interface”
event manager applet Deactivate-3G
event track 60 state up
action 1 cli command “enable”
action 2 cli command “configure terminal”
action 3 cli command “interface cellular0/1/0”
action 4 cli command “shutdown”
action 5 cli command “end”
action 99 syslog msg “Primary Link Restored – Deactivating 3G interface”
Stateful Failover for IP Security (IPsec) allows a router to continue processing and forwarding IPsec packets after a planned or unplanned outage occurs. A backup (secondary) router automatically takes over the tasks of the active (primary) router if the active router loses connectivity for any reason. This process is transparent to the user and requires neither adjustment nor reconfiguration of any remote peer.
It should be transparent but due to the nature of the configuration we had to apply the Stateful Failover to the Standby.
+
+
+
+
+
+
+
+
+
+
+
+
SSH provides an encryption shell to prevent snooping by unwanted parties and authentication. SSH shell sessions are encrypted, whereas Telnet is in clear text. Passwords and any data transferred from a user accessing a device is private and not easily viewable.
The following configurations are used to enable SSH on a device:
Cisco IOS access router
hostname access-router
ip domain name ese.cisco.com
!
cry key generate rsa general-keys modulus 1024
!
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh source-interface GigabitEthernet0/1
!
line vty0 15
Transport input ssh
Cisco Catalyst switch
hostname catalyst-switch
ip domain name ese.cisco.com
!
cry key generate rsa general-keys modulus 1024
!
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh source-interface Vlan193!
!
line vty 0 15
Transport input ssh
+
+
+
+
+
+
GRE Tunnel Configuration
Generic Routing Encapsulation, or GRE, is a tunneling protocol that allows the encapsulation of many different network layer protocols between two endpoints. Packets are sent through a virtual tunnel on a point-to-point link.
It is important to understand that GRE tunnels do not encrypt traffic in any way; they are simply encapsulated within an additional GRE and IP header. If a secure tunnel is required, IPSec can be used with GRE to provide data confidentiality.
Also keep in mind that GRE over IPSec tunnels are different from stand-alone IPSec VPN tunnels. GRE over IPSec tunnels support multicast IP traffic, which strict IPSec VPNs do not. This is important when routing protocols need to send routing information across the tunnel since they use multicast for their control information. If your network requires a routing protocol like EIGRP or OSPF, then GRE over IPSec can provide secure transport for those services.
Step 1: Create the tunnel interface on the VPN router.
A GRE tunnel uses a virtual tunnel interface, configured with an IP address where packets are encapsulated/decapsulated as they enter and exit the GRE tunnel.
The IP address must be in the same subnet on both router’s tunnel interfaces.
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
It is common practice to also reduce the maximum transmission unit (MTU) to 1400 bytes to avoid any fragmentation problems over the transport networks. Remember that GRE adds an additional 20-byte IP header as well as a 4-byte GRE header to each packet in the tunnel.
Because most devices have an MTU of 1500 bytes, reducing the GRE tunnel MTU will account for the added overhead and help prevent unnecessary packet fragmentation.
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
ip mtu 1400
Step 2: Define the tunnel source and destination under each tunnel interface.
The router uses its local interface that connects to the internet as its tunnel source. The tunnel destination corresponds to the remote router’s publicly routable IP address.
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
ip mtu 1400
tunnel source FastEthernet0/0
tunnel destination 204.20.20.2
Note that the tunnel source and destination can both be IP addresses. For example, “tunnel source 201.20.20.1″ could have been used instead of “tunnel source FastEthernet0/0″.
Step 3: Testing Connectivity
The configuration above is from the perspective of RouterA. The same configuration template would need to be applied to RouterB for the tunnel to begin passing traffic (with source/destination IPs swapped of course).
Now that both endpoint routers have been configured, they should be reachable via pings.
ping 172.16.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Step 4: Add Routes to Remote Networks
This confirms that we can pass traffic inside the GRE tunnel, but hosts on the Branch LAN networks will not be able to send packets to each other without some routes added. We can use a simple static route for this purpose.
RouterA(config)# ip route 10.0.20.0 255.255.255.0 172.16.1.2
RouterB(config)# ip route 10.0.10.0 255.255.255.0 172.16.1.1
Now when RouterA receives a packet destined for the East Branch LAN (10.0.20.0/24), it knows it’s next-hop interface is the tunnel endpoint, so it will forward the packet through the GRE tunnel.
That’s it for the GRE tunnel configuration. Now onto adding IPSec.
IPSec Encryption for the GRE Tunnel
As we mentioned, GRE provides no form of payload confidentiality or encryption. If the packet are sniffed over the public transit networks, their contents are in plain-text.
IPSec solves the security concerns by encrypting part or all of the GRE packets. There are two IPSec tunnel modes – tunnel and transport. This configuration example will show the default, tunnel-mode IPSec encryption which protects they entire GRE header and payload.
Step 1: Create an Access list to define the traffic to encrypt.
The ACL should match traffic from the outside interface of the local router to the outside interface of the remote router.
access-list 101 permit gre host 201.20.20.1 host 204.20.20.2
Step 2: Configure an isakmp policy.
Note: The ISAKMP policy, key, and IPSec transform set must match on both sides of a single tunnel.
crypto isakmp policy 1
authentication pre-share
Step 3: Configure pre-shared keys.
The key P@ssword will be configured to be used for authentication with RouterA’s peer 204.20.20.2. The address at the end of the statement refers to the public IP address of the peer router (RouterB).
crypto isakmp key P@ssword address 204.20.20.2
Step 4: Configure the transform set.
crypto ipsec transform-set strong esp-3des esp-md5-hmac
The full ISAKMP configuration:
crypto isakmp policy 1
authentication pre-share
crypto isakmp key P@ssword address 204.20.20.2
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
Step 5: Configure a crypto map and bind the transform set and the traffic ACL to the crypto map. Define peer IP address below crypto map.
crypto map S2SVPN 10 ipsec-isakmp
set peer 204.20.20.2
set transform-set strong
match address 101
Step 6: Apply the crypto map to the physical, outside interface.
If you are running a version of IOS Software Release earlier than 12.2.15 then the crypto map must be applied to the tunnel interface as well as the physical interface.
interface FastEthernet0/0
crypto map S2SVPN
interface Tunnel0
crypto map S2SVPN
Now configure the remote router using the same IPSec configuration template. Make sure to change the local and remote IPs as necessary.
Verify GRE over IPSec Tunnel Connectivity
Now that the GRE over IPSec tunnel configuration is complete, we can verify end-to-end IPSec tunnel connectivity. By simply sending pings to the remote networks, the IPSec VPN will come up and begin encrypting/decrypting traffic.
RouterA# ping 10.0.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
The show crypto session command can be used to verify that the IPSec VPN encryption is operational.
RouterA# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 200.20.20.2 port 500
IKE SA: local 201.20.20.1/500 remote 204.20.20.2/500 Active
IPSEC FLOW: permit 47 host 201.20.20.1 host 204.20.20.2
Active SAs: 2, origin: crypto map
+
+
+
+
+
+
What is Iceweasel?
Iceweasel is a fork [from Firefox] with the following purpose :
backporting of security fixes to declared Debian stable version.
Beyond that, they will be basically identical.
Step # 01
Launch the browser and download the Flash Player in a separate folder.
Download link = http://get.adobe.com/flashplayer/
(Note: Version to download tar.gz for other Linux)
Step # 02
Launch the terminal and open the folder path where downloaded flash file is stored then run the following command.
or
If in case your downloaded file having some another name then put that file name during extracting
Step # 3
Now run the following last command (Remember: Do not change the folder path stay in the same folder where you unpacked the files)
+
+
+
+
+
+
In the first CLI session, run tcpdump on the LAN interface. In the second CLI session, run tcpdump on the WAN interface and in the third CLI session, ping the IP address fo the host which traffic doesn’t get optimised
Open up three sessions
Three CLI sessions via SSH to the RB for troubleshooting:
riverbed-sh#tcpdump -ni lan0_0 icmp
riverbed-sh#tcpdump -ni wan0_0 icmp
riverbed-sh#ping -I ip to ip
MystaJoneS 