[PTX10001-36MR] Is there any method to specify the source IP address when attempting a manual TCP connection to TACACS+

Two routers are consistently failing TACACS authentication

We have routes to reach the TACACS server

ICMP working correctly

Other routers in the same subnet successfully authenticating to the same servers

On the working routers, TACACS authentication succeeds and logs appear as expected:

Dec 22 2:24:56 working-router mgd[22358]: UI_AUTH_EVENT: Authenticated user 'test' assigned to class 'SUPER-USER'

On the affected routers, the router falls back to local PAM authentication, indicating that no TACACS+ reply is being received and possibly no TACACS request is being sent:

Dec 22 2:30:00 non-working-router sshd[2350]: pam_unix(sshd:auth): check pass; user unknown

Dec 22 2:30:00 non-working-router sshd[2350]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.17.46.164

Dec 22 2:30:00 non-working-router sshd[2350]: pam_unix(sshd:auth): check pass; user unknown

Dec 22 2:30:01 non-working-router sshd[2000]: error: PAM: Authentication failure for test from 10.17.46.164

Dec 22 2:30:01 non-working-router sshd[2000]: notice: Login failed for user 'test' from host '10.17.46.164' [preauth]

There is not a valid Junos command in PTX10001-36MR to specify source IP address for manual TCP connection to TACACS+

We verified this in a lab device, I can see that PTX10001-36MR is using Yocto,

labroot@jtac-ptx10001-36mr> start shell user root  

Password: 

[vrf:none] root@jtac-ptx10001-36mr:~# 

[vrf:none] root@jtac-ptx10001-36mr-:~# uname -a

Linux jtac-ptx10001-36mr-5.2.60-yocto-standard-g1426a22 #1 SMP PREEMPT Thu Nov 14 07:31:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

On Yocto-based Linux (like your kernel 5.2.60-yocto-standard-g1426a22), the built-in client is usually very minimal and does not support binding a source IP or source port. So, you cannot do it directly. But you can do it using netcat (nc).

nc -s <source_ip> -p <source_port> <destination_ip> <destination_port>

I tested the linux command without specifying the source port.

[vrf:none] root@jtac-ptx10001-36mr-:~# nc -s 10.219.38.146 10.32.192.46 49

While running the above command I was monitoring the management interface, as we can see below the system chooses a random port if we do not specify it (this is expected) and it is using the source IP and TACACS+ destination port.

labroot@jtac-ptx10001-36mr-> monitor traffic interface re0:mgmt-0 no-resolve matching "port 49"   

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on vmb0, link-type EN10MB (Ethernet), capture size 262144 bytes

02:13:04.142064 IP 10.219.38.146.44358 > 10.32.192.46.49: Flags [S], seq 201867190, win 42340, options [mss 1460,sackOK,TS val 735748596 ecr 0,nop,wscale 14], length 0

02:13:05.172304 IP 10.219.38.146.44358 > 10.32.192.46.49: Flags [S], seq 201867190, win 42340, options [mss 1460,sackOK,TS val 735749626 ecr 0,nop,wscale 14], length 0

02:13:07.220311 IP 10.219.38.146.44358 > 10.32.192.46.49: Flags [S], seq 201867190, win 42340, options [mss 1460,sackOK,TS val 735751674 ecr 0,nop,wscale 14], length 0

02:13:11.252308 IP 10.219.38.146.44358 > 10.32.192.46.49: Flags [S], seq 201867190, win 42340, options [mss 1460,sackOK,TS val 735755706 ecr 0,nop,wscale 14], length 0

The above commands will help to identify if TACACS+ traffic is ingressing/egressing the router, with the above commands we realized that the problem another part of the network.