We are setting up a new radius server and replacing several existing servers. During the transition we set a second ip address on eth0:1 on one of the new servers so that it would respond to radius and DNS queries in place of the retired server at its old ip address. We have been trying to debug an authentication issue with our vpop provider. Looking at the debug trace all appeared to be well. rad_recv: Access-Request packet from host 216.113.192.27:51209, id=131, length=170 User-Name = "name@domain.com" User-Password = "secret" NAS-IP-Address = 207.194.241.33 NAS-Identifier = "PGRGBC01AS01.provider.com" NAS-Port = 1189 NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP State = 0x Calling-Station-Id = "2505674819" Called-Station-Id = "5674831" Acct-Session-Id = "425788824" Ascend-Data-Rate = 31200 Ascend-Xmit-Rate = 46667 Processing the authorize section of radiusd.conf ...... rlm_ldap: user name authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 2 modcall: leaving group LDAP (returns ok) for request 2 Login OK: [name] (from client uniserv.2 port 1189 cli 2505674819) Sending Access-Accept of id 131 to 216.113.192.27 port 51209 Finished request 2 Going to the next request But the Windows DUN client would fail with a Error 691 Looking at a tcpdump of the traffic between the servers we see... [root@host raddb]# tcpdump -nn host 216.113.192.27 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 10:04:02.675842 IP 216.113.192.27.51209 > 204.244.116.2.1645: RADIUS, Access Request (1), id: 0x7e length: 171 10:04:02.680874 IP 204.244.116.14.1645 > 216.113.192.27.51209: RADIUS, Access Accept (2), id: 0x7e length: 20 10:05:20.101253 IP 216.113.192.27.51209 > 204.244.116.2.1645: RADIUS, Access Request (1), id: 0x7f length: 171 10:05:20.106329 IP 204.244.116.14.1645 > 216.113.192.27.51209: RADIUS, Access Accept (2), id: 0x7f length: 20 Notice the request comes to the aliased address but the reply comes from the real address of the port. Is this a configuration error, normal behavior, or a bug? Looking at other services such as DNS the reply comes back from the target ip address and port. Issue was resolved by having our vpop provider put in the proper addresses.