For your issue in the other thread:
Now i cannot access my Radius Server ( 103.xxx.x79.49 ) from my Clients side (PPPoE Clients) that are using above POOL (obviously)
The issue is with the subnets. Each PPPoE client gets its own /32 subnet of just one device. Additionally for some unknown reason you have placed the same subnet as a /24 on that same physical interface used for PPPoE.
A bit of theory - when a device needs to send traffic, first it has to determine whether the destination is on the same network or a different network. The way it does this is it applies its own subnet mask to both its own IP and the destination IP and does a bitwise AND comparison. If the results of this match, the sender knows that the other device is on the same network as it is, and sends an ARP request for that device’s MAC address to send the packet directly. If the results do not match, the sender knows that the other device is on a different network, and the sender sends the packet to the router instead so that it can be delivered to that other network.
So lets use an example - suppose you have a client on 103.xxx.x79.88 and it wants to connect your RADIUS server on 103.xxx.x79.49. First, the client would do a bitwise AND comparison using its own netmask, for both the source and destination IPs for the packet. This netmask is 255.255.255.255, in CIDR terms a /32:
Source IP: 103.xxx.x79.88
Source netmask: 255.255.255.255
AND comparison result: 103.xxx.x79.88
Destination IP: 103.xxx.x79.49
Source netmask: 255.255.255.255
AND comparison result: 103.xxx.x79.49
The two bitwise AND comparison results in this case do not match - one ends in 88 and one ends in 49. As a result, the PPPoE client correctly knows that it has to send the packet through a router to reach the RADIUS server as it is on a different subnet (and it is in fact on a different subnet).
This initial packet will make it to the RADIUS server and the RADIUS server will try to respond. In order to respond, the RADIUS server has to determine whether the PPPoE client is on the same network as it or a different network. In actuality we know that the PPPoE client is on a different network (a network of just one IP, network address 103.xxx.x79.88), but the RADIUS server has to use the bitwise AND comparison like before to try to determine whether the PPPoE client is on a different network. It does these calculations and gets these results:
Source IP: 103.xxx.x79.49
Source netmask: 255.255.255.0 (/24)
AND comparison result: 103.xxx.x79.0
Destination IP: 103.xxx.x79.88
Source netmask: 255.255.255.0 (/24)
AND comparison result: 103.xxx.x79.0
In this case, because the RADIUS server’s subnet mask is 255.255.255.0, the AND comparison results match - both are 103.xxx.x79.0. The RADIUS server then (incorrectly) thinks that the client is on the same network as it, and that it doesn’t have to send the packet through the router. It does an ARP request, asking 103.xxx.x79.88 what its MAC address is. Because this client is not actually on the same network, there will be no response to this ARP request. The RADIUS server then gives up on trying to send the response since it doesn’t know what MAC to send it to.
The best solution here is to make the subnet that the RADIUS server is on smaller than a /24, perhaps a /26 which would include the first 64 IPs, so that it didn’t overlap with the PPPoE range.