This is key, the Portmaster will ignore replies from the host running RADIUS
if the packets are coming from an address other than the address set in the
global settings for the RADIUS host. This would be consistent with the
"requester address mismatch" message you are receiving.
To watch the return RADIUS packets use the following:
This packet filter will show all RADIUS packets returning to the Portmaster.
It will NOT show RADIUS packets orginating from the Portmaster.
This is a very useful tool in debugging RADIUS problems. If the RADIUS
packet is returning from an ip address that differs from the ip address (or
the ip address of the hostname) that appears for the RADIUS server with the
"show global" command, then the packet is discarded.
Command> add filter r
New Filter successfully added
Command> set filter r 1 permit udp src eq 1645
Filter r updated
Command> set console
Setting CONSOLE to admin session
Command> ptrace r
Packet Tracing Enabled
# Example ptrace output
UDP from 192.168.1.2.1645 to 192.168.1.6.1026
UDP from 192.168.1.2.1645 to 192.168.1.6.1026
UDP from 192.168.1.2.1645 to 192.168.1.6.1026
UDP from 192.168.1.2.1645 to 192.168.1.6.1026
To turn off...
Command> ptrace
Packet Tracing Disabled
Command> reset console
Console RESET
At 02:43 PM 9/6/96 EST, you wrote:
>On numerous occasions, in an unpredictable manner, the PM in question
>will fail over to the alternate authentication host, which is on our
>main network and as yet does not have the users the remote PM serves
>in it's UAF file. The result is that several times a day, the users
>this POP serves are unable to login, and receive the "Invalid login"
>message. Very frustrating for them and us. No amount of power cycling,
>rebooting or other coaxing seems to help. The CPU and network at the
>site are very lightly loaded, and radiusd *is* running. TCPDUMP on the
>remote network reveals that the PM is sending the radius requests, and
>the CPU is sending back replies. The PM, however, seems to be ignoring
>these replies and repeats it's request several times and then tries
>the alternate auth host.
>All of this worked fine until a few days ago, and there have been no
>changes to the PM or the auth CPU. Note that it does not do this all
>the time. It will insist on consulting the alternate auth host for
>a while (10 or 20 mins, maybe) and things will be fine for several
>hours. No noticable pattern.
>
>Nothing appears in the logfile except for the occasional complaint
>about "requester address mismatch" ... this is rather odd in itself,
>and does not seem to coincide with the unwanted failovers in
>authentication. The IP address it says the request is coming from is
>a valid one for our network, but is not in use at the remote site, and
>has never been associated with the PM in question.
--- jstorms@livingston.com So much to do, so litt...[Hold on a sec]