Landline phone with own router on FTTP

[bruce_miranda]

Just got FTTP and everything is working fine off the VF router. Phone lines are plugged into the VF router, VF router's WiFi is switched off. 3rd party Mesh has been switched to Bridge mode and plugged into the VF's ethernet port.

However I am shocked at how feature poor the VF router is. e.g. There are no Parental controls at all. I know I can get rid of the VF router and plug my own Mesh router into the Openreach ONT, but what about the Landline. 

Are there any 3rd party routers in the market that have a telephone socket at the back to allow the home phone to be plugged in? 

[Madmanmav]

Has anyone got this to work with OPNsesne router ?
I bought a H812 and followed the settings in this thread , set NAT to STUN but I am struggling to get it through OPNsense's firewall.
I setup and old ASUS router and the H812 registered and I could call out and call in (though calling in the phone never rang , but picking it up I could hear my voice both ends ,, maybe a ringer setting i am missing ?)
I have tried allsorts on OPNsense to no avail.
Any advice would be appreciated.

[Madmanmav]

OK so I got this working in OPNsesne with the following settings

Step1 Create an Alias for the H8xx pointing to its LAN address (i.E 192.165.1.XXX) i called mine grandstream
Step 2 Create an Alias for ports 5059 and 10000 (type ports UDP) I called mine voipports

Step 3 create inbound rule 

Interface Proto Address Ports Address Ports IP Ports Description     

WAN

UDP

*

*

LAN address

Voipports

Grandstream

Voipports

Step Goto to outbound rules and select HYBRID MODE

Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description  STATIC 

WAN

LAN net

*

*

*

Interface address

*

YES

Goto to firewall > advanced and set

Network Address Translation
Reflection for port forwards
Reflection for 1:1
Automatic outbound NAT for Reflection

Also in firewall avanced set 

Firewall Optimization

conservative

Setup HT8XX as mentioned in this tread.

IMPORTANT reboot router to reset firewall state tables as anothe rule may have already taken these ports ad assigned the to other uses , so a reboot of router will free ports and H8XX should then be able to register fine.

Was fighting this for days and much of that time i had it right but the state tables needed resetting , so a router rest IS required , once connected and registered it should stay connected fine.

[Bigfluctuation]

Hey, I'm sorry I missed your original post. I did include a section for Opnsense in my Github repo here: https://github.com/mouldybread/VodafoneUKVOIPConfig

You're 99% of the way there but your OUTBOUND nat rules need to include your alias as the source, otherwise you're effectively disabling outbound port remapping(by setting STATIC=YES) for all devices on both udp and tcp which will cause intermittent connectivity issues if more than one outbound connection from your network uses the same source port.

According to Ripshods configuration (and as I have it working) the SIP port should be 5065 instead of 5059.

RTP (which SIP uses for audio transport) usually uses a range of random udp source ports. Ripshods configuration has the local RTP port set to 10000 with a port range of 24, and random port set to yes. When I configured my phone the minimum accepted range was actually 200. I'm unclear as to if this means 10000-10200, but it should.

So your UDP port alias should actually be more like 10000-10200 if you're being conservative and we assume the device is selecting from the "Local RTP port" upwards based on the settings. If you are more concerned with making sure it works: your UDP range should be 10000-32767 which is the full range used by RTP. You can always specify !=RFC1918 if you want to descope.

Picking a random source port is especially important as we have disabled outbound remapping. If something else is (or has) been using UDP/10000, the call will fail(this is the problem that remapping aims to fix after all). So a bigger range is better and relying on a single port may cause intermittent issues.

As far as I know, the firewall settings you mentioned (Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection) should be unnecessary as they relate to port forwarding/nat reflection.

Finally to reset state tables without restarting you can go to Firewall -> States -> Actions (tab) and Reset State Table/source tracking.

I hope this helps!

[Bigfluctuation]

Further I just noticed that your inbound WAN rule directly exposes your phone to the internet. This may pose a significant security risk, and is also not needed for your phone to function. Please disable your inbound WAN rule ASAP. Perhaps a moderator can edit the original post and remove that part?

[Madmanmav]

Thanks for the tips ,
Yes you are correct the port is 5065 , that was a typo but could not see where to edit the post. 
The inbound port forward rule should be only exposing ports 5065 and 10000 to the phone , the admin interface on port 80,443,22 aren't exposed with that rule. Without the rule I could not get it to work at all.
The rule without aliases would be as follows
Scource                                                                     Destinantion
interface      protocol   address  ports                address    ports                    IP                      ports
WAN            UDP           ANY       ANY                 LAN          5065 10000        VOIP LAN IP     5065 10000
so only 5065 and 10000 should be exposed I beleive ,, i will look at the link provided thankyou.
exposing only those two ports has so far been solid ,, originally I had the rule forward 5060-5065 and 10000-20000 ,, but paired it back to just those two ports which seem to work ,, i have disabled direct IP dailing in the ATA. I agree ideally I would limit the inbound IP range to vodaphones block. thanks for the tip and resetting states ,, i will now go and read the link you provided and reply here.
Thanks once again ,, been banging my head on the wall for a while with this.

[Madmanmav]

@Bigfluctuation I heave read through your wrtiup , excellent , i wish I had know about it sooner ,, not sure how I missed it as I have been back and forwards through the tread a few times reading up. I though have tried disabling the rule and can't seem to get inbound calls without it. I don't have a static IP and am using fullcone STUN as per a tip i think @Ripshod posted , could that have a bearing ? 
I will be honest I am not great in OPNsense , especially with rules as i find the nomenclature somewhat counter intuative at times. I originally thought Unbound might be a cause for the problems.
As I mentioned I tried it on a spare asus A88u I had laying around running the Merlin firmware and it just worked (after wrestling the ATA setting provided by @Ripshod et all).

I feel it would be great to get a definitive setup for each working ATA/PHONE ,as I did note when cribbing from others posted setups that a number of them disagreed on certain features.
As an aside
I wanted to confirm my settings with voda (they had already provided them but they were scribbled down and i figured I might have an I for a 1 or o for a 0 that sort of thing) ,I had got them no problem first ime round but the next guy refused to provide them or confirm the ones i had were correct , so I escalated this up to the top teir.
They were very helpfull appologised and reprovided them , they also said they do an adapter that would plug ino the network and work with third party routers and would send one free of charge. GREAT I thought Voda are providing a Voda branded ATA , I nearly posted here with this marvelous revelation.
A few days later the "device" arrived ... It was an RJ11 to BT connector wire 😂

[Bigfluctuation]

Hi,

You can use the live view (Firewall -> Log Files -> Live View) to see exactly what's happening when you enable/disable your WAN INBOUND rule. Does it match anything? Upon re-reading your instructions it shouldn't match anyway as the packets won't have the VOIP devices LAN IP in the destination field when they hit the WAN side.

At any rate an INBOUND ALLOW rule on the WAN interface is potentially risky and isn't needed for VOIP as OPNSense stateful and tracks outbound connections. As a general principle, allowing any unsolicited traffic from the internet to reach your devices is undesirable.

In terms of OPNSense, Full Cone NAT is called Static Port Mapping and is what you have configured with your NAT Outbound Rule. Generally I think limiting the scope of this rule to devices that need static mapping is preferable as Port Remapping does serve an important purpose and any resulting problems will be transient and hard to trace. In your case this may be why the phone would only work after resetting the state tables - another connection likely used the same port.

In terms of the device I found that any setting other than 'No' for NAT Traversal resulted in the phone not working. When I'm able to find some time I may look at this further but as it is up and running for me with no issues it's not a high priority.

STUN gives the device a means by which to determine the external IP and negotiate a connection in symmetric(full cone/static NAT) environments. See RFC3489 for the full specification. It's not perfect and there are already proposals that supersede STUN. As per my instructions STUN wasn't necessary to get my phone working, though I did manually specify my external IP.

From your instructions I think you've implemented parts from the three different approaches outlined in my write up. This is understandable given the amount of confused/incomplete/outdated documentation floating around, but the steps I outlined should be enough to get your phone working without any additional steps.

FWIW I found this thread: https://community.freepbx.org/t/happiness-with-sonicwalls-it-can-happen/39463 which is full of people who also discovered that certain PBX don't work unless Static Port Mapping is enabled. This is probably because the PBX in question are doing something similar to what is described here: https://www.sonicwall.com/support/knowledge-base/troubleshooting-a-scenario-where-source-remap-is-ca... 

[Madmanmav]

I agree , Ideally there would be no holes poked through, but without I simply doesnt work for me.
The forward is limited to a single IP though that of the h812 ata and only the 2 UDP ports 5065 and rtp 10000.

The hybrid rule on outbound from what I understand essentially converts opnsense to a type2 nat , I could limit the translation fron the lan net to a sigle IP i suppose , making that ip moderate and the rest type 3 and have only that IP statically mapped. I did try this but had no joy , but this may have been down to my firewall tables not being reset after that change.

I will take another look at it , I am not overly concerned about the 2 forwarded ports to a single IP , unless there is a way to hack the ATA on those 2 ports it should be ok for time being but I will relook at this and thankyou for your pointers. I will post some feedback next time i have a play. I don't actually use the landline but my folks do and they were without phone for some time , so i will let them have their fill of poinless jibber jabber for now before i potentially cut them off again

[Ripshod]

My experience agrees totally. Port forwarding is necessary. It wouldn't be necessary if the ata device is built into the router, but as these devices are seperate from the router and have their own local network IPs the traffic needs to be steered to them.

[Bigfluctuation]

@Ripshod Infact we are talking about a firewall rule here, Madmanmavs has not mentioned port forwarding in his write up..

However I believe that contrary to your experience port forwarding is not always necessary and the reasons for that are quite complex.

It seems to largely depend on how the PBX is authorising clients. I wonder if Vodafone is doing a mix of both username + pass for the SIP Signalling and IP+Port for the media proxy. Check out https://community.freepbx.org/t/sip-port-forwarding/45446/3 and https://community.freepbx.org/t/sip-port-forwarding/45446/4 for a fairly great explanation.

In my case I do not need to use port forwarding to make Vodafone VOIP work behind an OPNSense router. 

Working backwards from that, I think that in your environment port forwarding acts as a hack/trick to prevent the state of the WAN port from hitting its timeout and being reassigned. But for OPNSense users it is not necessary because we are able to disable Port Remapping via scoped OUTBOUND NAT rules.

Briefly, no two computers can know which ports are in use on the routers WAN interface. No two connections can use the same source port at the same time. Hence NAT will remap source ports as packets leave the network. When the remote machine sends packets back they are addressed to the remapped ports. The NAT will then rewrite the destination IP as the packet crosses the router, knowing which uniquely assigned remapped port is applicable to which computer on the local network. Thus allowing multiple computers to originate packets from the same source port.

For example:

Computer A initiates an outbound connection with a source port of 100005. The router rewrites the packet as it exits the network to port 100010.

Computer B initiates an outbound connection with a source port of 100005. The router rewrites the packet as it exits the network to port 100011.

This is tracked in the state table. When the inbound packets are sent to the WAN interface from the remote computer they are addressed to the external IP with a destination port. The router knows that packets arriving with a destination port of 100010 are for computer A and rewrites the destination port and LAN IP accordingly. The same is done for packets with a destination port of 100011. This allows two machines to seamlessly share the same source port.

Eventually after a predetermined period the state of the WAN port will reset and the assigned WAN port will change. You may occasionally see solutions which involve increasing this time out value as a way to ameliorate VOIP devices dropping registrations.

When you port forward you effectively force that port into a permanently mapped state - all packets arriving on the WAN INBOUND interface with that destination port are always delivered to the same LAN IP. 

I think this is important to note because we would usually assume port forwarding is about routing unsolicited incoming packets to a LAN IP, but for VOIP it seems to be a trick to extend the state of the port on the WAN interface beyond the usual timeout and prevent other connections from using that port. 

In mine and @Madmanmavs case we are able to configure our router so that port remapping is disabled on a per device/per port basis without the need to ‘trick’ the router into not remapping the port by using port forwarding.

WRT the onboard PTSN adapter, those are probably connected to an ethernet port just the same as any other device, albeit using traces on the board instead of an 8P8C connector. The only difference is that Vodafone can get in and meddle with whatever settings they want with full knowledge of both client and server and then lock it down and hide the mess when they’re done. Given how ugly all of the above is I’m starting to understand why they took this approach.