TACACS+ configuration using freeRtr. This is about configuring authentication using the TACACS+ protocol. Authorization and Accounting are easy to set up once Authentication is working, but are not part of this netlab.

This is a configuration from scratch. freeRtr usage for the first time, no experience at all. TACACS+ freeRtr authentication.

The official freeRtr appliance is available here, or can be simply installed using the GNS3 marketplace or the GNS-gui import appliance function.

IP addressing

The IP addressing used in this netlab. 3 appliances:

Connections in the netlab from node-10 to R104 using telnet client.

TACACS+

This netlab is using the TAC_PLUS-NG server project from Event-driven servers.

Version of TACACS+NG:

TACACS daemon IP settings, this time the TACACS+ daemon is running on standard port 49. The reason behind is simple. The tac_plus client implemented on freeRtr has no AAA daemon TCP port configuration option, to test authentication the daemon runs on standard TCP port 49.

Preconfigured tac_plus-ng.cfg settings for user authentication:

The basic TACACS+NG configuration used in this example, has been explained in previous netlabs. For more details about the configuration read following articles:

• 01 - TAC PLUS-NG-Configuring basic authentication
• 02 - TACACS+NG PAP-CHAP authentication for AOS-CX
• 03 - Configuring TACACS+NG authentication for EXOS
• 04 - Configuring TACACS+NG authentication for VRP

TACACS+NG configuration

Pre-configured tac_plus-ng.cfg file for this netlab. AAA daemon configuration ready to use:

#!/usr/sbin/tac_plus-ng
id = spawnd {
    listen = { address = 0.0.0.0 port = 49 }
}

id = tac_plus-ng {

        host IPv4only {
            address = 0.0.0.0/0
            welcome banner = "\n Welcome to TACACS+NG\n\n"
            key = 123-my_tacacs_key
    }

    profile netadmin {
            script {
                    if (service == shell) {
                            if (cmd == "") {
                                    set priv-lvl = 15
                                    permit
                            }
                    }
            }
    }

    group admin

    user cisco {
    password {
        login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
        pap   = crypt $2y$10$NtwT2Cp/fjezs109gGsVdeyU4Am4q2j1IJ219/mMy.k29xNd9XXU2
        chap  = clear auth-chap

    }
        member = admin
    }

    ruleset {
                rule {
                        script {
                            if (member == admin) { profile = netadmin permit }
                        }
                }
        }
}

freeRtr configuration

The configuration is taken from the standard tests performed by the freeRtr project:

• freeRtr - interop1 TACACS+ test
• freeRtr - server TACACS+ test

Both test examples have TACACS+ protocol configured. The latter of both examples, looks like freeRtr is has simple Authentication implemented. There is also a 3-rd test listed which deals with PPP and PAP authentication. I have taken both as a configuration example to construct this router configuration here explained. The freeRtr documentation is really not to find. The selftest are the only full available collection of particlular protocol configuration examples for freeRtr. It is the best of documentation at the moment you can gat. This all steps described below are based on the 2 upper test scenarios.

freeRtr version used in this netlab

IP addressing

This is the freeRtr IP adressing setup:

• Hostname R104
• Address 10.100.100.104/24
• Gateway 10.100.100.1

Basic router IP configuration:

configure
!
hostname R104
!
vrf def v1
 rd 1:1
 exit
int eth1
 vrf for v1
 ipv4 addr 10.100.100.104 255.255.255.0
 exit
ipv4 route v1 0.0.0.0 0.0.0.0 10.100.100.1
!
exit
wr

Verify IP connectivity with the TACACS+ daemon, from the router:

IP connectivity is established. Note the usage of the vrf v1 in example.

freeRtr does not have a concept of a default IP routing table. Out of the box, freeRtr it does not have any IP routing tables at all, apart from the default host vrf table which is for out-of-band management purpose. IP packets sourced from the router, like the ICMP in shown example above, need to be set to a distinct local IP routing table. The only routing table created in shown example and assigned to interfaces is the vrf v1 routing table. Every working IP interface is using this particular IP routing table.

To define a default IP routing table configure following. Create a proxy-profile named p1, assing a routing table to the proxy-profile vrf v1.

configure
proxy-profile p1
 vrf v1
end

Finally configure the router to send all client IP requests, or all localhost sourced client requests using the proxy p1 profile:

configure
client proxy p1
end

This way a symlink is defined to a default to be used, target IP routing table. This is a global configuration setting setting shown client proxy p1. The configuration example shown is the most generic way of configuring this. In case someone in future, searching for freeRtr examples, reads this and is in search for a generic working solution for IP packets sourced from this router.

Note. It is possible configure the proxy p1 symlink directly in the AAA-1service in the freeRtr configuration, skipping the global configuration shown. This is not used here, to make the freeRtr configuration example simple as it can get. Without special treatment.

Verify IP connectivity. Now note there is no vrf option added. All IP packets use the vrf v1 as the default IP routing table:

freeRtr TACACS+ configuration

The freeRtr TACACS+ configuration. freeRtr authentication configuration consist of following configuration parts:

• AAA daemon template AAA-1
• Telnet service R104-T
  • login authentication AAA-1
  • IP table binding vrf v1

This results in following configuration for the authenticating users:

configure
!
aaa tacacs AAA-1
 secret 123-my_tacacs_key
 server 192.0.2.1
exit
!
server telnet R104-T
 login authentication AAA-1
 vrf v1
 exit
end
wr

This is the most basic authentication configuration for freeRtr. As noted already at the beginning, the TACACS+ client requests target the TCP port 49 per default. The implemented client here has no configuration option to change the TACACS+ daemon running TCP port.

Now the authentication can be tested.

Verify

Using the TACACS+ client, telnet to the router, and authenticate using the previously configured credentials:

After successful authentication, show the configured AAA service and its statistics:

The authentication is bound to AAA-1. 3 times OK. The show users output displays the authenticated users, connection related data and the time:

And while the test from the client succeeds, the freeRtr line tty1 shown above on the freeRtr will print following:

This is when a authenticated telnet session starts:

A universal command showing protocols and connections on freeRtr, without the need for CLI specific commands to list services:

TACACS+NG debug

Authentication debug output from authenticates on the NAS. freeRtr uses the ASCII method, now correctly shown authenticating user is cisco, without the domain part, resulting in a succeeding authentication:

Now that is all folks! Now you can and configure authorisation and accounting to have all the A's configured and working.

The authentication succeeds and it is easy to setup

freeRtr full config

Full working router configuration used in this netlab.

!freeRouter-rare v23.6.27-cur
!   
configure
hostname R104
!
vrf definition v1
 rd 1:1
 exit
!
aaa tacacs AAA-1
 secret 123-my_tacacs_key
 server 192.0.2.1
 exit
!
interface ethernet1
 vrf forwarding v1
 ipv4 address 10.100.100.104 255.255.255.0
 no shutdown
 no log-link-change
 exit
!
proxy-profile p1
 vrf v1
 exit
!
ipv4 route v1 0.0.0.0 0.0.0.0 10.100.100.1
!
server telnet R104-T
 security protocol telnet
 login authentication AAA-1
 vrf v1
 exit
!
client proxy p1
!
end

The router has no local users defined. All authenticating users on this router are requested at the AAA-1 TACACS+NG server.

Summary

The freeRtr TACACS+ authentication works, and is easy to setup too. At least the authentication part. 5 different tac_plus clients have been tested, and all work using TACPLUS-NG. This is great.

I must admit there is hardly documentation out there to find. And if you are not experienced in networking protocols and configuration, freeRtr is not easy to setup at first as a GNS3 appliance.

So in a case anyone wants a very basic freeRtr router authentication example, here it is. All components used in this particular AAA netlab here, are free software.

• freeRtr
• alpine-linux
• TACACS+NG
• GNS3
• QEMU

Finally, this is the first netlab, where a freeRtr GNS3 appliance is used. A specific use case, or more a test scenario is given, and it is interesting to find out which parts of the TACACS+ AAA protocol are actually implemented and working in freeRtr. You will not find any documentation about this specific topic, potentially somewhere on some mailing-list. The 3212 working freeRtr tests scenarios selftests are the only way to find something useful about this router.

There is also one official documentation source RARE/freeRtr documentation pages The self-test are depicted there with, the website is a bit sluggish and to over-engineered IMHO, maybe having to few ressources to depict the topology visualisation, or maybe this is only my browser here. Here the positive and more important topics, this website is a valuable source of documentation and the 1-st place to search about freeRtr related topics.

• Network topology
• Router configuration
• Test result

4 picked examples:

• Example: RIP triangle connection
• Example: OSPF with BGP linkstate
• Example: integrated IS-IS chain of broadcast nets
• Example: Babel with BFD

The list is big and reviewing this list, there is not much more to add to, when judging by the protocols usage. freeRtr requires much CPU/MEM ressources to run, but compared with all other GNS3 appliances, it boots blazingly fast, and is usable within 10 seconds after start. It is the fastest booting GNS appliance used here, and most flexible. FreeRtr can be turned from CLI only into: RADIUS server, TACACS+ daemon, PPP termination device, IRC server, Authentication server, Authorization server, Syslog server... the list is long. Protocol centric server appliance. Check it out, maybe it is something you never thought of it is.

References

• freeRtr - github
• RARE/freeRtr documentation - freeRtr self-test with visualisation
• freeRtr - interop1 TACACS+ test
• freeRtr - server TACACS+ test
• Event-driven servers - TAC_PLUS-NG server project

Related TACACS+NG posts:

• 01 - TAC PLUS-NG-Configuring basic authentication
• 02 - TACACS+NG PAP-CHAP authentication for AOS-CX
• 03 - Configuring TACACS+NG authentication for EXOS
• 04 - Configuring TACACS+NG authentication for VRP