On 20/10/2011 18:11, E.S. Rosenberg wrote: > On the whole I just need the backend to know the username, or what > 'browsing plan' the session is using, sometimes plans are also > determined based on src IP (ie. certain stations aren't allowed to > browse no matter who's logged in, or are supposed to only have access > to a whitelist even when staff are using them), so I think a > 'NAT'-like method is most likely what i need. Just to highlight a feature that not everyone yet knows about, but in the 3.2 series there is support for conntrack marking both to copy the original connection mark to the output and also to mark connections based on various squid criteria. Conntrack marks don't affect anything outside of the network stack they are running on (ie next hop knows nothing), but they can be used to help integrate a firewall to achieve various clever effects. I'm not sure that they help you that much, so this was more to add an idea on the off chance it helps... At a pinch you can use your firewall to change IP address or TOS marks to communicate conntrack marks outside of the box, but it's a bit crude... The other thing is that I believe you can use the auth helpers to set the upstream auth username to be somewhat different to the logged in user? So I *believe* you can achieve the effect that you can do some database lookup on users in group X to get a group name "X" and pass that "X" upstream as the auth user. The point is that you don't need to use IP as your upstream signaling criteria, you can use the auth user, but pre-grouped to the service class names that you need. As an extension to this basic idea I believe you can use the auth helpers to derive these "usernames" from other criteria such as client IP address, etc. Does this help? Good luck Ed W
