Authenticate the management users from Radius server, reachable via a routing-instance

[SRX] Authenticate the management users from Radius server, reachable via a routing-instance

[KB21085] Show KB Properties

---

SUMMARY:

Can I authenticate the management users from a Radius server, reachable via a routing-instance.

PROBLEM OR GOAL:

If the Radius server is reachable via a routing-instance, can I authenticate the management users from Radius?

SOLUTION:

Yes. The only requirement is that the inet.0 table should have at least one interface as its member. The default behavior of the device is that it uses the IP of the interface connected in inet.0 to use as its source. It cannot use the IP of the interface existing in VR as its source, even when you import the route of that interface.

root@juniper> show configuration interfaces ge-0/0/0 
unit 0 {
    family inet {
        address 10.10.10.10/24;
    }
}

Example:

All the interfaces are members of VR and Radius configuration is as follows: 

root@juniper>show system radius-server 
10.10.10.11 secret "$9$dkw4aUjHqfTdbJDkqzF9ApORSeK8db28LbY"; ## SECRET-DATA

If there is no IP as part of inet.0 then the device will display the following message:

sshd: sendmsg to 10.10.10.11(10.10.10.11).1812 failed: Can't assign requested address

These are the cases where the customer is running short of physical interfaces, and they do not want to assign any physical IP as part of inet.0 table; we need to have a minimum of one interface in inet.0

In such a scenario you can configure a Loopback IP in the inet.0. The SRX will take the IP of the lo0 interface to source the traffic. Make sure you import the interface route of inet.0 to the VR as well; otherwise, the device will drop the return traffic.

root@juniper# show interfaces lo0 
unit 1 {
    family inet {
        address 1.1.1.1/32;
    }
}

Example on how to import route: 

1. Configure the policy statement:
   
   
   policy-statement inettovr {
    from {
        instance master;
        route-filter 1.1.1.1/32 exact;
    }
    then accept;
}



2. Export this in inet.0:
   
   
   #set routing-options instance-export inettovr


3. Import this in VR testVR:
   
   
   set routing-instances testVR routing-options instance-import inettovr

To add more, if you use the lo0 IP just to initiate the traffic to Radius and you do not want to disclose this IP to the Radius server, then you can configure source-based NAT or interface-based NAT depending on requirement.

root@srx# show security nat source 
pool dummy {
    address {
        10.10.10.10/32;
    }
}
rule-set 1 {
    from routing-instance default;
    to interface <interface that connects to radius>;
    rule 2 {
        match {
            source-address 1.1.1.1/32;
            destination-address 10.10.10.11/32;
        }
        then {
            source-nat {
                pool {
                    dummy;
                }
            }
        } 
    }
}

Note: If you use the source as VR interface for UAC or sending syslog, you will encounter the same issue and you will have to resolve this by configuring a lo0 interface to initiate traffic.