Skip to main content

ASA - transparent firewall on 8.3 and 8.4

I need to implement a transparent firewall between r1 and r2. Ping and bgp session have to be allowed.


  10.0.0.1        10.0.0.100          10.0.0.2
  /----\            -----             /----\
 |  R1  |----------| ASA1 |----------|  R2  |
  \----/            -----             \----/

          vlan10 ---->| <---- vlan20                    


1) Cisco Adaptive Security Appliance Software Version 8.3(1)

First I configure min requirements to allow on bgp session between r1 and r2

R1:
 
!
interface GigabitEthernet0/0
  ip address 10.0.0.1 255.255.255.0
!
router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
!  

R2:
 
!
interface GigabitEthernet0/0
  ip address 10.0.0.2 255.255.255.0
!
router bgp 65001
 neighbor 10.0.0.1 remote-as 65001
!  

ASA is in ‘transparent mode’:

ASA1:
 
!
firewall transparent
hostname asa1
!
!
interface Ethernet0/0.10
 vlan 10
 nameif outside
 security-level 0
!
interface Ethernet0/1.20
 vlan 20
 nameif inside
 security-level 100
!
access-list BGP extended permit tcp any any eq bgp 
access-group BGP in interface outside
access-group BGP in interface inside
!
ip address 10.0.0.100 255.255.255.0

Now we can check the bgp status:
 
r1#show ip bgp summary 
BGP router identifier 10.0.0.1, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4        65001      38      38        1    0    0 00:31:10        0
r1#
 
 
r2#sh ip bgp summary 
BGP router identifier 10.0.0.2, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4        65001      38      38        1    0    0 00:31:00        0
r2#

 and confirm the traffic is going through the firewall:
 
asa1# sh conn
1 in use, 3 most used
TCP outside 10.0.0.1:179 inside 10.0.0.2:13761, idle 0:00:27, bytes 238, flags UIO
asa1# 
asa1(config)# fixup protocol icmp 
INFO: converting 'fixup protocol icmp ' to MPF commands
asa1(config)# 

Now I would like to add password to authenticate peers before they set up bgp session:

r1:
 
router bgp 65001
neighbor 10.0.0.2 password cisco

r2:
 
router bgp 65001
neighbor 10.0.0.1 password cisco

Once I enabled this feature I received error message:
 
r2#clear bgp * all 65001
r2#
*Oct 22 20:24:32.381: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down User reset
*Oct 22 20:24:32.381: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.0.1 IPv4 Unicast topology base removed from session  User reset
*Oct 22 20:24:40.241: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.1(12069) to 10.0.0.2(179)
*Oct 22 20:24:42.237: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.1(12069) to 10.0.0.2(179)
*Oct 22 20:24:54.573: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.1(45215) to 10.0.0.2(179)
*Oct 22 20:24:56.573: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.1(45215) to 10.0.0.2(179)
 
r1#clear bgp * all 65001
r1#
*Oct 22 21:03:37.809: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.2(12884) to 10.0.0.1(179)
*Oct 22 21:04:03.745: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.2(33490) to 10.0.0.1(179)
*Oct 22 21:04:05.745: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.2(33490) to 10.0.0.1(179)
*Oct 22 21:04:09.745: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.2(33490) to 10.0.0.1(179)
*Oct 22 21:04:17.745: %TCP-6-BADAUTH: No MD5 digest from 10.0.0.2(33490) to 10.0.0.1(179)

The problem we see above is related to fact that ASA by default changes TCP MD5 option value and TCP sequence number is random (ASA in the middle breaks the session into two session: first between r1 and asa1 and 2nd between asa2 and r2). To allow on TCP MD5 authentication I need to add TCP-MAP:
 
!
tcp-map BGP
  tcp-options range 19 19 allow
!   

and then define class-map where I apply the TCP-MAP:
 
class-map BGP-class
 match access-list BGP
!
policy-map global_policy 
 class BGP-class
    set connection advanced-options BGP
!

Let’s test it:
 
r2#
*Oct 22 20:44:06.565: %TCP-6-BADAUTH: Invalid MD5 digest from 10.0.0.1(26643) to 10.0.0.2(179)
*Oct 22 20:44:10.565: %TCP-6-BADAUTH: Invalid MD5 digest from 10.0.0.1(26643) to 10.0.0.2(179)
*Oct 22 20:44:18.565: %TCP-6-BADAUTH: Invalid MD5 digest from 10.0.0.1(26643) to 10.0.0.2(179)
*Oct 22 20:44:40.409: %TCP-6-BADAUTH: Invalid MD5 digest from 10.0.0.1(46945) to 10.0.0.2(179)

Now the MD5 is allowed but ASA changes TCP sequence number. I need to disable it:
 
policy-map global_policy 
 class BGP-class
    set connection random-sequence-number disable
!

Let’s check the routers once again:
 
*Oct 22 21:26:06.805: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Up 
r1#
r1#
r1#sh ip bgp summary    
BGP router identifier 11.11.11.11, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4        65001       4       5        1    0    0 00:00:53        0
r1#
 
 
*Oct 22 20:47:15.873: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up 
r2#                     
r2#
r2#sh ip bgp summary    
BGP router identifier 22.22.22.22, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4        65001       4       4        1    0    0 00:00:19        0
r2#

As we see everything works fine. Now I will change software on ASA to 8.4 and I check what is required to keep the same functionality


2) Cisco Adaptive Security Appliance Software Version 8.4(4)5

The new version has some requirements for transparent feature. Like on IOS you need to create BVI interface where you add ip address.
This command is no longer support:
 
no ip address 10.0.0.100 255.255.255.0

and IP for management we can set on new BVI interface:
 
!             
interface BVI1
 ip address 10.0.0.100 255.255.255.0 
!   

Both interfaces need to belong to one of the bridge-groups, in my case to '1’:
 
interface Ethernet0/0.10
 bridge-group 1
!
interface Ethernet0/1.20
 bridge-group 1
!             

After reloading I see BGP is still working fine:
 
r2#
*Oct 22 21:05:23.577: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up 
r2#
r2#sh ip bgp summary    
BGP router identifier 22.22.22.22, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4        65001       4       4        1    0    0 00:00:12        0
r2#
 
 
r1#
*Oct 22 21:44:14.521: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Up 
r1#
r1#sh ip bgp summary    
BGP router identifier 11.11.11.11, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4        65001       4       4        1    0    0 00:00:16        0
r1#

 
asa1# sh conn
1 in use, 2 most used
TCP outside 10.0.0.1:38297 inside 10.0.0.2:179, idle 0:00:42, bytes 276, flags UIOB
asa1# 

Comments

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an

MAC Authentication Bypass

One of the method to control your network is using MAB feature. It is helpful in case you have devices without dot1x functionality. Today I will try to implement basic configuration and analyze log messages. There is only one switch SW1 and one device attached to port Fa1/0/2.   ! aaa new - model aaa authentication dot1x default group radius ! ! int Fas1 / 0 / 2 authentication host - mode single - host authentication port - control auto mab ! I haven’t configured ACS yet but let’s see what error message I receive:   SW1 ( config - if ) # mab - ev ( Fa1 / 0 / 2 ): Received MAB context create from AuthMgr mab - ev ( Fa1 / 0 / 2 ): Created MAB client context 0x1100000F mab : initial state mab_initialize has enter mab - ev ( Fa1 / 0 / 2 ): Sending create new context event to EAP from MAB for 0x1100000F ( 0000.0000 . 0000 ) mab - sm ( Fa1 / 0 / 2 ): Received event 'MAB_START' on handle 0x1100000F mab : during state mab_initia

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze the packet flo