From TangleBall

Jump to: navigation, search

Details for the Internet connection @ TB.

Up to now, Ed has kindly provided internet to the space, but personal circumstances may make such a continued kindness difficult.

The present solution has been less-than-perfect, relying on an overly-complicated arrangement where a connection is shared from the above residence & 'piped' down to the space to use, involving double-NATting & other tricks.

It has proven -problematic- challenging at times.

A new arrangement could look something like:

[INTERNET] - [OPTIONAL ROUTER] - [pfSense GATEWAY] - NIC(1): [RESIDENCE LAN & WiFi] (via DD-WRT AP?) & NIC(2): [TB LAN & WiFi] (via DD-WRT AP)

The questions now become:

  • What kind of connection needs to be put in place - VDSL or UFB (fibre)? Both are priced very-much the same (cheaper than ADSL in most cases).
  • Kind of service - unshaped, uncapped, fixed price, or something else?
  • Preference of provider/ISP

In this context, only "naked broadband" is considered - i.e. sans POTS phone line, since there are (arguably) better VoIP services available.



For the most part, we already have the requisite infrastructure in-place: UTP cable running between space & domicile, WRT54G AP's flashed with DD-WRT (good time for an upgrade). We could get away without it, but a pfSense box would give us a lot of functionality we'd find very useful later on, such as OpenVPN, Dynamic-DNS, QoS, accounting, caching and/or reverse-proxy - just to name a few.

A stock x86-based PC - with at least 3 NIC's (WAN, LAN-house, LAN-TB) - can be used for this purpose, but I've had some very good results with ALIX-based hardware (~$280), as the difference power-consumption & maintainance of fanless device could make up for the difference. If UFB is chosen, then an ISP modem is strictly-speaking not needed (or used in bridged mode), and will in fact get deprecated, since pfSense is more than capable of handling PPPoE connections.

There can be a *very* long lead-time for installation - 3-8 months in some cases - and there may be additional costs associated with provisioning.

For the installation of any new infrastructure on-site, such as an ONT, we'll require an OK from the building owner.

A rack-mounted managed switch would be a boon to keeping the infrastructure properly organised in the cabinet. The switch used can be better used elsewhere.


IINM, we're presently using something like an ADSL connection, stretched pretty thin over all the users.

Recent developments in the broadband-market have pushed prices down significantly, meriting a reconsideration of what's available & used. From my own price-hunting of such services, costs for VDSL & UFB are very similar, and often cheaper than ADSL.

Seeds available are typically:

  • 30 Mbps download, 10 Mbps upload
  • 100 Mbps download, 50 Mbps upload

The (official) Chorus capability map shows us well withing the coverage area :D

Unfortunately VDSL is not available at the address :(


We're spoilt for options. Member will have to make a decision here. (/me will *NOT* deal with vodafone) A few ISP's offer connections without fixed long-term contracts. Most would allow for the upgrade of service, but would penalise for downgrades (often requiring termination of contract & re-connection)

Candidates include:

Other pricing plans

Not all connections are created equal. Some shape traffic so as to block legitimate P2P traffic, others offer "unlimited"/"unmetered" services but balk when used as advertised. Line attenuation is also a factor - ie. how many connections share a cabinet.

Proposed implementation strategy

  1. Configure on-site infrastructure to address current connectivity, and meet potential new requirements, using repurposed x86 multi-nic PC running pfSense & DD-WRT WRT54G devices
  2. Members discuss & make a decision on provider & package
  3. Arrange with building-owner for permission to go ahead
  4. Give the go-ahead to ISP & arrange schedule
  5. Install UFB on 2nd WAN NIC on gateway & run concurrently with existing line to ensure it's stable
  6. Cancel old line
  7. Consider replacing interim x86 gateway with low-powers, low-latency ALIX-style embedded gateway.
Personal tools