"reset all states" box does not seem to work as advertised.

chpalmer

Cablemodems without routers usually answer to 192.168.100.1 and will give out an address via DHCP when not connected so that the user can access the modem GUI for troubleshooting. If they are connecting to the headend then they do not hand out addresses.

Is the AT&T modem Uverse?

compsmith

@chpalmer said in VoIP SIP Trunks randomly disconnecting:

Cablemodems without routers usually answer to 192.168.100.1 and will give out an address via DHCP when not connected so that the user can access the modem GUI for troubleshooting. If they are connecting to the headend then they do not hand out addresses.

Is the AT&T modem Uverse?

At the location I added 192.168.1.254 it is an AT&T uverse modem with IP pass-through enabled for the pfSense router. I used 192.168.1.254 as that is the address of the uverse modem but I believe this also prevents pfSense from getting a DHCP public address as none of the locations have Static IP's.

Side note I also have this enabled but the state remains.

chpalmer

@compsmith said in VoIP SIP Trunks randomly disconnecting:

192.168.100.11:5060

Your not seeing this state while connected behind the Uverse connection are you?

Yes do not block the DHCP server on the Uverse.

compsmith

@chpalmer said in VoIP SIP Trunks randomly disconnecting:

.100.11:50

No that example was at a Comcast location. I have more issues at AT&T sites than Comcast by far and wanted to test that setting at one of those locations but pfSesne wouldn't get a public ip with it enabled.

Here is a couple AT&T sites.

192.168.1.73:6228 (10.2.13.2:5060) -> 208.xxx.xx.xxx:5060
10.2.13.2:5060 -> 208.xxx.xx.xx:5060	NO_TRAFFIC:SINGLE

VOIPVLAN	udp	10.2.14.2:5060 -> 208.xxx.xx.xx:5060	MULTIPLE:MULTIPLE	223.387 K / 2	131.94 MiB / 1 KiB	
WAN	udp	192.168.1.198:5060 (10.2.14.2:5060) -> 208.xxx.xx.xx:5060	MULTIPLE:MULTIPLE	223.387 K / 2	131.94 MiB / 1 KiB

chpalmer

What do your incoming WAN rules at the sites look like? For the VOIP in particular??

compsmith

@chpalmer said in VoIP SIP Trunks randomly disconnecting:

What do your incoming WAN rules at the sites look like? For the VOIP in particular??

What I attached in the OP is the inbound NAT rule and has an associated WAN rule

chpalmer

Hard to tell without actually seeing your aliases. But all my VOIP locations work without a hitch. I do not use local PBX but only from a cloud provider.

It appears then that your behind double NAT at the Uverse locations..??

SIP was not originally designed to be behind any NAT. It was only added (hacked in) later as the idea of residential users caught on. Double NAT can be really troublesome in a lot of cases. Im not sure Id even try it behind anything with the Uverse router in the way personally. Id be wanting to bypass it. But thats me.

So question would be "Has it ever worked without issues"? Have you contacted voip.ms to see if they are having issues? They seem to be a smaller one man type operation from what I see over at DSLR. Im understanding that the connection between the PBX and VOIP.ms servers is the issue..correct?

compsmith

Hard to tell without actually seeing your aliases. But all my VOIP locations work without a hitch. I do not use local PBX but only from a cloud provider.

It appears then that your behind double NAT at the Uverse locations..??
No there is a setting in the Uverse modem to pass the exteral IP addresst to the pfSense router disabling any routing and firewalls on the Uverse modem.

SIP was not originally designed to be behind any NAT. It was only added (hacked in) later as the idea of residential users caught on. Double NAT can be really troublesome in a lot of cases. Im not sure Id even try it behind anything with the Uverse router in the way personally. Id be wanting to bypass it. But thats me.

So question would be "Has it ever worked without issues"?
Yes at some locations

Have you contacted voip.ms to see if they are having issues?
Started there had them do some live loggin but there we not getting any register attempts when led me back to pfSense
They seem to be a smaller one man type operation from what I see over at DSLR. Im understanding that the connection between the PBX and VOIP.ms servers is the issue..correct?
I wouldn't say they are a small one man provider. They have servers all over the US. This isnt a issue with their service.

The main issue is the bad route states being set by what i assume is a service disruption with the ISP which then sets the route to a private IP address:

VOIPVLAN	udp	10.2.12.2:5060 -> 208.xxx.xx.xx:5060	NO_TRAFFIC:SINGLE	220.064 K / 0	132.12 MiB / 0 B	
WAN	udp	192.168.100.11:5060 (10.2.12.2:5060) -> 208.xxx.xx.xx:5060	SINGLE:NO_TRAFFIC	220.064 K / 0	132.12 MiB / 0 B

Deleting these states the PBX will reconnect immediately

VOIPVLAN	udp	10.2.12.2:5060 -> 208.xxx.xx.xx:5060	MULTIPLE:MULTIPLE	90 / 85	55 KiB / 48 KiB	
WAN	udp	98.xxx.xx.xxx:5060 (10.2.12.2:5060) -> 208.xxx.xx.xx:5060	MULTIPLE:MULTIPLE	87 / 85	54 KiB / 48 KiB

So the state is remaining despite the public address being set in pfsense. IF pf sense temporally get a private ip address due to a brief service outage then goes back to the public ip this setting should clear all states but is not.

chpalmer

@compsmith

Yep- I get that the cable connection might assume an address from the modem in the cable modem range. But not the Uverse modems. I would assume that your pfsense in those instances always has a WAN address in the 192.168.x.x range. Thus being behind double NAT. If that is true then the states would always show that address. Please clarify that.

The cable modem problem is probably a different horse. If the state tries to connect and does not clear then that is an issue that should be duplicatable anywhere else by someone with a similar setup.

If I pull the cable off my modem and let it sit it would actually take a bit for it to start handing out addresses on 192.168.100.x. In fact the only time it seems that it ever does is if I re-boot it and not the router. I would assume that any cable modem would be similar but could be wrong as Ive not tested them all. The issue as to why your modem decides its a good time to do that should be looked into.

You should change the title of the thread here to detail that the "reset all states" box does not seem to work as advertised. Many will be turned off by VOIP in the title if they do not understand it. Actually by what that box says in the description it should not be necessary in your case.

Looking at System/Routing.. how are your gateway functions set up? Specifically "Gateway Action" ??

chpalmer

Uverse modem would actually be the "gateway" that probably does not drop when service suffers. Setting a different monitoring address (such as the next hop off site) would help to trigger "gateway" events such as dropping states. For the gateway event to happen the pings have to change.

aaronpaker

This post is deleted!

compsmith

@chpalmer

Yep- I get that the cable connection might assume an address from the modem in the cable modem range. But not the Uverse modems. I would assume that your pfsense in those instances always has a WAN address in the 192.168.x.x range. Thus being behind double NAT. If that is true then the states would always show that address. Please clarify that.

Ok to clarify and show examples, the all The AT&T uverse locations have a public IP address inside pfsense not a private.

In the AT&T IP Passthough is enabled for the MAC address of the pfSense router.
https://forums.att.com/conversations/att-internet-equipment/strict-nat-bridge-mode-what-is-ip-passthrough-can-i-enable-on-my-arris-bgw210-or-like-router/5defbfffbad5f2f606ad5ed2

The IP address of the AT&T modem is 192.168.1.254, so I believe when a brief loss in service occurs an invalid state is set for a private IP address in that subnet on the pfSense WAN. The 208.xxx.xx.xx:5060 is my SIP trunk provider. Here is an example of a bad state:

WAN	udp	192.168.1.198:5060 (10.2.14.2:5060) -> 208.xxx.xx.xx:5060	SINGLE:NO_TRAFFIC	223.387 K / 0	131.94 MiB / 0 KiB

After I delete that state the PBX connects immediately. Here is an example of what the state should be:

WAN	udp	108.xx.xxx.xx:5060 (10.2.14.2:5060) -> 208.xx.xx.xx:5060	MULTIPLE:MULTIPLE	16.047 K / 15.578 K	9.48 MiB / 8.59 MiB

Would enabling this option help clear that state automatically?

I have this option enabled already:

The cable modem problem is probably a different horse. If the state tries to connect and does not clear then that is an issue that should be duplicatable anywhere else by someone with a similar setup.

If I pull the cable off my modem and let it sit it would actually take a bit for it to start handing out addresses on 192.168.100.x. In fact the only time it seems that it ever does is if I re-boot it and not the router. I would assume that any cable modem would be similar but could be wrong as Ive not tested them all. The issue as to why your modem decides its a good time to do that should be looked into.
Lets focus on the AT&T DSL uverse service. The cable service rarely has issues but I have had the same issue.

You should change the title of the thread here to detail that the "reset all states" box does not seem to work as advertised. Many will be turned off by VOIP in the title if they do not understand it. Actually by what that box says in the description it should not be necessary in your case.

Looking at System/Routing.. how are your gateway functions set up? Specifically "Gateway Action" ??

chpalmer

@compsmith

Under Gateway Actions-

Ive asked for a bit of information from a friend back east from me with Uverse how his setup works.. He has several statics however so Im not sure if things work the same.

compsmith

I need to bump this issue because I am still experiencing issues with all the suggestions given.

compsmith

@compsmith said in "reset all states" box does not seem to work as advertised.:

I need to bump this issue because I am still experiencing issues with all the suggestions given.

Does anyone else have any suggestions how i prevent this from happening as this is still a issue