Wednesday, February 17, 2021

Remote SIP Extensions

Sorry for the long post, I tend to over-communicate and write short novels.

I'm the network guy at my job and we have a dedicated phone tech. The two of us have for years wanted to get remote SIP phones working. He wanted it for our contracted AV company to be able to just plug a phone into the guest network and it'd connect to our phone network, I wanted it for working from home during snowstorms. Covid came and now the higher-ups want to make it happen, and here we are. Also in a big snowstorm, which is just funny timing.

Our phone vendor set us up with NEC's remote client, tested it from a computer (tech server) on the phone network and gave us the addresses/ports we'd need to get things up and running.

We are PCI-beholden so have 3 networks: admin, phone, and guest. No VLANs, each is a flat network. I put a Fortigate in place to bridge between phone and guest, to either be a VPN (split-tunnel it so only SIP traffic goes over and users can still use their own devices), or even potentially VPN-less using a FQDN and some port forwarding. On Fortigate's VPN I could ping everything to my heart's desire but couldn't actually register the extension. Same using the FQDN, no matter the settings.

Yesterday I gave up and replaced the Forti with pfSense. The Forti was old and not covered by an active license, I thought maybe it wasn't working because of that. pfSense definitely gives me more information, but it still doesn't work. With OpenVPN through pfSense I can ping the tech server (gateway for that NIC is the pfSense firewall), but nothing else.

I can Wireshark and check logs all I want, the NEC client is sending SIP REGISTER packets to the proxy port but nothing is coming back across. If I plug my laptop into the phone net it registers immediately, but on guest or at home nothing comes back. On both Forti and pfSense I have the vendor's listed ports whitelisted from WAN -> LAN, and LAN -> WAN is unrestricted.

Here are the generals:
Phone net: 10.1.0.0/23
Phone switch: 10.1.0.5
Phone proxy: 10.1.0.5:5080
Firewall phone net addr: 10.1.0.20
Tech server: 10.1.0.10
VPN client net: 10.1.10.0/24
Guest net: 10.10.0.0/22
Firewall guest net addr: 10.10.0.20
FQDN: phonevpn.contoso.com (Peplink NATs the public IP to a private IP on guest)

The phone switch and other devices have their gateway set to 10.1.0.1, the new firewall is 10.1.0.20. I have no idea what the 0.1 device is, that network is managed by the phone vendor so I haven't touched anything on it ever.

My line of thinking is: because the gateway is set to 0.1, when NAT-ed requests come through the VPN or FQDN via 0.20, the phone switch is replying but since they're originating from different networks/subnets it sends to 0.1, which has no idea what I'm trying to do and drops the packets. I haven't yet put Wireshark on the phone network side to see what it's doing but I can try that tomorrow.

We have an NEC phone switch with a mix of SIP and analog phones. My suggestion to the vendor was to change the gateway at least on the SIP blade of the switch to 0.20, but we also have a cloud provider (BluIP. DIDs hit them first and then if the land network goes down their router switches to cellular) so I don't know how that would affect normal operation.

All this to say: am I in the right direction with thinking the phone switch can't reply to the REGISTER requests because it's sending to its default gateway instead of directly? I'm out of my depth with phone stuff, and we don't have full access over the switch so I can't test on my own. Our phone tech is retiring soon so I will need to learn more about all this, but at the moment it's still way above me (more acronyms than in networking, it's nuts.) I swear I'm not completely stupid, I've just reached the rabid stage of trying to get something to work.

Thanks for any advice!



No comments:

Post a Comment