ASA Transparent mode NAT

The ASA transparent mode acts as a bump in the wire (Placed in the layer 2 path of the traffic). There is no interface IP addressing with transparent mode. The ASA can be assigned an IP address for remote management and testing. In the transparent mode, there are still access rules and inspection rules. There are a few exceptions though. For instance, ARP and BPDU is allowed from lower security level interfaces by default.

With the ASA 7.x code and lower, the ASA did not support address translation in transparent mode. In fact, the 'nat' and 'global' commands were disabled. The static command was available but the real and translated addresses must be the same. IMO, the command was enabled so that the static options can be used. An example would be the 'norandomseq' keyword that is used in BGP authentication.

With the ASA code 8.x code, there is now support for NAT in transparent mode.
The NAT implementation has a few caveats:
1. The alias command is NOT supported.
2. Since there is no interface address, interface PAT is not allowed.
3. Arp Inspection is not allowed
4. Since the inside and outside interfaces are on the same 'subnet', if any of the addresses (real or translated) is NOT on the subnet, then static routes have to be used to point to the address so that routing can take place. This is from the configuration guide:

"When the mapped addresses are not on the same network as the transparent firewall, then on the upstream router, you need to add a static route for the mapped addresses that points to the downstream router (through the security appliance)

If the real destination address is not directly-connected to the security appliance, then you also need to add a static route on the security appliance for the real destination address that points to the downstream router. Without NAT, traffic from the upstream router to the downstream router does not need any routes on the security appliance because it uses the MAC address table. NAT, however, causes the security appliance to use a route lookup instead of a MAC address lookup, so it needs a static route to the downstream router."

With the Routing fixed, NAT with the ASA transparent mode should not be too different from the regular routed mode NAT.

Further Reading:
ASA Configuration Guide: NAT in Transparent mode
Amplebrain

ASA Cut-Through Proxy Part 2: Radius Authorization

AAA Authorization and Authentication are two separate processes. Authorization must be performed after Authentication has taken place. That makes sense because we have to know who the user is before we can know what he can do right?

While User Authentication and Authorization are separate processes, they are implemented together in the RADIUS server. The User is Authenticated and downloadable access-lists are used to perform Authorization for the user.
From a configuration perspective, no further authorization command is needed on the ASA as the authentication and authorization is performed at once on the RADIUS server.

From the radius server perspective, there are two ways to accomplish authoriztaion.

1. The radius server can reference an ACL configured on the ASA which is now 'activated' after the user has authenticated. In this case, the access-list name is specified under the radius attribute 11 (filter-id). The access-list can also be specified under the cisco AV pair (009,001) attribute.


2. The Access-list entries can be defined on the ACS server and downloaded unto the ASA after the user has authenticated.
Downloadable access-lists can be created on the server using the Advanced downloadable access-list features, (This must be activated from the Interface configuration tab). Check the box for "group-level downloadable access-lists"

The other option is to specify the access-list entries in the cisco-av-pair using the "inbound access-list" syntax.

ip:inacl#[acl-line-number]=[acl permit/deny statement] for example:

ip:inacll#1=permit ip any any



Note that there must be an authentication protocol for authorization to work, if none of the authentication protocols (telnet, http(s) or ftp) is configured, then the virtual telnet/http command should be used.



Consider the following same topology as the previous post;

R1 --- (inside)ASA(outside) -- R2 where the Radius server is on the inside interface.

The user would be authorized to telnet from the outsude interface to R1 on port 3070.



1. Configure the authentication AAA server on the ASA.

aaa-server ACS protocol radius

aaa-server ACS (inside) host 10.10.10.5

key bauxite



2. Configure the Authentication access-list


access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

virtual telnet 2.2.2.2




3. Since it is on the outside the access-list must be configured to allow the authentication traffic:



access-list OUTSIDE_IN permit tcp any host 2.2.2.2 eq telnet

access-group OUTSIDE_IN in interface outside



4. Configure AAA for authentication


aaa authentication match AUTH inside ACS




5. Configure the AAA server: To keep things simple, we would define the access-list test_auth on the ASA and then refer to it through the filter-id attribute of the RADIUS server:



access-list test_auth extended permit tcp any any eq 3070

access-list test_auth extended permit tcp any host 2.2.2.2 eq telnet



The 2nd line of the acl is added so that the telnet session for authentication does not die after the authorization has taken place on the ASA. If the telnet session is not allowed by the authorization acl, though authorization would still take place, the telnet session would die immediately after the user is authorized and an error would be returned (though the process was successful), we would rather add the line for sanity sake. :-)



On the Radius server:



6. Enable Per-user override on the inbound access list on the outside interface;

This makes the downloaded access-list take precedence over the existing interface access-list
access-group OUTSIDE_IN in interface outside per-user-override



7. Verification


Enable telnet on port 3070 on R1



line con 0

rotary 70

password cisco





Before Authorization:



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ...

% Connection timed out; remote host not responding



R2#telnet 2.2.2.2

Trying 2.2.2.2 ... Open



LOGIN Authentication



Username: Amplebrain



Password:




Authentication Successful




[Connection to 2.2.2.2 closed by foreign host]



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ... Open




User Access Verification



Password:

R1>




Show User Authentication on the ASA


ASA#sh uauth


Current Most Seen


Authenticated Users 1 1

Authen In Progress 0 1

user 'Amplebrain' at 192.168.1.2, authenticated

access-list test_auth (*)

absolute timeout: 0:05:00

inactivity timeout: 0:00:00


As I mentioned earlier, Authorization can also be accomplished using the tacacs+ protocol but this is implented entirely differently. I hope to put up a post on this sometime in the future.



Anyway, this is the last technical post for the year 2009!



Wishing everyone a prosperous 2010...Cheers!


Amplebrain

ASA Cut-Through Proxy: Part 1

In the previous post, I discussed the IOS Authentication Proxy and hw it is used for 'authorization' using downloadable access-lists. In this post, I would describe the Cut-through proxy feature of the ASA.

The Proxy Authentication feature of the ASA is tied to the AAA process.
Authentication proxy can be configured for any protocol but authentication is performed by the telnet, http, https and FTP protocols. If any other protocol is requires authentication, one of the other "authentication protocols" (ftp, http(s) or telnet) MUST also be configured to authenticate the user before access can be granted.
Once a protocol is configured for authentication under the AAA process, unauthenticated users are not given access to the protocol.

The Authentication and Authorization processes are separate on the ASA.
Users can be authenticated using the local database, tacas+ server and the RADIUS server. Users can only be authorized with Radius or Tacacs+ but not the local user database.

Unlike Auth-Proxy, the traffic required for authentication MUST be allowed in the access-lists otherwise Authentication/Authorization wouldnt be able to take place. Authorization can be used to allow further traffic.

Lets look at a simple example of proxy-authentication using the local database. Assuming we have the topology:

R1 ---- (inside)ASA(outside) ---- R2

Base configuration:

interface Ethernet0
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
!

interface Ethernet1
nameif outside
security-level 0
ip address 192.168.1.1 255.255.255.0
!

1. Specify traffic to be Authenticated using an access-list

access-list AUTH extended permit icmp any any
fixup protocol icmp

The fixup protocol is used to ensure icmp traffic is inspected. (It is a quick fix compared to using the MPF). Another option would be to allow icmp inbound on the outside interface.

2. Configure AAA server: We would just add a user since we are using the local database.
username Amplebrain password cisco


3. Configure AAA on the ASA

aaa authentication match AUTH inside LOCAL
auth-prompt prompt Authenticate Before Access
auth-prompt accept Access Granted
auth-prompt reject Access Denied

The line "aaa authentication match AUTH inside LOCAL" means that traffic matched by the AUTH access-list on the inside interface must be authenticated using the local database before they can be allowed to pass through.

4. Test

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We cant reach R2. This is because we are authenticating icmp protocol but icmp is NOT one of the authentication protocols. At least one authentication protocol configured for authentication for this to work.
The ASA uses the virtual command for this.


5. Configure Virtual Telnet address and add 2.2.2.2 to the AUTH traffic

virtual telnet 2.2.2.2
access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

The authenticating user must have a route to 2.2.2.2 for this to work properly.

6. Test Again: Authenticate with virtual telnet and then ping.


R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open

LOGIN Authentication

Authenticate Before Access
Username: Amplebrain

Password:
Access Granted

Authentication Successful


[Connection to 2.2.2.2 closed by foreign host]
R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
24/88/196 ms
R1#


On the ASA, we can show authenticated users

ASA(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'Amplebrain' at 10.10.10.3, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
ASA(config)#

The next post would describe proxy-authorization using the Radius Server.

Compliments of the season :-)

Amplebrain.

Configuring BGP through the PIX/ASA.

When configuring BGP through the ASA, a basic understanding of how the ASA works and how BGP is implemented is very important. I would highlight some of my findings about the BGP/ASA relationship in this post.

1. The ASA (when in routed mode) is a HOP: This doesnt matter if we are configuring ibgp since BGP believes that the underlying IGP would take care of reachability to the neighbor but with ebgp, we need to explicitly state that the bgp neighbor is not on the same subnet. The ebgp multihop command is used to achieve this. Lets assume the following topology;

R2(f0/0) --- (ins) ASA (out) --- (f0/0) R3.

on R2 (and similarly on R3), we need to configure:

router bgp 1
neighbor 192.168.13.3 remote-as 2
neighbor 192.168.13.3 ebgp-multihop 2

When configuring ebgp multihop, we should also ensure that there is a route to the neighbor with a length greater than 0 (default route will not work) in the routing table..

Assuming we have on R2,

ip route 0.0.0.0 0.0.0.0 192.168.12.1

When we try to negotiate the BGP connection, it would fail (except R3 configured properly - which would always make R3 active). When we look at the debugs, we would see;

BGP: 192.168.13.3 active open failed - no route to peer, open active delayed 29090ms (35000ms max, 28% jitter)

But when we take a look at the routing table, sure enough, our default route is there...

R2(config-router)#do sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C 192.168.12.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.12.1

This is because the router actually searches for a route going to 192.168.13.3 and finds none.

R2(config-router)#do sh ip rou 192.168.13.3
% Network not in table

To fix this, we insert a route with a longer match in the routing table (doesnt have to be a host route, anything from a /1 would do)

R2(config-router)#ip route 192.168.0.0 255.255.0.0 192.168.12.1

That should fix things considerably and the BGP neighbor should come up.

2. The ASA does NAT: If the ASA NATs the address of the BGP peer, the neighbor statement should reflect this. Assuming we had a static statement on the ASA,
static (i,o) 192.168.13.2 192.168.12.2

Then on R3, we would peer with 192.168.13.2 instead of 192.168.12.2

neigh 192.168.13.2 remote 1

This would work well if Authentication is NOT configured.

3. Configuring BGP Authentication: BGP Authentication uses special tcp option for MD5 (option 19) to carry the Authentication information. This is stated in rfc 2385. The 16-byte MAC is computed based on a one-way hash function (MD5) generated from TCP header, the IP header, the password and a key. The following must be considered when configuring BGP authentication through the ASA:
a. Since the IP header is used in generating the hash, NAT cannot be used to change the ip address of the peers as this would break the authentication. If nat-control is enabled, the real and translated ip address must be the same.
b. Since the tcp header is used, the sequence number must not be randomized (default behavior of the ASA.) To stop randomization we can append the norandomseq option behind a static address mapping (that does not change the IP address) of the neighbor. This would only work in routed mode (of course)

static (inside,outside) 192.168.12.2 192.168.12.2 no randomseq

We can also disable random sequencing in the global_policy.

c. Finally, option 19 must be allowed to pass through the ASA for BGP traffic. This can be achieved by allowing it in the global_policy. The configuration on the ASA is shown below.

tcp-map BGP
tcp-options range 19 19 allow
!
class-map BGP
match port tcp eq bgp
!
policy-map global_policy
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
!

That would be all for now.
Further Reading

BGP through ASA configuration exmaple
RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option

Amplebrain.