Vonage not working with pfBlockerNG enabled
-
@johnpoz No. Not for deny rules. I was using pfblockerng to create an alias of Amazon AWS IPs for allow rules. I disabled those weeks ago as I no longer use those rules.
-
Well if your setting specific allow rules, that kind of tells me you must not be using the default any any allow? So what are you rules? Post them please.
-
That allow rule was only for smartthings (via AWS) to communicate with home assistant. I got rid of smartthings.
I did some more troubleshooting. I unchecked keep settings and completely removed pfblockerng. Reinstalled, enabled and calls work. Added a single, IPv4 permit alias for AWS using https://ip-ranges.amazonaws.com/ip-ranges.json and I can no longer hear audio over vonage voice calls. Nothing else is configured. I then removes the AWS permit alias and calls worked. I then created a dummy IP4 alias and no vonage audio.
pfblockerng is now removed permanently from my firewall.
-
Without you actually posting exactly what you did, there is no way to help you figure out what is going on.. With the default any any rule, why would you need another allow for anything? All is allowed, there is no point to other allow rules, unless you also going to put in a block
Again without seeing what you actually did there is no way to help you figure out what is going on.
But creating an allow rule for say IP address 1.2.3.4 above a ANY ANY has zero to do with anything.. Where and How exactly where you creating these rules? And you were letting pfblocker auto create rules?
-
I am referring to inbound NAT rules. You are referring to outbound/LAN rules for which I have the default LAN to any rule as well as the default anti lockout rule. That's it. Inbound WAN to LAN I currently have the defaults. No custom rules.
The pfblockerng aliases with an alias as an action are not supposed to create any rules or do anything else but create aliases. This should not cause any issues with anything as no firewall rules was even defined to use the aliases I added as a test and pfblocker shows absolutely nothing being blocked in the logs or alerts.
As soon as I add anything to IPV4, vonage audio stops working. Even a dummy alias entry breaks it.
-
If all its doing is creating aliases, that are not even used in rules... Or are for example then how would that effect traffic.. Makes no sense.
Why don't you sniff and actually see what is going on vs guessing that its xyz with no actual details to go on..
I run pfblocker in alias mode and have not seen any issues with anything not working... I don't use vontage and off the top of my head not sure how whatever your doing is works from a protocol standpoint.. But having an alias that has 1.2.3.4 in it would have zero to do with anything.. You have pfblocker removed right, ok create an alias with some IPs in it.. That is all pfblocker is doing when its in alias mode.
edit: So quick google looks like you could need these ports forwarded
https://support.vonage.com/articles/answer/Port-Forwarding-690
SIP: Port 5061 UDP (Used to send and receive SIP information)RTP: Ports 10000-20000 UDP. (Used to send and receive RTP traffic) When a call is made, random ports between 10000 and 20000 are used to carry the conversation. If any of these ports are blocked, you may experience one way or no audio.
But you say you have no rules on wan? So your trying to use UPnP to open these ports?
-
I have some input that might be useful for you. I have a Vonage machine that is the only device on this VLAN with the following (hastily written) rules:
The referenced VonagePorts are defined as follows:
Everything seems to be working fine with this, calls go out and calls come in, all using outgoing connections only. There are no port forwards on the WAN. I have confirmed this with a port scan - no open ports.
I have a somewhat-wild guess why you might be having inconsistent results with your unit. The only documentation that I have found for Vonage ports talks about using ports 10000:20000. At some point, I recall finding out about that range needing instead to be 10000:25000, and recently I discovered it using port 27830. I've got VonagePorts set to 10000:30000 right now, but will probably just open that rule up to any port, in order to save myself aggravation down the road. I wonder if you have been using the documented 10000:20000 and just by coincidence getting lucky with a port below 20000 sometimes, and unlucky with a port above 20000 sometimes? -
I forgot to mention above that I'm also using pfBlockerNG-devel, with pretty basic config and lists for both DNSBL and IP. I don't have anything whitelisted for Vonage.
I just ran a packet capture while placing calls to and from the Vonage phone, and it used the following destinations:
ec2-18-217-95-147.us-east-2.compute.amazonaws.com.21100 (UDP)
ec2-54-219-107-58.us-west-1.compute.amazonaws.com.10000 (UDP)Maybe do a DNS lookup on those domains and see what you get?
-
I'm starting to like my somewhat-wild guess :)
I dropped VonagePorts down to 10000:20000, and the phones ring but you can't hear anyone talking. -
This makes more sense than pfblocker being the issue. Another option would be to assign your phone(s) a static lease through DHCP and then create a rule which allows any traffic from that IP out from any port. I don't have Vonage, but in the office we have a different VOIP service and that's what I ended up doing. I followed all the documentation and opened all the ports they said were required and still had issues on some phones, so I got tired of that game. I added all phones to an alias and with one rule solved all those issues.
