strongSwan

Tobias Brunner wrote:

Why don't you redefine how FreeRADIUS generates the unique ID so that it doesn't include the changing IP address?

Well, this way can work around the issue a little tricky, though with potential risks of duplicate acct-session-ids. Morever even if the accounting is properly handled, nas-ip-address related policies such as huntgroup may still have to face up such cases. Technically other service hooked up to this freeradius server would also be impacted more or less. The client just dials up a specific IP, and we can deliver all traffic via a specific IP by "SNAT --to", hence it should be fairly reasonable to bring in an explict parameter in eap-radius to specify the IP packeted. Anyway thanks for your help, it still solves my current problem temporarily.

though with potential risks of duplicate acct-session-ids

You mean if the same client accesses different NAS?

Morever even if the accounting is properly handled, nas-ip-address related policies such as huntgroup may still have to face up such cases.

So you might want to investigate why the IP changes in the first place. Or why you have multiple IPs assigned to that host when you don't actually want to use them.

The client just dials up a specific IP, and we can deliver all traffic via a specific IP by "SNAT --to", hence it should be fairly reasonable to bring in an explict parameter in eap-radius to specify the IP packeted.

What do you mean? SNAT? "IP packeted"?

Tobias Brunner wrote:

though with potential risks of duplicate acct-session-ids

You mean if the same client accesses different NAS?

As the reason why freeradius introduce the unique-id, some device/NAS perhaps would reuse the acct-session-id after reboot. Then I just doubt some other freeradius-backended services may come into such cases one day. It is pretty possbile that they might share a same database.

Morever even if the accounting is properly handled, nas-ip-address related policies such as huntgroup may still have to face up such cases.

So you might want to investigate why the IP changes in the first place. Or why you have multiple IPs assigned to that host when you don't actually want to use them.

Sure thing. It would be definitly a better way to tackle this issue within strongswan internally.

The client just dials up a specific IP, and we can deliver all traffic via a specific IP by "SNAT --to", hence it should be fairly reasonable to bring in an explict parameter in eap-radius to specify the IP packeted.

What do you mean? SNAT? "IP packeted"?

Oh, I mean iptables can specify the output IP in forward chain. And I thought the strongswan could change the NAS-IP-ADDRESS field explicitly in radius messages. Is it feasible?

The client just dials up a specific IP, and we can deliver all traffic via a specific IP by "SNAT --to", hence it should be fairly reasonable to bring in an explict parameter in eap-radius to specify the IP packeted.

What do you mean? SNAT? "IP packeted"?

Oh, I mean iptables can specify the output IP in forward chain. And I thought the strongswan could change the NAS-IP-ADDRESS field explicitly in radius messages. Is it feasible?

You mean you want to map all IP addresses of the server to a single IP? Or what IP do you want to change? And the NAS-IP-ADDRESS sent by the eap-radius plugin is simply the address the daemon uses to communicate with a particular client. If that address is not to your liking, again, make sure your clients don't use a different address.

Tobias Brunner wrote:

The client just dials up a specific IP, and we can deliver all traffic via a specific IP by "SNAT --to", hence it should be fairly reasonable to bring in an explict parameter in eap-radius to specify the IP packeted.

What do you mean? SNAT? "IP packeted"?

Oh, I mean iptables can specify the output IP in forward chain. And I thought the strongswan could change the NAS-IP-ADDRESS field explicitly in radius messages. Is it feasible?

You mean you want to map all IP addresses of the server to a single IP? Or what IP do you want to change? And the NAS-IP-ADDRESS sent by the eap-radius plugin is simply the address the daemon uses to communicate with a particular client. If that address is not to your liking, again, make sure your clients don't use a different address.

I mapped all traffic from "right=xxx" to a single IP, simply because clients only dialled up this IP. And yes, to disable other IPs is supposed to be what I mostly need at present. Regarding to your description, may I just block udp 500 and 4500 of other IPs to ensure the only one IP sent by eap-radius?

Regarding to your description, may I just block udp 500 and 4500 of other IPs to ensure the only one IP sent by eap-radius?

Sure, if the clients can't connect to a specific IP they won't use it (unless it's the only IP of the server they know - but since they can't connect you won't see that IP in RADIUS messages).