Forwarding tcp/udp ports from new sky hub to existing destinations on my lan

[IHateSteps]

In the interest of being prepared (I was a cub scout once) I'm researching the right procedures to follow once my sky broadband is installed.

I currently run with VM broadband, a pfSense firewall which forwards ports 80/443 to a server (advertised using Cloudflare DNS) which itself runs traefik and authentik to decide  which connections to forward where, and for whom.  It sounds complicated, especially when I start talking about about docker and containers, but it really is not.

For the time being I want to retain a standard (if DV can be called standard) telephone line.  Moving fully to VOIP will come later.

On receipt of my new connection I will need to configure port forwarding for minimum of ports 80 and 443 to discrete ports on my lan-connected HP Server.  Can somebody point me to the documentation which covers this activity?

Thanks!

[cookiemonsteruk]

@IHateSteps 

Thats one for @mae-3 . 

[mae-3]

@IHateSteps 

The pfSense firewall is compatible with Sky and one only needs to connect to the ONT (FTTP full-fibre ultrafast) or purchase a modem when connected to FTTC (VDSL2 modem superfast) and connect pfSense to either of these devices using DHCP Option 61 (DHCP client identifier 61) and DHCPv6 Prefix Delegation (PD) for IPv6 traffic for WAN.

The user credentials for DHCP Option 61 are 'anything@skydsl|anything' without the quotes.

The forwarding of ports for pfSense remains the same and the connection details for Cloudflare are as VM.

[IHateSteps]

@mae-3 

Thanks for your considered response which I had already been aware given that I'd been aware of this potential requirement when I first looked at the various FTTH/P services a few months back.

The difficulty is that for every different providing a fibre-based landline service (and this number is dropping quite rapidly it seems) there is a different implementation.  I have noted that some use the router or hub to connect to client telephones, while others allow for a direct connection to the ONT.  I am sure there are technical reasons for the variation  - but I see this is 'Too much information (TMI)'.

I need a landline for the moment (not just for my community alarm pendant) so full VOIP is not an immedate option, although I am planning this some months from now.  I have so far failed to find any option for changing the point which the DV service terminates, thus I have to keep the hub connected, with its Sky configured internet address.

I cannot help but think that I could implement some clever routing/forwarding configuration allowing me to retain my pfsense as a routed network behind the sky hub, while keeping the hub as a layer 3 device, thus maintaining the DV setup and leaving in place the tools by which Sky monitor our network status, and ensure service levels.  Of course, double-natting is also an option, though my port-forwarding will require some additional head-scratching.

It is for questions regarding port forwarding, firewall rules and static routes, etc, for which I have been searching for a manual for the hub device.  While there are a good number of posts available on port forwarding and other techniques, these often date from earlier routers and technologies.

[mae-3]

@IHateSteps 

Port forwarding on the Sky Hub https://helpforum.sky.com/t5/Broadband-Talk/How-to-set-up-port-forwarding/ba-p/2662260 

[TimmyBGood]

---

@IHateSteps wrote:

 I have noted that some use the router or hub to connect to client telephones, while others allow for a direct connection to the ONT.   

---

Probably not the latter in practice.  While earlier models of Openreach ONT had one or two 'phone' ports, the current widely deployed units just have one ethernet socket.  Direct connection of telephony to the optical network was clearly once considered as a potential topology (even supported by a BBU), but was subsequently rejected.

[mae-3]

@IHateSteps 

The phone, Digital Voice (DV) is a VoIP proprietary BT solution. When you take on a new provider, eg: Sky then as you know they have their own VoIP solution.

So, if and when you move the DV will stop working as it only works with BT's Hubs.

1. Keep the Sky Hub in the circuit and you'll keep the free offering of VoIP line with excessive call charges. And use pfSense in double NAT.

2. Put the firewall in the circuit connected directly to ONT and route through pfSense and use a non-proprietary VoIP solution with ATA connected to pfSense, eg: cheaper calls with several VoIP offerings.

3. Play around and have the pfSense and Sky Hub behind it but the solution is proprietary and not everything is known about Sky's VoIP solution. One has to DHCP relay for IPv6 through pfSense for Sky Hub.

[Eeeps · Accepted solution]

I suggest double NAT is the way to go, at least initially.

The key to that is to have the pfSense in the DMZ of the Sky Hub.

This means that there are no port forward configuration steps on the Sky Hub - the DMZ will forward all ports.

Also, DMZ provides a simple stateless NAT, only the destination address is changed on the incoming IP headers and source address in the outgoing IP headers.

For me this made my move from VM to Sky really simple from an internal network point of view.
As you say, Sky still see their HUB which means they will investigate any issues you might raise with them.

[IHateSteps]

I would like to thank @Eeeps and @mae-3 and everyone else for their suggestions.   I can't help but think we need to have some kind of place to publish solutions to problems, so that those of us coming along later can see what they did.

I was getting rather depressed by the lack of port forwarding with port translation that I took for granted with pfSense - which led me to initially ignore the opportunities offered by the DMZ.

Bizarrely, I'd just seen a posting on another site describing the DMZ / Double NAT option - when I returned here.

I'll loop back around when I've got it working, and leave a desription of what I had to do.

[IHateSteps]

As promised, here is my final solution based on responses from @Eeeps and @mae-3 .

To save my sanity, and to reduce the load on my wheelchair batteries from constantly chugging between different cupboards and bits of electronics I made use of the otherwise forgotten additional ethernet port to be found on the little usb3 hub attached to my primary pc.

I connected and set both interfaces on my pc to DHCP, connecting the temporary interface to the back of the router in a spare socket.  I then configured the sky router to 192.168.1.1 (note the 1 in the third octet).  After enough time to read War & Peace, the sky router rebooted.

I connected the pfsense WAN to my lan switch, found the mac, and reserved that address as 192.168.1.254, made it the DMZ host.  Two more reboots later, I have my sky router'l LAN on 192.168.1.0/24.

I then switch cables so that the pfsense WAN is connected to the main LAN port on the sky router, and connect the LAN port of the pfsense into my main switched LAN network.  I now have a pc connected to both networks temporarily (somewhat insecure, but only temporary).  Here's a picture:

With the temporary connection from my PC to the 'Sky LAN' disconnected I can traceroute, ping and connect in all sorts of ways to the internet.

I find also that the connections inbound, which rely on port forwarding and an reverse proxy server all work without any hesitation.  The code which detects my wan ip still correctly identified the WAN IP of the sky router.

All in all, a much easier job than expected.

Some thoughts that I hope Sky adopt in their forthcoming new router:

1.  Resort back to the kind of configuration that there used to be in my last experience with Sky broadband which are simple menu settings for like requirements.  Lan stuff on a LAN menu, WAN on a WAN, and DNS further on, etc.

2.  Making the router simple just to make support easier will only put off the slightly more knowledgeable users.

3.  Port forwarding is a common requirement.  Don't hide the function behind two separate menus, and place the automatic (UPNP) options behind an unknown password prompt.

4. As much as the VirginO2 routers were hated by users, they actually incorporated the majority of required functions in their firmware, modem mode was effective, and the telephone line worked in both router AND modem mode.  VMO2 actually listened to customers when the background muttering reached louder levels. 

If anyone wants to know more about how I got this working, PM me and I'll draw some more diagrams.