Hello, i have keeplaived and lvs with 2 freerdaius servers running version 3.0.16 on redhat 7 ( keeplaived is configured with NAT option) when i send an accounting start from a client vm using radclient i get this response: radclient: Received reply to request we did not send. (id=134 socket 3) have you any idea how to resolve this issue, my freeradius servers is listenning on all interfaces ( *). Thanks a lot Mettichi Bassem
On Apr 6, 2018, at 12:19 PM, Bassem Mettichi <mettichi@gmail.com> wrote:
i have keeplaived and lvs with 2 freerdaius servers running version 3.0.16 on redhat 7 ( keeplaived is configured with NAT option)
when i send an accounting start from a client vm using radclient i get this response:
radclient: Received reply to request we did not send. (id=134 socket 3)
Your network is broken. Fix that. FreeRADIUS works. It sends correct replies when it receives correct requests. Since that isn't happening here, it's because of something *else* in the network. Which isn't the fault of FreeRADIUS. Read the source and destination IPs of the request and reply packet. They should match. If they don't (and they won't), it's because something else is breaking RADIUS. This shouldn't be difficult. Install a simple configuration. It WILL work. And *understand* the system you've built. Alan DeKok.
Hello, thakns a lot Alan for this response this is really my problem. because when i send the packet from the client side the destion IP is the VIP ( ported by keeplaived) however when i receive the response i get source IP of freerdaius server instead of the VIP ( normally the source IP of the response packet should be the VIP ) . but i don't know this behavior why keepalived and lvs are changing the IP source of the packet. thanaks a lot Alan Mettichi Bassem 2018-04-06 17:26 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Apr 6, 2018, at 12:19 PM, Bassem Mettichi <mettichi@gmail.com> wrote:
i have keeplaived and lvs with 2 freerdaius servers running version
3.0.16
on redhat 7 ( keeplaived is configured with NAT option)
when i send an accounting start from a client vm using radclient i get this response:
radclient: Received reply to request we did not send. (id=134 socket 3)
Your network is broken. Fix that.
FreeRADIUS works. It sends correct replies when it receives correct requests.
Since that isn't happening here, it's because of something *else* in the network. Which isn't the fault of FreeRADIUS.
Read the source and destination IPs of the request and reply packet. They should match. If they don't (and they won't), it's because something else is breaking RADIUS.
This shouldn't be difficult. Install a simple configuration. It WILL work. And *understand* the system you've built.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Fri, Apr 6, 2018 at 4:50 PM Bassem Mettichi <mettichi@gmail.com> wrote:
thakns a lot Alan for this response this is really my problem. because when i send the packet from the client side the destion IP is the VIP ( ported by keeplaived)
however when i receive the response i get source IP of freerdaius server instead of the VIP ( normally the source IP of the response packet should be the VIP ) .
but i don't know this behavior why keepalived and lvs are changing the IP source of the packet.
I'm no expert with freeradius, but it sounds like it's sending its responses from 0.0.0.0 which means "let the kernel pick", regardless of where it received the request. Searching github and mailing list archives for "multihoming" will find some people who have been down this road before. Possibly there's some configuration you can make to freeradius to explicitly bind it to the VIP address. Again I'm very much not an expert here. But I'll offer an alternate direction of research in case adjusting the freeradius configuration turns out to be a dead end. If the sending socket isn't explicitly bound to an address, the kernel will consult the routing tables to decide on a source address. For example, on my Linux desktop packets destined for 8.8.8.8 will use the source address 192.168.1.102: $ ip route get 8.8.8.8 8.8.8.8 via 192.168.1.1 dev em1 src 192.168.1.102 You can view the entire routing table with "ip route". You might be able to tweak your keepalived configuration so when it installs the VIP address, it also inserts a route with a lower metric than the existing ones such that the VIP is used as the default source address. You can also play games with ip-rule(8) if you want this to happen for only some ports or hosts in a way that you can't express with just one routing table. Hope that gives you some possible solutions to research.
On Apr 6, 2018, at 1:34 PM, Phil Frost <phil@postmates.com> wrote:
But I'll offer an alternate direction of research in case adjusting the freeradius configuration turns out to be a dead end. If the sending socket isn't explicitly bound to an address, the kernel will consult the routing tables to decide on a source address. For example, on my Linux desktop packets destined for 8.8.8.8 will use the source address 192.168.1.102:
That's the answer here. And... this is why FreeRADIUS can be bound to to (a) a specific IP, such as the VPN IP, or (b) to a specific ethernet interface, such as the VPN interface This is documented in the configuration files. Alan DeKok.
participants (3)
-
Alan DeKok -
Bassem Mettichi -
Phil Frost