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



  • I have recently been having a lot issues with our VoIP PBX's trunk being randomly disconnected at multiple locations. Each location has a Netgate firewall and an Asterisk PBX linked to SIP phones. Our provider is voip.ms.

    On the firewall I have a port forward NAT rule using Aliases for the SIP trunk url's from out provider as well as all the necessary ports.
    nat.png

    Outbound NAT rule is in place
    outbound.png

    Firewall optimization Options is set to conservative.
    NAT Reflection mode for port forwards is set to Pure Nat.
    Enable automatic outbound NAT for Reflection is checked.

    I believe the trunks are randomly being disconnected due to a invalid state being set.
    At this specific location using Comcast as an ISP the VoIP subnet is 10.2.12.0/24. Here are the invalid states

    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 2 states the trunks will immediately reconnect. What is odd to me is where is the firewall is getting the 192.168.100.11 address? None of the subnet at any of these locations use a 192. address they are all 10. At this location we have a customer owned cable modem which passes the external IP address to the firewall. At first I thought it was just an issues with locations that have AT&T DSL as they require us to use their modem/router/firewall/AP but in these devices I enable IP pass-through to get the external IP address in pfSense. I thought it may have been a issue with those devices but this is on a Comcast gateway that has no routing or firewall capabilities. Other locations have a similar issue at AT&T ISP locations we get a random 192.168.1.0/24 address in the state.

    After deleting the 2 states here is what a working state looks like

    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
    

    Does anyone have an idea what is going on here?



  • Looks like your firewall may be grabbing an address from the modem before it gets its true public IP. Just a guess though. Verify that your modem is not one of the affected Puma6 equipped models and that if it is the firmware is up to date. See my sig below. VOIP UDP traffic can really affect these.

    You could tell your pfsense to ignore DHCP answers from the modem itself on your WAN interface page.

    See if that helps.



  • @chpalmer said in VoIP SIP Trunks randomly disconnecting:

    Looks like your firewall may be grabbing an address from the modem before it gets its true public IP. Just a guess though. Verify that your modem is not one of the affected Puma6 equipped models and that if it is the firmware is up to date. See my sig below. VOIP UDP traffic can really affect these.

    You could tell your pfsense to ignore DHCP answers from the modem itself on your WAN interface page.

    See if that helps.

    I noticed the "Reject leases from" option in the WAN interface settings. Is this what you are referring to? Im not even sure what the default address of these cable modems are or how they even hand out a 192.168.x.x address as they have no DHCP server. I can block the AT&T modems as they 192.168.1.254.
    wan-dhcp.png

    This issue is a mixture of customer owned cable modems and DSL modems given to us by AT&T. Was the Puma6 equipped models only on cable modems?



  • Adding the IP address of the AT&T modem caused a complete outage of service.



  • 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?



  • @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.
    network.png



  • @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.



  • @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
    


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



  • @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
    nat.png



  • 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?



  • 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.
    network.png



  • @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" ??



  • 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.


  • Banned

    This post is deleted!


  • @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.
    interfaces.png

    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?
    misc.png

    I have this option enabled already:
    network.png

    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" ??
    gateway.png



  • @compsmith

    Under Gateway Actions- gateway.jpg

    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.


Log in to reply