I have rules for specific traffic in separate anchors so that I can better control what devices talk to what when. One of those anchors is for Google Voice. I originally had allowed traffic to the entire Google CIDR block for the necessary TCP and UDP ports (see the 2nd quote) but recently changed that to the IP addresses resolved by DNS lookups. The IP addresses are updated every minute via a cron job and the results are updated in a table in pf. Here, GOOGLE_VOICE_STUN and GOOGLE_VOICE_FIREBASE_MESSAGING are both dynamically updated.
The problem I am experiencing now is that when making Google Voice calls on my wifi network, people on the other end suddenly stop hearing me and then after some time, they may start hearing me again or they might be hearing me with substantially delay. It does not appear to happen 100% of the time, but seems consistent enough that I suspect it is my updated ruleset. I am thinking that I don't experience it 100% of the time because not all my calls may be long enough.
I've had some issues earlier with Google Voice when I originally got my phone and was thinking it was my wireless access point, a pocket router, so I replaced that with another one, but the issues still persisted, they were just extremely intermittent. The bluetooth on my phone would also sporadically stop working and then a minute later, my earbuds would reconnect (I had my phone in my pocket, a mere 3 ft away).
1. I thought the default behavior for pf was to track state, therefore, once the initial packet matching these rules is passed, it should be good for the lifetime of the connection even if the table containing IP addresses is updated?
2. Might I be mixing issues? Would this be readily apparent if I merely do a tcpdump -i pflog and look for traffic that I thought should be matching that rule?
3. What I am trying to prevent is compromised devices from sneaking traffic out, but if a device wanted to 'sneak' out, they could easily go through the typical web ports https via tcp/udp to Amazon AWS and I wouldn't have any idea it was there.
I am testing my firewall rules with a test call to testcall.com and my tables are updated every minute and so far with the rules from the first block, I haven't experienced the issue with the echo test (I've been on a call for over 5 minutes). So, it might still be an issue with my phone
.
The problem I am experiencing now is that when making Google Voice calls on my wifi network, people on the other end suddenly stop hearing me and then after some time, they may start hearing me again or they might be hearing me with substantially delay. It does not appear to happen 100% of the time, but seems consistent enough that I suspect it is my updated ruleset. I am thinking that I don't experience it 100% of the time because not all my calls may be long enough.
I've had some issues earlier with Google Voice when I originally got my phone and was thinking it was my wireless access point, a pocket router, so I replaced that with another one, but the issues still persisted, they were just extremely intermittent. The bluetooth on my phone would also sporadically stop working and then a minute later, my earbuds would reconnect (I had my phone in my pocket, a mere 3 ft away).
1. I thought the default behavior for pf was to track state, therefore, once the initial packet matching these rules is passed, it should be good for the lifetime of the connection even if the table containing IP addresses is updated?
2. Might I be mixing issues? Would this be readily apparent if I merely do a tcpdump -i pflog and look for traffic that I thought should be matching that rule?
3. What I am trying to prevent is compromised devices from sneaking traffic out, but if a device wanted to 'sneak' out, they could easily go through the typical web ports https via tcp/udp to Amazon AWS and I wouldn't have any idea it was there.
Code:
# @see: [URL]https://support.google.com/a/answer/9206518?hl=en#zippy=%2Callowlist-uris%2Cvoice-ip-address-range%2Coutbound-ports-need-to-allow-voice-traffic[/URL]
GOOGLE_VOICE_CIDR="74.125.39.0/24"
GOOGLE_VOICE_STUN_CIDR="74.125.250.129/32"
GOOGLE_VOICE_UDP_PORTS="{19302:19309 26500:26501}"
# google voice / hangouts
pass out quick on wan proto udp to <GOOGLE_VOICE_STUN> port $GOOGLE_VOICE_UDP_PORTS queue top
pass out quick on wan proto tcp to $GOOGLE_VOICE_CIDR port https queue top
pass out quick on wan proto tcp to <GOOGLE_VOICE_FIREBASE_MESSAGING> port {https 5228 5229 5230}
pass in quick on wired proto udp from <google_voice_client> to <GOOGLE_VOICE_STUN> port $GOOGLE_VOICE_UDP_PORTS
pass in quick on wired proto tcp from <google_voice_client> to $GOOGLE_VOICE_CIDR port https
# firebase
# @see: [URL]https://firebase.google.com/docs/cloud-messaging/concept-options#messaging-ports-and-your-firewall[/URL]
pass out quick on wan proto tcp to <GOOGLE_VOICE_FIREBASE_MESSAGING> port {https 5228 5229 5230}
pass in quick on wired proto tcp from <google_voice_client> to <GOOGLE_VOICE_FIREBASE_MESSAGING> port {https 5228 5229 5230}
include "/firewall/macro/google"
GOOGLE_VOICE_TCP_PORTS="{19305:19309 xmpp-client 5228 http https}"
GOOGLE_VOICE_UDP_PORTS="{19302:19309 26500}"
Code:
# google voice / hangouts
pass out quick on wan proto udp to $GOOGLE_CIDR port $GOOGLE_VOICE_UDP_PORTS queue top
pass out quick on wan proto tcp to $GOOGLE_CIDR port $GOOGLE_VOICE_TCP_PORTS queue top
pass in quick on wired proto udp from <google_voice_client> to $GOOGLE_CIDR port $GOOGLE_VOICE_UDP_PORTS
pass in quick on wired proto tcp from <google_voice_client> to $GOOGLE_CIDR port $GOOGLE_VOICE_TCP_PORTSI am testing my firewall rules with a test call to testcall.com and my tables are updated every minute and so far with the rules from the first block, I haven't experienced the issue with the echo test (I've been on a call for over 5 minutes). So, it might still be an issue with my phone
.
