Backup ASA config with PowerShell

During my years in the networking business one of my frustrations is that it is very hard to backup the configuration of an ASA. There are some commercial products like Solarwinds that can accomplish this goal, but it costs money. An open source alternative like Rancid is also available but is pretty hard to configure.
Determined to find a solution I started searching the internet and came across some PowerShell scripts.  I’m not a PowerShell specialist, but I do know how to put together the separate scripts. So to be clear, I did not invent the scipts I just put them together.

So let’s take a look at the script:

Read-Host  “Enter Password” -AsSecureString | ConvertFrom-SecureString | Out-File c:\<map>\cred01.txt
–I don’t want to sent the password of the ASA user plain over the network. So with the above line I make sure the password is encrypted. It is possible to convert the password back to plain text, but then you’ll need access to the server. So it is not rocksollid save, but safer then sending the password in plain text over the internet. If you make sure that the useraccount only has minimal rights on the ASA, there is minimal change of getting unwanted guests on your ASA. The line converts the plain password to an encrypted password and writes it to a .txt file.

$ASApw = Get-Content “c:\<map>\cred01.txt” | ConvertTo-SecureString #-AsPlainText #-Force
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($ASApw)
$ASApw = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
–The above three lines are needed to convert the encrypted password from the credentials file. This is needed because the ASA is unable to read an encrypted password.

$ASAIP = “<ip address>”
$ASAUser = “<username>”
$ASAEnablepw = $ASApw

#Modifies the ASA firewall
#Starts by writing a “commands” file#
echo en >>unicode.txt
echo $ASAEnablepw >>unicode.txt
echo “conf t” >>unicode.txt
echo “no pager” >>unicode.txt
echo “show run” >>unicode.txt
echo “pager 24” >>unicode.txt
echo “copy running-config startup-config” >>unicode.txt
echo “running-config” >>unicode.txt
echo exit >>unicode.txt
echo exit >>unicode.txt

#Converts the file to ASCII format (separate file)#
$lines = gc “unicode.txt”
$lines | out-file -encoding Ascii -filepath commands.txt
–The above lines writes the actual ASA commands to the commands.txt file.

#Using the command file and plink.exe connects and runs the commands#
c:/Windows/System32/plink.exe -ssh -l $ASAUser -pw $ASApw $ASAIP -m commands.txt > “c:\<map>\ASA.txt”
–To make things work you need to download the Plink tool. It is the command line version of Putty. It can be downloaded for free. I put the tool in de c:\windows\system32 folder, but you can place it everywhere you want. This line writes the configuration of the ASA to an .txt file.

#removes the files it created earlier#
del unicode.txt
del commands.txt

As you can see it’s actually a pretty easy script an above all it’s free.
To make a daily backup, create a task through “Task scheduler”.

Cisco Champion 2016

I’m proud to announce that I’m a Cisco Champion in Enterprise Networks for the second year in a row!

logo

Cisco Guest Blog

Check out my guestblog @ Cisco: http://blogs.cisco.com/perspectives/dmz-basics

 

Connect to OSPF area 0 over GRE tunnel

We all know that all OSPF areas have to be connected to area 0. But sometimes you encounter
a situation where it is not possible to connect an area to area 0. This can happen because of
poor network design or because two or more networks merge together. There are several options
to deal with this problem. In the CCNP curriculum you learn that a virtual-link is the way
to go on this problem. But there is an other option which is not as popular, but in my opinion
is even more elegant. I’m talking about a GRE tunnel solution.

Let’s take the topology as shown in the picture below.

OSPF_GRE_TOPOLOGY

Router R2 is connected to R1 in area 0. R2 and R3 are connected in area 1 and R3 is connected
to R4 in area 2. Which means that R3 has no connection to area 0.

Below the configurations of routers R1 to R4 before the configuration of the GRE tunnel.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.100.100.254 255.255.255.0
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.100.100.0 0.0.0.255 area 0
!
R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 1
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.3 area 1
!
R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.3.1 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 1
network 10.0.1.0 0.0.0.3 area 1
network 10.0.3.0 0.0.0.3 area 2
!
R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.3.2 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.200.200.254 255.255.255.0
!
!
router ospf 10
router-id 4.4.4.4
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 2
network 10.0.3.0 0.0.0.3 area 2
network 10.200.200.0 0.0.0.255 area 2
!

To make this topology work there needs to be a connection from R3 to area 0. To make this happen
make the following configurations to router R2 and R3.

R2
!
interface Tunnel0
ip address 172.18.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 3.3.3.3
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!
R3
!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!

If you do a “show ip ospf neighbors” on R2 you can see there is a full neighborship between router
R2 and R3 in area 0.

show ip ospf neighbors R2-R3
And with the “show ip route” command you see the network from “area 2” is now in the table.

show ip route R2-R3
Now ping from PC1 to PC2 and this will succeed.

ping PC2-PC2

More interesting is a traceroute from PC1 to PC2, this will show the traffic is actually going
trough the GRE Tunnel!

traceroute PC1-PC2

GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.

 

Private vlan’s

This blogpost is about private vlan’s. For  my CCIE study I looked into PVLAN’s. First some terminology. When working with PVLAN’s words like primary vlan, secondary vlan, promiscuous port, isolated port and community port have to sound familiar. If not check the following summary:

  • Primary VLAN: Original vlan, used to forward the actual traffic
  • Secondary VLAN: is configured with one of the following types Isolated or Community
  • Isolated port: A switch port configured as Isolated is only able to communicate with the promiscuous port. It is not able to reach any other destination!
  • Community port: A switchport configured as Community is able to communicate with a server in the same community vlan and the promiscuous port. A community port is not able to communicate with an isolated port.

Below a drawing which describes the above summary.

PVLAN

In the configuration below two laptops are configured in an isolated vlan. Therefor they won’t be able to communicate with each other, but they are able to communicate with the promiscuous port.

PVLAN_isolated

 

In the next configuration the two laptops are configured in a community vlan. because of that they are able to ping each other.

PVLAN_community

 

As you probably noticed, the only configuration change is that the private-vlan host-association changed.

Private vlan’s are very useful to large ISP, because with isolated ports it’s possible to use the same subnets. There is virtually no limit to the number of customers and only one firewall is needed for a lot of customers. The only limiting option is the throughput of the used firewall!

 

** to build this topology I used a Cisco 3560 switch and a Cisco ASA 5505 firewall

Follow

Get every new post delivered to your Inbox.