Unable to accomplish a simple DMZ setup for port forward.
Hello to anyone who can help. I am attempting to use some Firewalla Purples as a simple firewall/router for a single SIP Phone Server. I have had no luck with either port forwarding or using a DMZ setup. Essentially I just need port 5060 forwarded from a single known IP to the SIP server on the internal interface. There is no cg nat, WAN is a dedicated static IP. If anyone is able to point out what I have been missing it would be greatly appreciated.
Firewalla Purple: Version 1.9742 in Router Mode
App Version: 1.52.86 (1288)
Physical Setup:
ISP <-> (WAN) Firewalla Purple (LAN) <-> SIP Server
We have so far tried:
Setting up a port forward per Firewalla documentation, setting up a limited DMZ, setting up an unlimited DMZ, disabling Active protect, manually creating rules to permit port 5060. Essentially we are unable to permit ANY unsolicited traffic at all.
-
After trying this again there is no difference in th blocking on the device.
Our issue seems very similar to this: https://help.firewalla.com/hc/en-us/community/posts/5299868620947-Trying-to-allow-a-single-IP-in-through-WAN-is-this-possible-with-the-default-block-traffic-from-internet-rule-
-
@Kael,
I would recommend port forwarding not DMZ here. Can you check the following:
- Check to make sure the protocol is correct. UDP/TCP. If you need both you will need separate port forwarding rules.
- Create your port forwarding. Adjust the internal port if it is different than the external port.
- Forward to the device (or LAN IP address).
- For Ingress Firewall select the IP or IP range you want to allow.
-
This is exactly what we have done. Screenshot below.
We also found that after enabling emergency mode for 15 minutes it worked and continue working after that 15 minutes until the firewalla was rebooted. After the reboot we tried enabling emergency mode again and it no-longer worked. We really cannot make any sense out of how this device seems to operate.
-
Thank you for assisting us with this. There are no groups and no network rules. There are only the default internet and active protect rules as well as the rules auto-generated by the port forwards on the device at this time. 5060UDP for the SIP connection and 10k-12kUDP for the RTP audio.
-
Hmmm. Here are some ideas:
- Check if there is double NAT.
- Check that you have a public WAN IP.
- Check to see if MS-ESIP-1 has any firewall in place.
- If you have any other device you can test with, create a port forward to that and see if port forwarding has any challenges with that device.
-
Thanks for your suggestions. I can speak to some of these from past attempts.
1. There is no double/ CG NAT.
2. We have a static public IP which can be reached directly from the internet.
3. MS-ESI-1 has no firewall in place and operates correctly with the same WAN different firewall/router devices. (I've tested with enterprise grade Barracuda firewall and terrible old netgear SOHO router)
4. If I have time today I will try another device, probably a simple test web server
A side note, we have gotten this to work with firewall at times in the past (without engaging emergency mode) but typically it only works until the Firewalla device was rebooted or lost power.
I even have the exact same setup working at another location. Resetting an copying that config exactly did not help, nor did use the "Migrate from other box" features. I'm just completely at a loss. We are also engaging support on this issue.
-
@Kael, Interesting. So what's different?
- Different ports. Seems unimportant.
- Different device. Seems unimportant, unless the device has some kind of firewalll which you say it doesn't.
- For the test, were you using the same public IP or is MS-ESIP-1 on a different public IP? I assume the port is not blocked by the ISP?
-
Thanks very much for your help. We ended up moving to a different vendor which did not have this issue and worked immediately.
We worked in parallel with Firewalla support for a week but we were never able to reliably get 5060 open to the internet. Port 80 was no problem and just worked as described in the documentation. We were also unable to figure out the inconsistent behavior around port 5060 and the Emergency Access mode.
My only theory is that there is some bug in the implementation of the SIP passthrough that causes issues specific to port 5060. Unfortunately this makes the product unsuitable to our use case.
Thanks especially to @Michael Bierman for all the work on this.
Please sign in to leave a comment.
Comments
17 comments