To allow phone to work which is best: ONT-->XT8--> SR203.... OR ONT-->SR203-->XT8

[Pete-da-Meat]

Sorry for the delay.

I've been so busy doing my day job that I've not had much time for my side projects.

I'll try to pen something soon.

[mae-3]

@Pete-da-Meat 

What you have set up is a DHCPv6 PD relay on the edge router which isn't ratified in RFC8987 yet, but your throughs on the subject and your project and this issue and a workaround are much appreciated with anything you can add for future clients of Sky appreciated for VoIP behind an edge router/firewall setup... 😀

[Kevin+D-B]

I thought I'd add my own experience with this conundrum as I've now a working solution as of 10 minutes ago running under openwrt.  First off, no way could have done it without Pete's large clues.  Filling in some of the blanks:

For the Sky router to accept an IPv4 via DHCP from the upstream router it must receive DHCP option 43 with "SkyBB-DHCP" as the value.  dnsmasq is a commonly found dhcp server and the config option is "dhcp-option=43,53:6b:79:42:42:2d:44:48:43:50"

I've dedicated an interface on my own router with a /29 (255.255.255.248 subnet mask) to hand out an IPv4 address to the Sky router.  Similarly I've delegated a /64 IPv6 prefix from the /56 that sky give you over the same interface.  Under openwrt I had to delegate a /63 to the interface so that 'udhcpd' could further delegate a /64 - shame I couldn't just delegate a /64 and be done with it.

Although all the VOIP bit appears to be done using SIP over IPv6, the sky router needs an IPv4 before it'll do anything though due to name resolution only being available over IPv4.

I also had to connect the sky router up directly at one point before it would work, I'm pretty sure it did a firmware update and it's that which downloaded/enabled a SIP client...until that point the 'voice' light didn't even light up orange let alone green.

[frankNsteeen]

And there ladies and gentlemen is proof why I will always be double NAT'd.

As much as I see your fooling the Sky Router into thinking its receiving IP's from Sky I don't have a scooby doo chance of doing that! 🙂 

Unless of course someone can drop it all onto a something like a raspberry pie with an idiots guide I wouldnt know where to start.

[greendragons]

Following @Pete-da-Meat and @Kevin+D-B 's advice above, I've just got the Sky router working behind my Mikrotik router.

It picks up and IPV4 and IPV6 address fine - and voice connects. Annoyingly, voice then disconnects after a few minutes/seconds - and I haven't yet worked out why.

I've tried disabling firewall rules, but I've not found the cause yet.

So close and yet so far! 

[greendragons]

Just revisiting this after life got in the way of my last attempt.

My setup is: Huawei modem -> Mikrotik RB750gr3 -> Sky router

My Sky router is correctly receiving an IPv4 address and a IPv6 PD /60 (from the /56 I receive from Sky) from my Mikrotik router. The Sky router logs show WAN IPV6 UP and (albeit temporarily) that Voice is Connected (with a public IPv6 address as part of the log entry).

The Maintenance tab on the Sky router all looks fine - everything populated as it should be (IPv4 and IPv6) - it has the correct Sky IPv6 delegation.

The Sky router has a route to the internet because the log also shows it 'calling home' successfully, e.g.

syslog: TR69: Connect to Production ACS
syslog: TR69: Connection to ACS Complete
syslog: TR69: Close ACS Connection

I can also connect 'through' the Sky router to the internet fine (i.e. joining the Sky Wifi network) - my laptop also correctly receives an IPv6 address from the delegated prefix.

I can also see a IPv6 dynamic route created on the Mikrotik for the /60 for the correct interface.

But I'm then seeing 'Voice Disconnected' in the log. 

I'm thinking that I'm missing a port forwarding rule somewhere - maybe the VoIP service initiates a connection that's not reaching the Sky router.

Can I please ask @Kevin+D-B and @Pete-da-Meat - did you forward any particular ports to the Sky router to get the Internet calls service working? Or might anyone else know which ports are used?

I'd like to packet sniff a 'normal' connection, but I don't currently have equipment available to do it.

Many thanks in advance for any pointers that might get me over this final hurdle! 🙂

[mae-3]

@greendragons 

Packet sniffing or better still a DPI firewall between the internet and Sky Hub would likely yield results on what's happening handshaking-wise with Sky's headend for VoIP. I do have the equipment but not connected to Sky with Zen! 😎

[frankNsteeen]

Forgive my clear lack of knowledge, but surely if it were a port it would never connect in the first place? (of which you said it does for a few seconds/minutes)

[mae-3]

Most VoIP implementations use UDP port 5060 SIP and 5070 RDP for data communication which is bi-directional so maybe two ports to allow bi-directionally through the XT8 or whatever router in front of the Sky Hub.

[Kevin+D-B]

I wish I could offer some solution to this, unfortunately I have no idea.  My openwrt router doesn't have any special/specific port forwarding.  I'm lucky enough that 'it just works' somehow.

[greendragons]

Thanks all!

I agree @frankNsteeen - it doesn't make a great deal of sense. I'm wondering if maybe the VoIP server is trying to initiate a connection back to the router, the router isn't seeing it, and then concluding voice must be down.

Strangely though, as the 'Voice Connected' log entry shows the public IPv6 address of the router, it seems to suggest that the VoIP system operates over IPv6 (as @Kevin+D-B also suggested previously).

My understanding of IPv6 is that unless I'm specifically blocking a port with a firewall, the ports should all be directly accessible from outside (using the public IPv6 address) - assuming my main router is set up to route the traffic correctly.

(NB. I am using a firewall, but I believe I have excluded the traffic passing through to the specific interface connected to the Sky router)

Thanks @Kevin+D-B - much appreciated. When I get a chance during the week, I'm tempted to try this with OpenWrt - just to see if this is a quirk in my current setup (I can flash the Mikrotik with OpenWrt).

[Kevin+D-B]

@greendragons I don’t know if you got this working in the end however I’ve fallen across a problem with similar symptoms.  For some reason or other the DHCPv6/RA server on my network stopped offering itself as the default IPv6 gateway.  The result being the Sky router couldn’t route IPv6 to the wider Internet and would lead to the voice service disconnecting.  Looking at your logs you successfully connect to the ACS whilst mine said it couldn’t resolve a hostname.  It’s worth checking the sky router can get to the internet - Maintenance>Diagnostics

[greendragons]

Hi @Kevin+D-B - thanks for the message - I was actually about to post back because I (finally!) got it working on Thursday.

I flashed my router with OpenWrt, but I had exactly the same issues - the Sky router was correctly getting IPV4 and IPV6 addresses, the routes were correctly set up, I could access the internet 'through' the Sky router etc,, but the Sky logs just showed Voice Connected followed shortly after by Voice Disconnected.

Packet sniffing the connection, I could even see the Sky router resolving the IP addresses for (and subsequently connecting to) the Sky ACS and 'update' servers - and even resolving all of the domain names relating to the VoIP connection - but I noticed it would never actually attempt a connection to the VoIP server it had resolved the address for.

I'd pretty much given up, but then based on a (quite glaring!) clue in your original post, I connected the Sky router up first, made sure the logs showed it had downloaded the SIP configuration and Voice had successfully connected, then left it on and switched over the connections to the OpenWrt router - and it finally started working!

This seemingly obvious route was made a little more difficult on my side because I am on G.Fast (FTTC), rather than FTTP - hence I have an SR204, rather than an SR203 Sky router. I don't have an ONT and so require a G.Fast modem to connect if I take away the SR204. 

Connecting the SR203/4 through LAN port 4 to the G.Fast modem won't achieve a connection because FTTC still requires VLAN 101 to be set (I believe this is done automatically by the ONT if you're on FTTP).  The SR203/4 assumes that if you're connecting through LAN port 4 (rather than the VDSL/G.Fast port), this VLAN ID doesn't need to be set, so it won't even begin to communicate with Sky because the packets are just being dropped before getting anywhere in Openreach's network.

Once I'd worked this out, I reconfigured the G.Fast modem itself to use VLAN 101, which meant that I could then get the SR204 to connect through it.

The SIP configuration seems to get easily 'lost' by the SR203/4 if it hasn't been able to connect to Voice while trying various configurations - and this was mainly the problem I was then running into (for so long!).  Connecting it back up directly to the G.Fast modem and letting it download its SIP configuration again helps it start working again.

This SIP configuration also seems to be different between the VDSL/G.Fast and WANoE connections, so if you're on G.Fast, it needs to download a new configuration through the modem (connected on LAN port 4) before it'll work.

I've no idea why it can't seem to download this while behind another router - really puzzling - but I guess we may get to the bottom of it one day!

As a side note, I noticed that if I block the default IPv6 ICMP inputs/forward on the OpenWrt firewall, the Voice connection is dropped, so that's just something to note.

Anyway - long story, but thanks again for your help @Kevin+D-B (and for the original inspiration @Pete-da-Meat).

[Kevin+D-B]

This is a followup/recap of my success of getting a Sky SR203 hub to retain it’s VOIP functionality only when used behind my non-Sky openwrt based router/firewall.  Yes it is possible to do though I would be the first to admit it’s not the most robust of setups.  My original setup used a 3rd physical network interface on my router solely to connect to the SR203.  You could view those as ‘WAN, LAN & VOIP’ interfaces.  I simplified the configuration (and wiring) by discarding the VOIP interface and running everything over the LAN interface.

From the SR203 perspective what we’re trying to do is pretend/fool it into think its WAN port (port 4) is connected to Sky’s servers.  For IPv4 it sends out a DHCPv4 request and requires the response to have option 43 as ‘SkyBB-DHCP’ along with usual assigned IP address, subnet, default gateway, DNS servers.  This is easily achieved with openwrt’s default DHCP server ‘dnsmasq’.  In my configuration I have used a tag to identify and respond with that particular option 43 for the SR203 only using the SR203’s mac address as the ‘flag’.  I have other devices that used option 43 for other things hence the need for tagging/conditionally sending it.

/etc/config/dhcp:

config tag 'SkyBB'
        list dhcp_option '43,53:6b:79:42:42:2d:44:48:43:50'

config host                            
        option name 'Sky-Router'
        option dns '1'
        option mac '00:a3:88:a3:52:c3'
        option tag 'SkyBB'

1st extract from /etc/config/network:

config interface 'wan4'       
        option proto 'dhcp'                                                       
        option norelease '1'                                                      
        option reqopts '43'                                                       
        option delegate '0'                                                       
        option hostname '*'                                                       
        option device 'eth0'                                                      
        option clientid '616e797468696e6740736b7964736c7c616e797468696e67'
        option verbose '0'   

Brief explanation: proto ‘dhcp’, configure interface using dhcp (v4).  norelease, do NOT hand back the IP address on reboot, usually you’ll get the same IPv4 address back when you come back. reqopts, request option 43, pretend to be a Sky router.  delegate ‘0’,  6RD prefix delegation which we’re not using.  hostname ‘*’, no idea why!. device ‘eth0’, eth0 is my WAN facing physical network interface. clientid, ah good old option 61, the hex representation of “anything@skydsl|anything”.  Verbose ‘0’, don’t be noisy.

The VOIP service primarily runs over IPv6 though it uses IPv4 for DNS name resolution.  Sky delegate and route a /56 prefix of which means there are up to 256 delegated /64 networks available for us to use.  Here’s how we get IPv6 on our WAN interface.

2nd extract from /etc/config/network:

config interface 'wan6'                                                           
        option proto 'dhcpv6'                          
        option norelease '1'                           
        option reqprefix '56'                          
        option reqaddress 'none'                       
        option device 'eth0'                           
        option userclass 'anything@skydsl|anything'                   
        option verbose '0'                             
        option noclientfqdn '1'

Brief explanation: proto ‘dhcpv6’, configure interface using dhcp (v6). norelease, do NOT hand back the prefix delegation on reboot, prefixes are pretty sticky anyway, this helps a little. reqprefix ’56’, delegate a /56 please, the whole lot. reqaddress ’none’, we don’t want an address for our interface, we’ll choose one ourselves. device ‘eth0’, my WAN facing interface (same as ipv4). userclass, this is the equivalent of clientid, this time in plain ascii.  verbose ‘0’, don’t be noisy. noclientfqdn ‘1’, don’t try to register our hostname with an upstream DNS server.

Openwrt (by default) uses ‘odhcpd’ to handle LAN IPv6 address assignments and will sub-delegate prefixes from ‘upstream’ interfaces if there’s enough address space.  For my LAN interface I assign a /63 prefix, which means there’s a ‘0’ network for normal address assignment and a ‘1’ network available for delegation for something that wants it…like our SR203.

3rd extract from /etc/config/network:

config interface 'lan'                 
        option proto 'static'          
        option ipaddr '192.168.1.1’  
        option netmask '255.255.255.0' 
        option ip6ifaceid ‘::1’
        option device 'eth1'           
        option ip6assign '63'
	list ip6class 'wan6'

Brief explanation: proto ‘static’, we’ll define the IPv4 address thanks. ipaddr, this is our lan IPv4 address. netmask, our usual netmask 255.255.255.0 or /24 in new money. ip6ifaceid ‘::1’, we’ll use the first address of our delegated /63 for our lan interface IP address. ip6assign ’63’, grab a /63 (two ‘subnets’) from our delegated /56. The zero network will be our usual LAN globally routable network.  The one network will be available for sub-delegation to our SR203. ip6class ‘wan6’, only assign/delegate addresses from the wan6 address range, the important bit here is to NOT assign from any ULA address range.  The SR203 will accept a ULA, it just won’t work since ULAs are by design not internet routable.

The SR203 also sends ‘Bi-directional forwarding detection’ echo probes that it expects the other end to loop back.  This occurs however openwrt also send ICMP host redirect responses, which is sensible in that the probes are addressed as going to the SR203 and openwrt is basically saying ‘you don’t need to send those to me, you can get there directly’.  To disable those ICMP redirects add the following to the network config.

4th extract from /etc/config/network:

config device                       
        option name 'eth1'    
        option sendredirects '0'

Nearly there!  Finally there’s need to let IPv6 from Sky through to the SR203 coping with the dynamically allocated prefix. So…

/etc/config/firewall

config rule                   
        option name 'Sky VOIP'          
        option src 'wan'          
        option dest 'lan'       
        option target 'ACCEPT'       
        list proto ‘all’                     
        list src_ip '2a02:c78::/29'             
        option family 'ipv6'           
        list dest_ip '::1:0:0:0:1/-56'

The only thing that might need explaining is the dest_ip.  The -56 applies a ‘host bits only’ mask to the destination IP address for the address comparison. ie. Destination IPv6 & ::ff:ffff:ffff:ffff:ffff = 0:0:0:1:0:0:0:1.  This makes the comparison independent of the prefix delegated by Sky, only our local subnet (and host within that subnet) is relevant.  We also narrow down the permitted source address to Sky’s /29 prefix.

I also tweak a few settings on the Sky Box.

Advanced -> WAN setup: Respond to Ping on Internet WAN IPv4 & IPv6 - set.  Router Mode: WANoE only.

Disable DHCP server on LAN, disable IPv6 on LAN

Enable remote management from my local LAN subnet, 196.168.1.1 to 192.168.1.254. I don’t enable IPv6 since the prefix may well change, and IPv4 access is good enough for the moment.  Remote management may sound odd, but realise the only connection the sky router has is via the WAN interface, so everything is remote!

Disable WIFI access point - don’t need the additional WiFI interference!

[Rich132]

Sky VOIP uses normal SIP /UDP packets if there is something inbetween ONP and the sky router they will be lost.