RFC1918 traffic on WAN when making calls with Signal
-
Hi,
i have an egress rule on WAN, which prevents RFC1918 traffic directly to wan as follows:
Now when i´m in my WLAN with my phone (on a separate VLAN), and calling someone via the Signal App, i get the following entries in my firewall log - the blurred out parts is my public IP and the destination is the interal LAN-IP of the other participant, which is also at home in his WLAN (also an a separate VLAN):
I´m not able to find out why this happens, or where i could start to investigate.
Any help is very appreciated.
Thanks.
Puni -
@puni
Generally the traffic is routed according to the routes table. If the destination is routed out on WAN to the default gateway, I'd assume, that the destination address doesn't lie inside of a configured subnet.So check if the concerned network mask is set properly and check the routes table.
-
@viragomann - to clarify my first post - the traffic is supposed to go out to the internet, because the counterpart with his phone with the signal app is in a different place with it´s own internet/public ip an own network behind that. I think i didn´t describe this in detail in the first post.
What is strange is that i see his internal IP on my WAN.
Vice versa he sees my interal IP on his WAN.
Is this maybe because the way Signal work/handles traffic?But thanks for the tipp, i will have a look at my routes.
Best regards
Puni -
@puni Are you both connected via a VPN? And does signal work? Maybe it is a signal-problem and pfSense does its job just fine.
-
@bob-dig
Yes we have a wireguard site to site tunnel, but the routes are only for the 192.168.50.0 net on my part to get to his subnet and 192.168.33.0 on his part to get to my subnet.I had a look in pfsense on my routes, 192.168.50.0 only has a route to its gateway 192.168.50.1 - also on his pfsense 192.168.50.0 onlz has a route to its gateway 192.168.33.1.
So i dont think it has something to do with wireguard. Weve also disabled wireguard completely and the firewall entries are generated.
I think its maybe how Signal works, but wanted to ask if somebody has experienced this too.
I also think that its not a particular pfSense bug.Best regards
Puni -
@puni I did a short test with calling someone over signal and I couldn't replicate but speak time was only about 30 seconds.
-
@bob-dig Thanks for trying out, i will further investigate an post any findings.
Best regards
Puni -
@puni said in RFC1918 traffic on WAN when making calls with Signal:
Yes we have a wireguard site to site tunnel, but the routes are only for the 192.168.50.0 net on my part to get to his subnet and 192.168.33.0 on his part to get to my subnet.
But the source in question is 192.168.30.100, not in either of those subnets.
Where on your network could traffic sourced from that address be coming from?
When it is occurring, look at Diagnostics > States, filter on that address, and you should see the state coming into the firewall before it tries to connect outbound WAN and gets rejected by that rule. That will show you the interface it arrived on.
-
@derelict I was called via Signal and had a look at the states.
Your tip was good - now i see that there is a state with the IP 192.168.22.3, which is my client desktop, which has signal also running.Not sure how to investigate further, maybe someone could try to also get an incoming call on the phone app, while running an other client, which should also receive the call.
Thx.
