Hey Metik, Thanks so much for your insights and your help. And yes, I was able to append the X-AUTH-IP header with no problem. But that didn't solve the issue. After some more research, it appears that the problem isn't with auth-calls at all.
I disabled all auth-call directives in every sip profile and the registration through a proxy is still being rejected. I looked in sofia_reg.c and if auth_acl is defined, sofia_reg checks the ip variable against the auth_acl cidr. if (auth_acl) { if (!switch_check_network_list_ip(ip, auth_acl)) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_WARNING, "IP %s Rejected by user acl %s\n", ip, auth_acl); ret = AUTH_FORBIDDEN; goto end; } So I guess the question is, is it possible to control what gets put into the ip variable? Thanks, Bill Metik wrote: > Honestly, several years ago I accomplished this by mod'ing SER (which > became OpenSER which was then forked to OpenSIPS and Kamalio) and using > one cluster of proxies for subscriber endpoints and another for > infrastructure (so that I could keep RTP flows optimized yet support > double NAT when required by an endpoint). Although the network looks > different today. > > However, we were never quite happy about the lack of media failover > (complicated NAT) and evaluated several commercial solutions until > finding Covergence (which is now, for better or for worse since the jury > is still out, owned by ACME Packet). At the time, they offered the best > mix of security (their forte) yet scaled very well in comparison to > their competitors that I had tested in our lab (ACME Packet, Kagoor, > Netrake, NexTone, Kagoor, and Jasomi). In fact, they made a great > decision, not unlike that of the FS developers, to implement a > proven/stable SIP protocol stack. Nothing is perfect and that does not > mean that we did not spend a considerable amount of time documenting > bugs so that they could be addressed and it would work as it should > > We still use OpenSIPS for certain CSCF functionality (due to its speed > and flexibility since it is not a B2BUA). > > Based on Mathieu's response (and he is definitely someone that would > know), it looks like you should be able to easily append a X-AUTH-IP > header (via OpenSIPS) containing the IP address of the endpoint and call > it a day. > > -metik > > > Bill W wrote: >> Hey Metik, >> >> That's exactly what I'm trying to do... load balance across multiple FS >> boxes, and have any machine in the cluster be able to reach a device >> behind a NAT firewall. Hence the need for the proxy. Also, I'm trying >> to keep the proxy relatively "dumb" and put all the logic in the FS boxes. >> >> True I could do the auth on the proxies as well, but then I'm setting up >> another authentication scheme in addition to what is on the FS boxes, >> and then integrating the databases so everything is consistent. >> >> I also have hosts that talk to the FS boxes directly, rather than >> through the proxy. So I can't get rid of auth_acl on FS either, even if >> I do implement it on the proxies. So my setup becomes much more >> complex and potentially brittle. >> >> And all we're really talking about for FreeSWITCH, conceptually >> speaking, is populating a variable with a different IP. We could even >> make it configurable, as to which IP is to be used for the auth-acl. >> >> What are you using for SBCs? (if you are allowed to divulge that) I'm >> currently using OpenSIPS for my proxy. >> >> Thanks, >> Bill >> >> Metik wrote: >> >>> Why not simply implement this feature in the PROXY itself? >>> >>> FS has a pretty comprehensive security feature set for endpoints that >>> directly register with it. >>> >>> Don't get me wrong, I do agree this is useful especially if you are >>> going to be using your proxies to load balance across multiple FS boxes >>> to create an ad-hoc cluster. I actually have session border controllers >>> that have this feature and use it quite often. >>> >>> -metik >>> >>> Bill W wrote: >>> >>>> Hey Metik, >>>> >>>> Thanks for the reply, and the pointers for doing it with xml_curl. >>>> >>>> I'll guess have to do that in the short term, but in my opinion, having >>>> auth-acl be able to work through a proxy is very important as it is a >>>> vital part of a comprehensive security feature set. And it would be >>>> much simpler to implement from an end-user perspective than the >>>> alternative of doing it in xml_curl. >>>> >>>> As a matter of fact, I'm considering offering a bounty for that feature. >>>> What is the going rate for that kind of thing? >>>> >>>> Is anyone out there interested in coding this feature? Or chipping in >>>> for the bounty? >>>> >>>> >>>> Thanks, >>>> Bill >>>> >>>> >>>> Metik wrote: >>>> >>>> >>>>> This may be difficult considering that ACL needs to consider the >>>>> original src IP/URI. To do that it, freeswitch would need to do so >>>>> using a header that retains that information (i.e. From, Via, Contact, >>>>> etc.). Which I do not believe is currently possible using auth-acl or >>>>> apply-proxy-acl. >>>>> >>>>> However, you should be able to emulate the behavior using mod_xml_curl >>>>> (and validating against appropriate variables available when using it to >>>>> authenticate the request). >>>>> >>>>> see: http://wiki.freeswitch.org/wiki/Mod_xml_curl#Authorization >>>>> >>>>> -metik >>>>> >>>>> >>>>> Bill W wrote: >>>>> >>>>> >>>>>> Hey Brian, >>>>>> >>>>>> >>>>>> I've been doing some testing and I am unable to get auth-calls to work >>>>>> through a proxy the way I want them to, even with setting >>>>>> apply-proxy-acl to either the endpoint IP or the proxy IP. >>>>>> >>>>>> I have a multi-tenant system with multiple domains with multiple users >>>>>> in each domain. And I want to restrict a user to an arbitrary CIDR and >>>>>> challenge them for a password. The arbitrary CIDR will vary from UA to >>>>>> UA, and is specified in the directory via the auth-acl parameter. >>>>>> >>>>>> TL,DR; I want to get auth-calls to use the IP of the UA endpoint, not of >>>>>> the proxy. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bill >>>>>> >>>>>> Brian West wrote: >>>>>> >>>>>> >>>>>> >>>>>>> it needs to be an ACL from acl.conf or a ip/cidr >>>>>>> >>>>>>> /b >>>>>>> >>>>>>> On Dec 17, 2009, at 5:41 AM, Bill W wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Okay, I added: <param name="apply-proxy-acl" value="true"/> to my >>>>>>>> sofia >>>>>>>> profile and restarted sofia, and still no joy. >>>>>>>> >>>>>>>> I'm on FreeSWITCH Version 1.0.trunk (15764) >>>>>>>> I've got <param name="auth-acl" value="190.218.103.12/32"></param> in >>>>>>>> the directory, but I'm still being rejected by the acl: >>>>>>>> >>>>>>>> 2009-12-17 06:04:59.920517 [WARNING] sofia_reg.c:1928 IP >>>>>>>> 64.135.119.105 >>>>>>>> Rejected by user acl 190.218.103.12/32 >>>>>>>> >>>>>>>> Here's what I believe is the appropriate snippet of the debug output: >>>>>>>> http://pastebin.freeswitch.org/11531 >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> Thanks, >>>>>>>> Bill >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> FreeSWITCH-users mailing list >>>>>>> FreeSWITCH-users@lists.freeswitch.org >>>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>>>>>> http://www.freeswitch.org >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> FreeSWITCH-users mailing list >>>>>> FreeSWITCH-users@lists.freeswitch.org >>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>>>>> http://www.freeswitch.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> FreeSWITCH-users mailing list >>>>> FreeSWITCH-users@lists.freeswitch.org >>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>>>> http://www.freeswitch.org >>>>> >>>>> >>>> _______________________________________________ >>>> FreeSWITCH-users mailing list >>>> FreeSWITCH-users@lists.freeswitch.org >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>>> http://www.freeswitch.org >>>> >>>> >>>> >>> _______________________________________________ >>> FreeSWITCH-users mailing list >>> FreeSWITCH-users@lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >>> >> _______________________________________________ >> FreeSWITCH-users mailing list >> FreeSWITCH-users@lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> >> > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org