Basic Shaper help needed
-
Perhaps your rule might work better if you used the port for SIP instead of the server IP under the floating rule section. This way ANY SIP traffic will get shaped how you want it.
-
The rule should be working as it is if the alias is correct. You can go to status –> system logs and click on the resolver tab. In there you can see if the alias was resolved correctly. It will look something like this
Aug 16 00:16:02 filterdns: adding entry 64.2.142.188 to table voipservers on host outbound.vitelity.netFWIW my floating rule looks similar. The first 2 entries were for some external phones but those entries are now removed.
-
I'm as sure as what the rep from phone.com told me. I can also see in the logs that the address is actually resolving. ???
Regarding the transparent proxy - yes, I'm running Squid.
@KOM:
You're positive that you have a correct alias for Phone_SIP_Server? When you say transparent proxy, are you talking about Squid?
As for the wizard, it's a one-size fits-all GUI. Bandwidth totals up/down are used by the HFSC shaper to do its calculations. PRIQ doesn't use it, but it doesn't surprise me that the wizard bugs you for it. You can enter anything.
-
That's an idea…
I'll try that and see if it makes any difference!Perhaps your rule might work better if you used the port for SIP instead of the server IP under the floating rule section. This way ANY SIP traffic will get shaped how you want it.
-
Yep, I see an entry in the logs that basically looks like that. It is resolving.
The rule should be working as it is if the alias is correct. You can go to status –> system logs and click on the resolver tab. In there you can see if the alias was resolved correctly. It will look something like this
Aug 16 00:16:02 filterdns: adding entry 64.2.142.188 to table voipservers on host outbound.vitelity.netFWIW my floating rule looks similar. The first 2 entries were for some external phones but those entries are now removed.
-
Squid redirects port 80 traffic to 3128 or whatever the Squid port is, so it shouldn't have any effect on your queue rules. Is your SIP server a device on your local subnet?
-
So, playing around with the floating rules and monitoring firewall logs and states, I can see that something isn't working here.
I've modified the floating rule for outbound connections so that it's looking for a SRC port range from 5060-5070
I've configured the floating rules to be set to log-on-match.
I've confirmed in the states table listing, after establishing an outbound call to my cell phone, that there is a state entry for the SIP phone using port 5060 and 5070
192.168.0.135 is the static IP assigned to the SIP phone. 72.1.46.10 is the translated address for the SIP proxy. (the same one I was using for my alias)udp 72.1.46.10:6060 <- 192.168.0.135:5070 MULTIPLE:MULTIPLE
udp 192.168.0.135:5070 -> 76.97.14.107:56835 -> 72.1.46.10:6060 MULTIPLE:MULTIPLE
udp 72.1.46.10:6060 <- 192.168.0.135:5060 NO_TRAFFIC:SINGLE
udp 192.168.0.135:5060 -> 76.97.14.107:2557 -> 72.1.46.10:6060 SINGLE:NO_TRAFFICAlso, I'm seeing these other entries that are using non-SIP related ports. Not sure what these are for:
udp 72.1.46.24:26598 <- 192.168.0.135:16056 MULTIPLE:MULTIPLE
udp 192.168.0.135:16056 -> 76.97.14.107:8831 -> 72.1.46.24:26598 MULTIPLE:MULTIPLE
udp 72.1.46.22:31574 <- 192.168.0.135:16058 MULTIPLE:MULTIPLE
udp 192.168.0.135:16058 -> 76.97.14.107:50117 -> 72.1.46.22:31574 MULTIPLE:MULTIPLESo after establishing the call, I see the above related entries in the state table, but I do NOT see any logging occurring in the firewall logs. ??? :o
So if I don't see this activity being entered in the logs, then PFS isn't recognizing this SIP traffic as matching the floating outbound rule….which means PFS is not putting this traffic in the qVoIP queue!
So the question then is....why isn't the outbound traffic matching the floating rule??
[EDIT]
Try playing around with the Outbound floating rule some more to try and get things to match and have it show up in the firewall logs. Now using the SIP phone's IP address as the SRC.
Looking more closely at the firewall logs, I can see when after making an outbound call, there's a log for a 'block' that is due to my SIP outbound floating rule. This makes NO sense!
The UPSTREAM being referenced is the floating rule, which is simply configured to match the source (phone@192.168.0.135) to ANY/ANY (below)
Is something broken here??
-
my SIP phone is on the local subnet. The SIP server is on the 'net, owned by the SIP service provider.
@KOM:
Squid redirects port 80 traffic to 3128 or whatever the Squid port is, so it shouldn't have any effect on your queue rules. Is your SIP server a device on your local subnet?
-
I would delete your shaper and start again. Ensure 72.1.46.10 is your VoIP_Server alias. Create a simple PRIQ shaper with just VoIP support and use your alias as the provider. Then make some test calls and see if there is traffic in qVoIP.
-
I've actually blown everything out (shaper) before this…a couple of times.
I'm not sure how I can verify the IP addresss of the SIP server, short of contacting the provider and asking them...again (I actually asked them for the IP address initially, but they didn't know...could only tell me the FQDN, which I figured was fine).I'm assuming then that from what you're seeing in the screenshots, that nothing is specifically configured wrong, right? You're thinking that the system is just confused somehow and want me to wipe everything out and start again?
@KOM:
I would delete your shaper and start again. Ensure 72.1.46.10 is your VoIP_Server alias. Create a simple PRIQ shaper with just VoIP support and use your alias as the provider. Then make some test calls and see if there is traffic in qVoIP.
-
Yep. Start again with something simple and then build on it. When I asked about your alias, I meant in your Alias table in pfSense. If you have the alias misconfigured, the rule won't ever match the traffic. For testing purposes, use the IP address instead of the alias. You can always change it later.
-
So…something a little interesting. :)
I decided, despite the weird behavior with the firewall log not showing a match...and that it's blocking that earlier connection outbound, I tried to just make an outbound call and watch the qVoIP queue anyway.
Queue is working!! >:( :o ;D
Tested with an inbound call. (This floating rule hasn't been modified and looks the same as it always has - using the alias). Queue is working.
Okay...so thinking maybe somewhere along the line I unknowingly fixed something 'somewhere', I decided to change the OUTbound floating rule back to its previous auto-generated state.
Queue no longer working!For now, I'm just going to configure the outbound rule to match the SRC address of the SIP phone. Apparently, there's an issue with having the Outbound rule match when the DST is the SIP server. BTW, the fact that the queue works for inbound must mean that the SIP server alias must be correct.....so therefore, it should work on the OUTbound side too.
-
Interesting. I'm glad to her it's working for you. I wonder why it didn't work with the auto rules.
-
Unless I have something configured somewhere that I'm not seeing that is causing this, it would seem to be bug.
