A few years ago, when I was learning about the Cisco ASA, I discovered how different it was from the Cisco IOS – there were a list of features that were unsupported on this device and BGP was one of them. Things have changed now because as of ASA software version 9.2(1) and BGP is now supported on the Cisco ASA. We will consider this new feature in another article but, in this article, we will configure the ASA in such a way that BGP sessions can be formed across/through it.

We will look at different scenarios, but the basic setup will be as shown below:

The basic configuration on the devices is as follows:

hostname R1
!
interface FastEthernet 0/0
ip address 192.168.10.2 255.255.255.0
!
interface Loopback 0
ip address 1.1.1.1 255.255.255.255
!
ip route 0.0.0.0 0.0.0.0 192.168.10.1
hostname ASA
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 192.168.20.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.10.1 255.255.255.0
hostname R2
!
interface FastEthernet 0/0
 ip address 192.168.20.2 255.255.255.0
!
interface Loopback 0
 ip address 2.2.2.2 255.255.255.255
!
ip route 0.0.0.0 0.0.0.0 192.168.20.1

Scenario #1: iBGP through Cisco ASA

In this scenario, both BGP neighbors (R1 and R2) are in the same AS, i.e., AS1. The scenario diagram is shown below:

In pre-8.3 ASA software versions, there was a concept of NAT control – if NAT control was enabled, then packets from a higher security level interface to a lower security level interface needed to match a NAT rule. With the newer versions of the ASA software, where NAT control has been deprecated, you don’t really need to do anything special to bring your BGP sessions up between the routers.

The BGP configuration on R1 is as follows:

router bgp 1
 network 1.1.1.1 mask 255.255.255.255
 neighbor 192.168.20.2 remote-as 1

The BGP configuration on R2 is as follows:

router bgp 1
 network 2.2.2.2 mask 255.255.255.255
 neighbor 192.168.10.2 remote-as 1

Even after this configuration, the BGP session will not come up, but this is not a problem with the Cisco ASA. If we debug BGP on R1, we see the problem:

The problem is that you need a more specific route towards the BGP neighbor than a default route. Therefore we can add the following routes on the routers:

R1:

ip route 192.168.20.2 255.255.255.255 192.168.10.1

R2:

ip route 192.168.10.2 255.255.255.255 192.168.20.1

Note that you don’t need a host (/32) route; it just has to be longer than a default route. With these static routes now, the BGP session comes up:

Keep in mind that, with this default configuration on the ASA, only R1 can initiate the BGP session to R2. We can confirm this from the local/foreign host section of the show ip bgp neighbors command output on R1 – the initiator will have a high-range TCP port; the responder will have a TCP port of 179:

If R2 tried to initiate the BGP session, it will be denied by the ASA because the packet is flowing from a lower security interface (outside with security level of 0) to a higher security interface (inside with security level of 100).

To allow both peers to be able to initiate the BGP session, we need to permit BGP (i.e. TCP port 179) through the ASA on the outside interface. The configuration is as follows:

access-list OUTSIDE_IN extended permit tcp host 192.168.20.2 host 192.168.10.2 eq bgp
access-group OUTSIDE_IN in interface outside

To confirm that this works, I can clear the BGP session on R2 and after the BGP session is re-established, we can check the show ip bgp neighbors command output on R1 again:

Notice that this time R1 is the responder (TCP port 179) while R2 initiated the session (TCP port 32793).

Scenario #2: EBGP with NAT

In this scenario, R1 and R2 will establish an EBGP peering relationship.

We will configure the ASA to translate the real IP address of R1 (192.168.10.2) to a mapped IP address (192.168.20.10). The configuration for that on the ASA is as follows:

object network R1
 host 192.168.10.2
 nat (inside,outside) static 192.168.20.10

The configuration change on R1 is as follows:

router bgp 1
 no neighbor 192.168.20.2 remote-as 1
 neighbor 192.168.20.2 remote-as 2
 neighbor 192.168.20.2 ebgp-multihop

The configuration change on R2 is as follows:

no router bgp 1
router bgp 2
 neighbor 192.168.20.10 remote-as 1
 neighbor 192.168.20.10 ebgp-multihop 2
 network 2.2.2.2 mask 255.255.255.255

There are only two things to note in this configuration:

  1. On R2, we use the mapped address of R1 (i.e., 192.168.20.10) in the BGP neighbor statement.
  2. We need to use the ebgp-multihop command because the ASA is considered as one hop and, by default, EBGP peers should be directly connected.

Scenario #3: BGP authentication

When dealing with BGP authentication that needs to pass through an ASA, there are some things to be considered. First, we need to disable NAT between the peers. If you must use NAT, then it must be an identity NAT, i.e., you cannot change the IP address of any of the BGP peers. This is because the IP address is used to compute the MD5 hash used for authentication; changing it means authentication will fail.

Also, although the TCP MD5 option is now obsolete, it seems Cisco’s implementation of BGP authentication still uses that TCP option to carry authentication information. Therefore, we need to make sure that the ASA does not rewrite the TCP MD5 option (option 19) used to carry the MD5 authentication.

Finally, since the TCP header is also used in producing the MD5 authentication hash, then that TCP header must remain unchanged. The problem, however, is that, by default, the Cisco ASA randomizes initial sequence numbers, so we need to disable this (for BGP sessions).

The configuration on the ASA to achieve the three requirements above is as follows:

! Remove previous NAT configuration
no object network R1
!
! Allow TCP MD5 option
tcp-map TCP_MAP_BGP_MD5
  tcp-options range 19 19 allow
!
! Disable TCP sequence number randomization for BGP session
access-list MATCH_BGP permit tcp host 192.168.10.2 host 192.168.20.2 eq bgp
access-list MATCH_BGP permit tcp host 192.168.20.2 host 192.168.10.2 eq bgp
!
class-map CLASS_BGP_MD5
 match access-list MATCH_BGP
!
policy-map global_policy
 class CLASS_BGP_MD5
  set connection advanced-options TCP_MAP_BGP_MD5
  set connection random-sequence-number disable
!
service-policy global_policy global

On R1, we will enable authentication under the BGP process with the following command:

neighbor 192.168.20.2 password cisco

.

On R2, the necessary configuration changes are as follows:

router bgp 2
 no neighbor 192.168.20.10
 neighbor 192.168.10.2 remote-as 1
 neighbor 192.168.10.2 ebgp-multihop 2
 neighbor 192.168.10.2 password cisco

With this configuration, the BGP session is established between R1 and R2. We can confirm this from the show ip bgp summary command on R1:

Summary

In this article, we have seen how BGP sessions can be formed across a Cisco ASA. As long as there is no NAT control, then BGP sessions can be formed normally, without any special configuration on the Cisco ASA. If a BGP peer on a lower security interface should be allowed to initiate the BGP session, then this must be permitted in an access list.

The main issue comes when authentication is used in BGP. In such cases, we need to disable NAT between peers (or configure identity NAT), disable TCP sequence number randomization, and disable TCP MD5 option rewrite.

I hope you have found this article insightful. In another article, I will discuss BGP configuration on the Cisco ASA itself.

Further Reading