BGP Route Redistribution

A good way to do route redistribution is to redistribute static routes using a route map.  BGP will let you redistribute static, but in order to protect agains errors it is better to filter the static routes via the use of a route map.  See example below:

router bgp 65049
 bgp log-neighbor-changes
 neighbor 10.248.45.161 remote-as 9942
 neighbor 10.248.45.161 description ** Moonee Ponds Backup BGP Session via Telstra DDFE **
 neighbor 10.248.45.161 password 7 050F56182F1F5C5A1702
 neighbor 192.168.208.6 remote-as 65049
 !
 address-family ipv4
  redistribute connected
  redistribute static route-map STATIC-TO-BGP
  neighbor 10.248.45.161 activate
  neighbor 10.248.45.161 send-community
  neighbor 192.168.208.6 activate
  no auto-summary
  no synchronization
 exit-address-family
!        
ip route 10.5.100.65 255.255.255.255 192.168.208.1
ip route 192.168.210.0 255.255.255.0 192.168.208.1

!        
ip prefix-list static-to-bgp seq 10 permit 192.168.210.0/24
ip prefix-list static-to-bgp seq 20 permit 10.5.100.65/32
!         route-map static-to-bgp permit 10
 match ip address prefix-list static-to-bgp

ASA and PIX guides - A Very Handy Link

The following page in the Cisco website has a ton of how-to guide's for configuration, administration, and optimisation of Cisco's security devices.

Configuring ASA and PIX Security Appliances

Failover Firewall - ASA 5540 Active/Passive

In this situation we had a single 5540 acting as the sole firewall for one of our divisions.  We will be purchasing a redundant Internet link so we are working on removing all single points of failure in the network.

Firstly the following MUST be the same accross the ASA Pairs:


- Platform type (i.e. 5510 + 5510)
- Number and types of Interfaces
- Licensed features
      - Encryption
      - Security contexts
      - Number of VPN peers
- Flash memory
- RAM


Also the IOS must be 7.1 or higher and if using a 5510 you'll need to have the security plus feature set.




Operation
If the active firewall fails the secondary takes over the primary firewalls IP and MAC addresses.


The two firewalls must be connected by what is called a LAN based fail-over link.  This can be a separate VLAN through a switch or a straight-through or cross-over cable.

The following data communication takes place over this link:

- Applicance state

- Hellos

- Link status

- MACs

- Config synchs (active to standby)

   

Changes must always be made on the active appliance and never on the standby firewall.

Stateful failover
Unless stateful failover is configured if the primary firewall fails all application connections will lose their state and will have to reconnect to their respective endpoints.  Configuring stateful failover makes sure that the following state data is shared from the active to the passive router so that applications will continue working without interruption:

- NAT table
- TCP connection state
- UDP connection stae
- ARP table
- Layer 2 brdge y able
- HTTP connection states
- ISAKMP and IPSec security association table
- GTP database info

Info not passed includes
- user auth table
- routing table

The stateful failover link is the link used by the ASAs to pass state info, this can be the same as the LAN-based failover link or it can be another physically separate link.  Data going over this link is sent in clear text unless a PSK has been configured at both ends.

Tasks required to create active/failover pair
Connect the two firewalls together and to their respective network - note that the IP addresses in the secondary unit are different but must be in the same subnet.

Veryfy that any switch port that connects to a security appliance failover link is configured to support LAN-based failover.
    - enable portfast
   - turn off channeling
- verify time ins synched on primary and secondary devices
- ensure speeds and duplex settings are all the same
- configure primary ASA for failover
- allow ASDM to configure secondary appliance
- save replicated config on the standby appliance


failover
failover lan unit primary
failover lan interface Failover GigabitEthernet0/3
failover polltime unit msec 500 holdtime 3
failover polltime interface 3 holdtime 15
failover key *****
failover replication http
failover link Failover GigabitEthernet0/3
failover interface ip Failover 10.21.35.9 255.255.255.252 standby 10.21.35.10

interface GigabitEthernet0/0.128
 description ASA-ISR Transit
 vlan 128
 nameif Outside
 security-level 0
 ip address 144.140.148.129 255.255.255.248 standby 144.140.148.130
 interface GigabitEthernet0/3
 description LAN/STATE Failover Interface

L2L VPN Config *** ROUTER Config ***

Background information

Have two sites which require a L2L VPN tunnel.  One is a head office/data center location running a ASA firewall and the other one is a remote branch office using a Cisco Router.  The config covered below assumes that both the router and the firewall already have a basic working configuration.  Details below:

Remote Office

Location: Badell, Singapore

Device: 1841 with adventerprisek9-m 12.4(25d)

LAN: 10.251.6.0 /23

WAN: 124.66.16.231

Head Office

Location: Sydney, Australia

Device: ASA 5540 with ASA software v 8.2(2)

LAN: all private ranges

WAN: 203.38.18.222

STEP 1 - ACL 
An access list needs to be created in order to match traffic which needs to be sent via the VPN tunnel, this ACL will be referenced in our crypto map.  In this particular example we don't require a split tunnel as all traffic is designed to go to via head office, this makes the ACL much simpler.

access-list 100 remark VPN ACL
access-list 100 permit ip 10.251.6.0 0.0.1.255 10.180.0.0 0.0.255.255
access-list 100 permit ip 10.251.6.0 0.0.1.255 10.177.0.0 0.0.255.255


This ACL will match the traffic coming from the local subnet to the two destination subnets and send it via the tunnel (in a line listed below).  One thing to note is that the ACLs on both ends must match (i.e. ASA ACL must match in reverse) or the tunnel wont work properly.




STEP 2 - ISAKMP Policy
In this step we need to exactly (except for policy ID) match the attributes to what we selected in the ASA.  Obviously the IP address is the outside address of the ASA (changed in this example)

crypto isakmp policy 35

encr aes

authentication pre-share

group 5

cypto isakmp key ***** address 203.38.18.222

STEP 3 - ISAKMP Policy

In this step we match the tansform set that we specified in the ASA. This transform set will be referenced in our crypto map.


crypto ipsec transform-set LABRADOR esp-aes esp-sha-hmac

STEP 4 - Crypto Map

 

L2L VPN Config *** ASA section ***

Background information

Have two sites which require a L2L VPN tunnel.  One is a head office/data center location running a ASA firewall and the other one is a remote branch office using a Cisco Router.  The config covered below assumes that both the router and the firewall already have a basic working configuration.  Details below:

Remote Office

Location: Badell, Singapore

Device: 1841 with adventerprisek9-m 12.4(25d)

LAN: 10.251.6.0 /23

WAN: 124.66.16.231

Head Office

Location: Sydney, Australia

Device: ASA 5540 with ASA software v 8.2(2)

LAN: all private ranges

WAN: 203.38.18.222

[INSERT DIAGRAM HERE]

STEP 1 - NAT and ACLS

The first steps are to do with creating (or modifying existing) NAT rules and access-lists in order to control which traffic is allowed to go through the tunnels and wether it is NAT'ed or not

STEP 1.1 - ACL modification to allow traffic past the inside ACL

The 'inside' ACL will have to be modified to allow the appropiate head office subnets access to the remote LAN.  In the example below badell_deg is an object-group with the internal or head office side subnets and badell_singapore_lan is a object-group with the remote LAN's subnet.


access-list acl_in extended permit ip object-group baddell_deg object-group baddell_lan

STEP 1.2 - New ACL to match traffic to be encrypted (referenced in tunnel group)

Later configurations sections require an ACL to match the source and destination of traffic which is to be encrypted.  The same object-groups as above were used.

access-list BADELL_VPN extended permit ip object-group baddell_deg object-group baddell_lan

STEP 1.3 Make sure tunnel bound traffic is not NAT'ed

An ACL needs to get created to match traffic which we do not want to be NAT'ed. note: there may be a pre-existing 'NONAT' ACL already.

access-list NONAT remark ** match DEG subnets to the Badell (Singapore) site **

access-list NONAT extended permit ip object-group baddell_deg object-group baddell_lan

If there is not an existing 'NONAT' ACL we'll also have to create a nat 0 statement which references the interface where traffic is coming from and the ACL name. note: the zero (0) code means do NOT nat.

nat (inside) 0 access-list NONAT

 

The following PAT (code 1) statement will do a global nat with anything that doesn't match the nonat ACL above.  This line will probably already be there and is not strictly required for VPN operation.

nat (inside) 1 10.0.0.0 255.0.0.0

STEP 2 - VPN CONFIG

STEP 2.1 - Crypto isakmp policy (phase 1) key exchange

This is what first greets other devices trying to connect to the ASA and attempts to negotiate phase 1.  In theory one ISAKMP policy could be sufficient to catch all VPN tunnels, however in practice not all devices support a standard set of attributes.  In most cases you'll have many policies (or as many as required) with slightly different policy attributes eg. 3des instead of aes or sha instead of md5.  

Connecting devices will go down the list of policies sequentially until it finds a set of attributes which match it's own. The following shows an example of a ISAKMP policy:

crypto isakmp enable outside

crypto isakmp policy 1

  authentication pre-share

  encryption aes

  hash md5

  group 1

  lifetime 86400

STEP 2.2 - Crypto ipsec transform set

This is a step which negotiates phase 2 encryption attributes. As with the isakmp policy many transform sets may be required in order to cover all VPN tunnels. (write more about he two attributes). The following line shows an example of a transform set:

crypto ipsec transform-set STANDARD esp-aes esp-sha-hmac

STEP 2.3 - Tunnel group

The tunnel group IP address refers to the remote WAN IP - **** refers to the PSK (ASA hides by default)

tunnel-group 124.66.136.122 type ipsec-l2l

tunnel-group 124.66.136.122 ipsec-attributes

  pre-shared-key ****

STEP 2.4 - Crypto map

The crypto map config ties in all the different VPN tunnel configuration sections. The first line defines a name (the word tunnel is a variable) and specifies an interface, in this case outside.

crypto map tunnel interface Outside

crypto map tunnel 10 match address BADELL_VPN
(one thing to note is the ASA will tell you config is not complete here)

crypto map tunnel 10 set peer 124.66.16.231
crypto map tunnel 10 set transform-set STANDARD

Final Steps

The firewall must have a route which directs traffic destined to the remote office LAN via the outside interface of the firewall.  In the example below the whole 10.251.0.0 /16 range (VPN range) has been diverted to the outside interface.

route Outside 10.251.0.0 255.255.0.0 203.58.41.254 1

...Router side config to follow in the next post.