[SOLVED] WIFI calling hiccup over bridge
-
I have the pfsense boxes LAN/WAN ports bridged all traffic flows freely through them from the switch to the Comcast modem. Everything there is getting a 172.20.0.0 IP from a Comcast router/modem. The port on the switch that connects the LAN cable only accepts the default VLAN untagged packets. The pfsense box runs VLAN2 on the OPT1 port and hands out 192.168.1.0 addresses. The port on the switch that connects the OPT1 cable only accepts VLAN2 tagged packets. The wireless AP has two SSIDs: Internal on the default LAN untagged and External on the Tagged VLAN2 network. The port on the switch that the AP connects to accepts default untagged and VLAN2 tagged packets.
So everything works exactly as it should. I create firewalls between the default LAN and VLAN they can’t ping or talk to each other unless I create a rule to say allow someone to print to a printer, etc….
So here’s my oddity. When using a cell phone and connecting to the external wireless (which the call then gets routed to the pfsense box over OPT1 and pfsense does NAT sends it onto Comcast modem and out) everything works fine. But when using a cell phone on the internal wireless (which sends the call over the LAN/WAN bridge to Comcast and then out) the phone call will go silent for maybe 10secs. It doesn’t drop the call. I can still carry on a conversation, it’s just that maybe after 30secs to a minute I hear nothing for 10secs or so and the other end can’t hear me and then it comes back and works fine the rest of the time. So my thoughts are those WIFI calling packets are getting hung up, temporarily dropped, temporarily routed the wrong way? I have no idea. I'm just looking for any ideas as to why this might be happening.
Thanks!
-
Wifi calling like that usually relies on mobile IPSec to carry the traffic. Check the state table for UDP port 4500 traffic.
Check for blocked traffic in the firewall log.
Ultimately you might need to do a packet capture and see what fails and on what interface.
Is there any particular reason you are bridging the interfaces like that?
It would probably be better to bridge the Comcast device and NAT both internal subnets in pfSense.
Steve
-
I allow all IPv4 and IPv6 traffic through so UPD 4500 is open. The VLAN has one firewall rule blocking it from the LAN PCs but that's it. And this only happens on the LAN 172.20 network not the VLAN network. I checked the firewall logs and no blocked traffic. It appears to have something to do with the bridge. Where as when I use the cell phone over the VLAN and pfsense works more like a normal router performing NAT, DHCP it works fine. It just happens when on a cell phone and the traffic passes through the bridge to the Comcast router/modem and out. And like I said it works, the call just goes silent for 10 seconds or so then back to normal. Yes I bridge the box this way so one I can monitor all traffic coming through and 2 so that I can easily remove the pfsense box, plug the Ethernet cable in from Comcast to the switch and the only thing I lose is the external wireless.
-
It could also be the Comcast box borking at the traffic in some way that pfSense corrects when it is routing. In bridge more it just gets passed to the Comcast router, there's not much that it can do there.
You only need UDP open outbound. You shouldn't have to open anything, that traffic should be passed by default.
Steve
-
Just trying to wrap my head around why your doing it like that.. What are you trying to accomplish other then over complex setup?
-
Is that Comcast box in gateway or bridged mode? If gateway, you have double NAT. Also, why do you have both LAN and OPT1 between the switch and pfSense? Why is WAN/LAN bridged to OPT2? What does OPT2 connect to? I don't see it on the diagram.
-
I would guess that the WAN/LAN bridge is assigned as OPT2 so that OPT1 can NAT to it for upstream access.
But a screenshot of the NIC assignments would clear that up.Steve
-
I everyone. Thanks for all your input and advice. I did finally figure out what my issue was. The wireless APs were configured to not allow an untagged VLAN. So when the phone connected to internal SSID the traffic was tagged with the default VLAN ID which is also the default LAN ID. I'm assuming that during the phone call the tag eventual got dropped because the network realized it does not need a tag. That must be what caused the slight delay in silence. allowing an untagged VLAN on the wireless AP has fixed this issue.
Again thanks for everyone's help and advice!
One more question. Is there a way to close out a post?
Thanks,
-
If your issue/question has been answered/solved - you can edit the thread title to reflect that [solved] for example.
-
Hmm, that explanation seems unlikely. VLANs don't just stop using tags like that. Either traffic is tagged onto a VLAN or it's not.
Still, glad you were able to resolve it.Steve
-
@demoso said in WIFI calling hiccup over bridge:
allowing an untagged LAN on the wireless AP has fixed this issue
Normally, when you use VLANs with an AP, it's to use multiple SSIDs. While you could send VLAN frames over WiFi, I really don't see the need to, in that you're unlikely to have something like a phone and computer share the same cable with different subnets.
