Firewall for PBX
-
Could it be that my floating rule may be blocking my PBX phone calls coming in? It appears that I have no hit on the PBX rule, yet I have hits on the floating rule ...see image below. I am thinking of moving that WAN rule to top floating with quickset checked. Call log claims it could be firewall when I try calling in.
-
Well I answered my question ... it's working wow ... wipe off sweat!
-
Do you really need to have sip open to the internet? If its only for a trunk to a sip provider then you don't need wan rules (and nat presumably.)
Unless of course you have phones connecting in, or other pbx's, but those should be on a vpn anyways. -
Your "Float keepout" rules is not he same thing as PBX rule on WAN.
It might have been triggered by TCP traffic - or IPv6 traffic. -
@Gertjan said in Firewall for PBX:
Your "Float keepout" rules is not he same thing as PBX rule on WAN.
It's also filtering ip4/udp in the screenshot so I'd be wondering how hits to the PBX rule should be allowed on WAN as Floating comes first
If its only for a trunk to a sip provider then you don't need wan rules (and nat presumably.)
Not necessarily true. We also have a SIP trunk with a provider and while our PBX tries to connect to it from inside its VLAN, they also try to signal or connect from their side and it can habe negative effects or timeouts or connection losses when not openend. But as the OP clearly limits the connection to its SIP provider, I see no problem opening the SIP port that way. The BiDir connection is documented by the provider so if he has one like that, too, it's quite normal. :)
-
@netblues See: https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-a-voip-pbx.html
-
@JeGr said in Firewall for PBX:
It's also filtering ip4/udp in the screenshot so I'd be wondering how hits to the PBX rule should be allowed on WAN as Floating comes first
That's my thoughts, especially when I am having incoming calls timeout.
@JeGr said in Firewall for PBX:
they also try to signal or connect from their side and it can habe negative effects or timeouts or connection losses when not openend.
Still fighting the timeout issues on calls coming in; so I'll move the WAN rule to Floating to see whether that resolve or just move the PBX to the third Ethernet port available on pfSense. Currently, my PBX is going through two firewalls, the pfSense - king of my WAN and the Mikrotik - king of my LAN ... and of course, its double natted.
-
@NollipfSense said in Firewall for PBX:
That's my thoughts, especially when I am having incoming calls timeout.
Why do you have that rule anyway, blocking all tcp/udp on WAN? There's the default block any for that, so why block it at all with a floating rule that stands above all?
-
@JeGr said in Firewall for PBX:
so why block it at all with a floating rule that stands above all?
and
@NollipfSense said in Firewall for PBX:
my PBX is going through two firewalls, the pfSense - king of my WAN
I could read : the PBX traffic comes in, goes through the first firewall using a NAT rule, and hits the pfSense WAN interface with it's firewall rule. The packet eater Floating firewall rule kicks in and does what it was told to do.
I have this right ? -
@JeGr said in Firewall for PBX:
Why do you have that rule anyway, blocking all tcp/udp on WAN?
It's one-way in only ans was to make things easy for Suricata.
-
@Gertjan said in Firewall for PBX:
@JeGr said in Firewall for PBX:
so why block it at all with a floating rule that stands above all?
and
@NollipfSense said in Firewall for PBX:
my PBX is going through two firewalls, the pfSense - king of my WAN
I could read : the PBX traffic comes in, goes through the first firewall using a NAT rule, and hits the pfSense WAN interface with it's firewall rule. The packet eater Floating firewall rule kicks in and does what it was told to do.
I have this right ?Sort of ... I change it to a floating rule; however, I was still getting timeout. It was really foolish of me trying to route PBX traffic through two firewalls. I have since changed my setup by creating a DMZ per: https://www.youtube.com/watch?v=QFk5jX-oeSo
I cannot test as there is a war between my ISP and myself ... hopefully, things will get resolve soon.