Access to network from dynamic IP addresses…
-
I have a small call center with my asterisk server behind the firewall and all is good.
The problem is that agents that need to login to the asterisk server are not on static IP addresses.
This makes it very hard to lock down the asterisk servers effectively. In an ideal world it would be white-list access only.
I know I can set up aliases that will resolve the Dynamic addresses, but I need a solution that is more immediate.
I wrote an application that will pull the server config, and update a White-list Alias with IP addresses when an agent authenticates to a web server.
I then run a remote .sh script to rm/tmp/config.cache…. but it does not always allow the newly added IP address to reach the asterisk server...
What is the best approach to get this figured out.
Thanks!
-
Are these users coming from public IPs on the internet side, or are they on your lan
If they are coming from public side, why not let them vpn in - this way you have easy way to lock down to only your users no matter what IP they come from, etc. They would have to have the cert for the vpn, the password, etc. etc.
-
VPN for VoIP has the added benefit of eliminating the need to NAT. The problems we have had using VoIP over OpenVPN UDP tun have been easily attributable to overloaded circuits on end stations (QoS might help here) or general transit problems affecting all traffic.
VoIP over OpenVPN generally works fine.
-
didn't sound like he was needing voip access to the server, more like management. Did i read it wrong? But yeah the voip over a vpn should work as well.
-
Yeah "agents logging into asterisk" to me implies voip phones but I could be wrong.
-
You are prob right now that I think about it.. But sure you can do that over vpn - I have read that running voip over a vpn can even improve call quality, etc.
-
The biggest problem is shaping. You have to shape the tunnel, not the voip. I think you can shape the different traffic inside the tunnel if you assign an interface to the OpenVPN instance but I haven't tried it. Then you have some complex bandwidth issues. The WAN, then the tunnel itself then the shaping within the tunnel. Then out to LAN. bleccch.
-
Wow thanks for all of the quick responses!
We have been reluctant to go the VPN route due to the additional complexity involved in getting the remote agents set up, and the uncertainty of how it may impact the SIP voice quality.
I don't have a test environment, but can ease into it and see how it goes…
-
I assume I can set up simple firewall rules on the LAN side to restrict the VPN agents to just the asterisk servers, and limit access to other servers, a namely databases?
Or is it more complex than setting up simple rules…
Thanks!
-
You restrict what your VPN clients can access at the server side with rules on the OpenVPN server interface. That's where connections come in from VPN clients to your network so that's where the rules go.
-
Ok so I revisited my code after giving it a rest for a few days and made some progress on my original idea of creating an Alias called "Whitelist" and then programatically updating that list by pushing the config.xml file from the server, updating the Whitelist Alias, then pulling the config.xml file back to the firewall and reloading the config….
The issue I ran into was that running rm/tmp/config.cache would not apply the changes…
Today I found that if you run both rm/tmp/config.cache and then /etc/rc.filter_configure it will apply the rule!
Two questions…
1. Are there any unforeseen issues with running the /etc/rc.filter_configure script… it looks like it is pretty straight forward.. and I did not see anything obvious…
2. Is there any way to preflight the config.xml BEFORE is run the commands to reload it? Like you can with Apache?
I am running all kinds of safety checks in my script that updates the config.xml.. but I want to be as safe as I can be…
For anyone interested here are more details…
I am running coldfusion on a box that is open to all Ip address on the WAN.
1. I have a page on that server that requires the agent to authenticate to.
2. The coldfusion script looks at the users IP and determines if it is a new one.
3. If it is a new one it updates a database for that users profile and sets a flag that tells a scheduled task (cron job) that a new IP needs to be added to the whitelist.
4. The scheduled task runs every five minutes and looks for the update flag… if it sees it it runs…
Here is what it does….
- Gets the new IP whitelist from the server…
- uses putty to run a .sh script on the firewall that FTPs the config to the coldfusion server (all done inside the LAN)
- Replaces the previous whitelist with the new whitelist
- uses putty to run a .sh script on the firewall to ftp the config.xml file back to the firewall server
- runs a .sh script to reload the config..