Raspi SBC v16 throwing tcp disconnect flags w sonicwall

[drewt]

Raspi sbc on 192.168.1.222 would not connect after sonic wall rules update, had to make a nat'd dmz port on sonicwall, with ip scheme of 192.168.4.222 and have sonic wall transate between the two subnets and phones can then connect. I have two questions,

1) I think i should enter the new sbc ip as 192.168.4.222 in the gui, as this is how phones reach sbc from 192.168.1.x Corrrect?

2) Company that manages firewall says that the sonic wall was getting a tcp disconnect flag and was therefore refusing to allow traffic, im waiting for a technical recap of the problem from the vendor. Tech said less secure firewall doesnt have this problem. Does this make sense? i thought sbc on 5090 was specifically engineered to avoid such problems. When I ran the raspi sbc through a verizon router setup in a non nat'd dmz port on the sonicwall the sbc connected right up.

3) I have a second raspi sbc at 192.168.4.220 and I had manually entered this into the yealink t48s gui. after a few weeks, I find that both the primary and secondary are now listed in the yealink gui as 192.168.4.222. Is there a way to stop 3cx from changing this to the listed primary in the sbc ip setting? Can two seperate ip's be listed in the 3cx provisioning tab?

Thank you for anyone's comment or advice in advance.

Drew

 

[cobaltit]

1) Huh? SBCs are designed to help with NAT traversal. To do so they should be in the same subnet as the phones. So if you actually have your SBC in a different subnet than the phones that's problem number one.

2) Does it make sense that Sonicwall's are problematic? Yes. Does it make sense that devices that do more than just basic packet inspection can be more picky? Yes. If this happened after a rule update, I don't see where the confusion is. It's either an overly sensitive rule (which happens sometimes) or the communication methods the SBC uses happens to also match a potentially malicious pattern as deemed by 3CX. Seems easy enough to fix.

3) You have to decide how you want to manage your phones. Yes it's expected that provisioned phones will re-provision and erase the settings you put in there.You can stop it by not provisioning the phones via 3CX. No you can't put two SBC IPs in the UI, but you can make a custom template to list both.

 

[drewt]

1) Huh? SBCs are designed to help with NAT traversal. To do so they should be in the same subnet as the phones. So if you actually have your SBC in a different subnet than the phones that's problem number one.

DPI was blocking conx with sbc's, could only stop DPI by putting both sbc's directly into sonic wall x2 and x3 setup as nat'd dmz port without DPI on sonic wall, with ip scheme of 192.168.4.222 and have sonic wall translate between the two sub nets and phones can then connect. Works fine for now, but a reset of the sonic wall will wipe that out. I was wondering if anyone had this happen before and if they had any insight on SBC config that could prevent TCP disconnect flags being transmitted. It was working fine for almost a year.

2) Does it make sense that Sonicwall's are problematic? Yes. Does it make sense that devices that do more than just basic packet inspection can be more picky? Yes. If this happened after a rule update, I don't see where the confusion is. It's either an overly sensitive rule (which happens sometimes) or the communication methods the SBC uses happens to also match a potentially malicious pattern as deemed by 3CX. Seems easy enough to fix.

Customer is a bank, and while Im in house IT, the firewall is managed by third party, fedcomp, that runs their cloud infrastructure, who says everything is fine, and I have no recourse to mod signatures. Im gratefull they setup the 192.168.4.x arrangement.

3) You have to decide how you want to manage your phones. Yes it's expected that provisioned phones will re-provision and erase the settings you put in there.You can stop it by not provisioning the phones via 3CX. No you can't put two SBC IPs in the UI, but you can make a custom template to list both.

Turns out I was putting the backup sbc in the primary proxy server entry in the yealink gui mistakenly, and the re provision would over write only the primary proxy server, leaving me with identical entries for proxy 1 and two. I fixed manually. I need to address the custom template.

Cust has 6 T48G's, a yealink model that I have successfully used in a wireless config at another cust and had no problems. I was thinking of putting these on a completely separate wireless network that they have, with their own sbc's, leaving 3 T21's on the wired network. Avoid the sonic wall altogether. If the wireless network goes down, they can plug in ethernet, which disables wireless, and run on the sonicwall. If the sonic wall goes down I could have workstations setup with a wireless usb they plug in and run on the wireless. Thoughts? Thanks for taking the time to respond to my post!

Drew

 

[cobaltit]

1. So I'm still a little unclear on this bit. DPI shouldn't be touching the traffic if you have the phones and SBCs in the same subnet hanging off the same port on the Sonicwall. Or are you saying that because of the settings on the phone subnet the SBC wouldn't connect out to 3CX so they had you put the SBCs in a different subnet to relax the rules?

2. Ugh.. I understand better now and I feel for you. Is 3CX hosted by fedcomp as well?

3. Are phones currently on their own network?