VOIP provider after schedule not registering debug help required
-
I have a dual wan setup and a vlan dedicated to a gigaset ip phone. I schedule a schedule to cut the rule between midnight and 6am to avoid spam calls.
I have three VOIP providers, voiptalk, mynetfone and gigaset. mynetfone is the outgoing voip provider. The two rules allow http and voip ports out the primary gateway. i.e. not using failover.
I didn't have any issues with any of the providers re-registering, one the schedule allowed the path through at 6am.
With 2.52 I didn't have any problems, but since I upgraded to 22.0x i am having the following problem.
If I reboot pfsense, all three providers register successfully.
the schedule kicks in at midnight and disconnects all providers.
after 6am the mynetfone outgoing provider re-registers, but the gigaset and voiptalk providers do not.Packet capture doesn't show any errors, and I am stuck on how to debug, given this only started after the 2.60 upgrade
-
All 3 providers register using the same WAN/gateway?
-
@stephenw10 if I understand you, yes.
It's a Gigaset C610A IP and can register up to 6 incoming providers and one outgoing provider. Was working since 2.4x in actual fact. if i reboot the phone, it doesn't help. But rebooting the pfsense allows all connections to register. I think that is because they occur before all the rules are loaded
-
If there were no rules loaded there would be no rules to open an states and you are seeing the state open for one provider. So more likely the connections to the other providers are not matching the rules as you expect.
If you remove the schedule fro9m the rules and reboot do all three connect then?Steve
-
@stephenw10 if i reboot pfsense, all connections are established. If i leave the schedule off, for days, the connections to work even after an interruption to the primary wan connection. It is only after the schedule is activated and the first time the rules are disabled by the schedule, when enabled by the schedule only mynetfone recovers
-
Is opening connections on the wrong WAN?
-
@stephenw10 i have the gateway set on those rules to the primary wan not failover
-
But are there states to those other providers being opened on the other gateway? Like you might have other rules without a schedule that are passing them unexpectedly. Existing open states would attempt to carry that traffic without hitting the scheduled rules the schedule changes.
Steve
-
@stephenw10 these are my rules
These rules are on the PRI WAN interface
p.s. I just realized those gateways are the failover gateways. i have just changed them to the primary WAN
-
I would still check the state table and see what states are opened and where at any time. Either it's trying to open states incorrectly when the schedule starts passing traffic again or there are already bad states open when it does.
Steve
-
@stephenw10 Hi Steve, so I am back to this. Refreshing the memory;
- reboot pfsense
- all three voip providers register
- schedule to block from midnight to 6am kicks in and blocks all.
- 6am only one provider re-registers.
- checked the state tables in diagnostics for the vlan and found voiptalk still registered. (but not on the voip phone)
- deleted the state table and voiptalk immediately registered successfully.
It appears after some period of time or event, the voip will re-register, but it is random and i guess is triggered by my wan falling over, or something.
This never happened under 2.5.2. it is only happening since 2.6x
-
Did you check the state table after the schedule reopens the rules for and states to the other providers?
Also check the states from mynetfone. Are they incoming or outgoing states?
You appear to be forwarding traffic on the Pri WAN but I wouldn't expect that to be necessary for a phone behind the firewall.
Steve
-
@stephenw10 I disabled the forwards and checked this morning.
mynetfone is self registered after the schedule re-opensAs for the States status after schedule opens:
WAN
udp WAN (ipfone) ->mynetphone
VLAN
udp sipgate -> ipfone
udp voiptalk -> ipfone
udp ipfone -> mynetphonedelete VLAN voiptalk state - immediate registration results with the notable difference in the state
WAN
udp WAN (ipfone) ->mynetphone
udp WAN (ipfone) ->voiptalk
VLAN
udp ipfone -> voiptalk
udp ipfone -> mynetphone
udp sipgate -> ipfonedelete VLAN sipgate state - immediate registration results with the notable difference in the state
WAN
udp WAN (ipfone) ->mynetphone
udp WAN (ipfone) ->voiptalk
udp WAN (ipfone) ->sipgate
VLAN
udp ipfone -> voiptalk
udp ipfone -> mynetphone
udp ipfone -> sipgate -
Hmm, so it appears to be the existing incoming states on the internal VLAN interface.
That's interesting for a number of reasons.
It must be the port forward that was allowing those states to be created from the provider to the phone.
They seem to exist only on the VLAN and not the WAN even though they must have come through the WAN initially. So it appears the states were removes or timed out on WAN but somehow not the VLAN.However without the port forward all opened states should be outbound so it should not be possible to get into the situation.
-
@stephenw10 said in VOIP provider after schedule not registering debug help required:
Hmm, so it appears to be the existing incoming states on the internal VLAN interface.
That's interesting for a number of reasons.
It must be the port forward that was allowing those states to be created from the provider to the phone.
They seem to exist only on the VLAN and not the WAN even though they must have come through the WAN initially. So it appears the states were removes or timed out on WAN but somehow not the VLAN.However without the port forward all opened states should be outbound so it should not be possible to get into the situation.
I disabled the forwards and rebooted for this test. They were the results of the first schedule re-open event after. What is particularly interesting is;
the below state does not exist before the schedule block, but only after the re-open.VLAN
udp sipgate -> ipfone
udp voiptalk -> ipfoneThe working ones are in the other direction. Just rebooted again and checked these states. Just rebooted and doubled checked. These states are not created after a fresh reboot and there are no forwards and services are registered. Will check again in the morning to see if it is repeated
-
@stephenw10 hi steve, so checking this morning after the schedule reopened, and the states are showing voiptalk and gigaset in the wrong direction on the vlan segment again.
They were in the right direction before the schedule kicked in last night. Forwarding was deleted, and the unit rebooted last night.
So two things seem strange to me;
-
why do only these two and not all 3 states switch to the wrong direction after the schedule re-opens
-
this behaviour is obviously new in 2.6 because notwithstanding the forwarding, it was working since 2.4.x through upgrades to 2.5.2 without problems
The question is, is this a defect, or is there something I can do as a workaround?
-
-
Hmm. I can't see how those states could be opened and remain open in that direction on the internal interface without also coming in on another interface. Which I expect to be WAN.
Are you sure they are opened in that direction?
You could try adding floating block rules to prevent those states being opened.
Steve
-
@stephenw10 i have checked and rechecked.
- no NAT forward rules
- no WAN forward rules
- only VLAN outgoing rules to VOIP servers/ports
I will check tonight when the schedule kicks in, if the states are being created after the schedule kicks in, or re-opens
-
Well one thing you can do is look at the state table from the CLI to see what rule opened the state:
pfctl -vvss
Then you can look at the rules to see what rule number that is:
pfctl -vvsr
So for example on a local test device:
all tcp 172.21.16.220:443 <- 172.21.16.8:38730 ESTABLISHED:ESTABLISHED [3316238557 + 4286908416] wscale 7 [1246366926 + 65792] wscale 7 age 00:00:33, expires in 23:59:59, 205:428 pkts, 17217:487318 bytes, rule 85 id: 252e1b6300000001 creatorid: 3f804604 gateway: 0.0.0.0 origif: mvneta0
@85 pass in quick on mvneta0 inet proto tcp from 172.21.16.0/24 to 172.21.16.220 flags S/SA keep state label "USER_RULE: Allow access from WAN" label "id:1661983132" ridentifier 1661983132 [ Evaluations: 2004 Packets: 1315 Bytes: 633672 States: 1 ] [ Inserted: uid 0 pid 89931 State Creations: 1 ] [ Last Active Time: Fri Sep 9 15:33:33 2022 ]
Steve
-
@stephenw10 cool. I'll give that a bash tonight once the schedule kicks in and again in the morning when it re-opens. Thanks man