FreePBX stops working on AWS when eth0 is put in the internet zone


After moving the eth0 interface from the trusted to the internet zone, after a few minutes I cannot connect to the GUI. My ssh connection disconnects as well.

The AWS console shows the instance is still running but I have to reboot to get things working again.

(Simon Telephonics) #2

If possible, use AWS security groups to handle your firewall needs.

I found that the FreePBX Distro firewall blocks DHCP and this causes the instance to drop its IP address after some time. So if you are using the distro firewall, try adding a custom rule to allow DHCP.

Old screenshot of Custom Rules should still be valid


I have an elastic IP address assigned so no need for DHCP

(Simon Telephonics) #4

Unfortunately, that’s not how it works. Your EC2 instance will receive a private IP address from AWS DHCP server. Your elastic IP is mapped to that private IP. You must use DHCP and you cannot assign the public IP directly to the interface.


Thanks for clearing that up. I’ll give this a try.


No joy. I created the custom service as you specified and put the eth0 interface into the internet zone. I can connect to the GUI until the firewall kicks in then it is blocked

I also put my client network into the trusted zone.

I’ll try to ssh tomorrow. It’s 0130 ICT

(Simon Telephonics) #7

Your issue may be different than the one I mentioned. With the DHCP packets being blocked, it usually would fail after several hours because the DHCP lease expires and the server can’t renew. In your case it is blocking you right away so you probably have something different going on. If you can operate with only AWS Security Groups as your firewall and disable the Distro firewall you will have a simpler configuration.


Do you have a working example security group for AWS with inbound rules

(Jared Busch) #9

I’ve worked on dozens of systems on Vultr and they never have a problem getting their DHCP assigned address. I’ve also dealt with dozens of local VM installs with DHCP assigned IP addresses without ever seeing this. I have never used AWS though.

(Simon Telephonics) #10

I don’t have the log information at hand and the incident I worked on was a year or so ago (which is why the screenshot image I shared has the old styling). I know this firewall rule solved the problem we had. If I remember it right, the initial DHCP acquisition by way of broadcast worked fine. Later, the renewal which happens by unicast was blocked, so at the end of the lease time the IP was released. When the IP was released, this caused several services on the server to go berserk (technically speaking!) and it never recovered. What I would expect to happen is for the DHCP client to start over with a broadcast to get a new lease, but that didn’t happen.


Please see my last comment. Can you help


I’m happy with AWS


How so, we all read that you can’t make it work :slight_smile:
Maybe they can help you traverse their firewall, you will need both your SIP signalling and your SDP traffic seamlessly forwarded both ways, along with any http/https services on whatever port you want to provide.


If I don’t put eth0 in the internet zone, it works. The private IP address is in the internet zone.

This is on a free tier so the price is right


Nothing is free. Time, yours or someone elses costs you or someone else

So don’t do that :slight_smile:


Free tiers are free.

I’m using a community marketplace AMI that has no subscription fees


I found this. Is it complete? Would you make any changes?


Nobody has answered the question

(Simon Telephonics) #20

It has been nighttime.

Yes, that guide is fine. Only allow traffic for what you are using. If you are only using SIP from your business then only allow your business IP to access SIP ports.


Thanks for all your help. I never did figure out exactly why putting the eth0 interface in the internet zone causes the failure that I described.