multiple public ip's for redundancy

Status
Not open for further replies.

Shawn

Free User
Joined
Feb 2, 2017
Messages
221
Reaction score
9
my 3cx server sits behind a firewall with nat rules that translate addresses in both directions. i have two separate public ip's from two separate isp's that wind up at different interfaces on my firewall. i have configured the firewall to nat 3cx traffic according to the public ip's and the firewall rules are setup to allow traffic on both of these interfaces. load balancing is setup for redundancy where if the primary connection goes down, traffic is handled via the secondary until primary comes back up to take over.

a windows soft client from outside the firewall connecting to my primary public ip works fine. when connecting to the secondary ip, the client shows extensions and their status along with calls in the receptionist view, however calls cannot be made or received. for example, when an attempt is made to make a call to another extension, the call is immediately dropped. chat between clients from outside to inside and vice versa work ok. seems like only calls are having issues on the secondary connection.

looking in 3cx activity log (verbose) i don't really see any sign of the initiated calls that are immediately dropped on the client side.

does anyone have any suggestions as to what is going on here. my firewall settings seem to be correct. i'm not sure what the role of the public ip address (external ip configuration under network settings) in the 3cx server configuration is. does that have any role in this behavior?

has anyone here setup redundancy similar to mine and have some input on my config?

thanks

shawn
 
most likely fqdn.3cx.etc is still resolving to the primary ip address, witch is down.

more of a dns witchcraftery than 3cx issue.
 
@Shawn

So that sounds like failover and not load balancing. You don't want load balancing for this purpose. But regardless you basically have three options:

- If you want to keep your PBX in-house and you want it to do right then you want an SDWAN solution. The solution we use gives you one IP that never changes regardless of the connection you are physically using which solves your problem. You can ping me for more info.
- If you want to keep your PBX in-house and you are ok with some downtime you want your 3CX box to be configured as STUN. It will resolve the 3CX FQDN to your primary connection and when you failover it will update that to your secondary connection. Keep in mind there is a delay on how fast DNS updates happen (TTL based on the license type) and if your connection bounces back and forth it will get ugly real quick.
- Move your PBX to the cloud and don't worry about the IP changing.

Obviously option 1 or option 3 are the recommended paths with 3 being cheaper and easier and option 1 being the best if you have other things in your office that would benefit from a proper solution. LB/Failover is a crap shoot at best unless you have tons of money to have your own netblock and implement BGP with your providers. If you want that kind of reliability but with commodity circuits then SDWAN is the way to go.
 
  • Like
Reactions: MARLEY JAFFE
3cxnub, i'm connecting from an outside soft client directly to the public ip addresses so dns is not an issue here that i can think of but, thank you for the note.

cobaltit, thank you for the different options. i'm aware of sdwan but don't really want to use that option as i believe i can handle this on prem with my current setup. you're correct, this is a failover and not load balancing. my firewall has load balancing options and under that is where you select whether to balance or failover so just getting terminology mixed up.

right now, i have a soft client on the public side which is connecting to my pbx on the lan through the firewall. everything is working ok including calls from extensions inside my network to the extension of the client outside the network, status is working, presence is working, chat works. the only thing that does not work is calls from the public client to anywhere. when an attempt is made to make a call, the client software immediately reverts back to previous screen as if nothing happened. i've traced packets on my firewall and on 3cx. packets are flowing through the firewall but i don't see them on a trace at the 3cx server.

it seems like a network issue from public to private but i see the packets traversing through my firewall but not making it to 3cx which does not make sense.

is there an option to put the soft client in verbose mode to see what is happening to outbound calls there?
 
@Shawn
Are you testing the softphone with a mic? I noticed (and it's been confirmed) that the 3CX client will freak out when the softphone is used with no mic. It will make one call then have a behavior similar to what you describe. Assuming that's not the issue then you can try forcing a tunnel connection instead of direct SIP for the remote clients. But otherwise I think what you are seeing is the difference in the protocol handling since presence/status/chat is all http and calls are SIP.

Good luck!
 
cobaltit, i could kiss you brother..... i'm pretty sure that you've hit the nail on the head. i am remoting into the machine that has the windows soft client and it's not picking up the presence of a mic. i'm am currently unable to connect a mic to the station but i'll bet once that is done, all should start working.

i wouldn't have figured that one out in a million years if it weren't for your tid bit.
i'll get a mic on that station and will reply to this thread with the result but i'm feeling pretty good about it.

i'll have to buy you a cold one if out paths ever cross.
thanks again mate.
 
i'll get a mic on that station and will reply to this thread with the result but i'm feeling pretty good about it.
For testing just re-register the client before every call. The client will then run one call (with no audio) before it needs re-registering.
 
Status
Not open for further replies.

Forum statistics

Threads
111,899
Messages
589,620
Members
164,765
Latest member
domi