Soldato
.608 it seems. Just rebooted and we'll see how it goes.
So far getting 375mbs and 24 up
firmware 608.
Where did that come from, I thought the new firmware gradually rolling out was .603
Virgin Media Discussion Thread
- Thread starter macca40
- Start date
firmware 608.
Where did that come from, I thought the new firmware gradually rolling out was .603
Associate
I think @brendy might be on the trial, perhaps unknowingly.
Last edited:
Yea I'm not sure neither, Area 26 here. Downloaded etc on 9th, took its sweet time though to install, how big are these firmware images?
TBB certainly doesn't like it!
Associate
Yeah, you seem to be getting trial firmware pushed to your Hub. I’m currently in the process of leaving Virgin but was on the trial. Can still access the trial board at the moment so can see what issues there are. TBB monitor being one of them.Yea I'm not sure neither, Area 26 here. Downloaded etc on 9th, took its sweet time though to install, how big are these firmware images?
TBB certainly doesn't like it!
Yea I'm not sure neither, Area 26 here. Downloaded etc on 9th, took its sweet time though to install, how big are these firmware images?
TBB certainly doesn't like it!
Your IP has changed. That or ICMP/echo/ping has defaulted to drop.
Checked the IP and it's the same, can't find any options on the router for the rest. I have noticed that the connected devices screen is much more accurate now as the rates are less rounded.
Soldato
@brendy, Im on .603 firmware but had software pushed to my hub3 at a similar time to you on the 9th although it said " software install failed" due to some download corruption, I'm guessing it may have also been this trial firmware.
I may try a reboot soon see if it gets pushed to my hub again.
I may try a reboot soon see if it gets pushed to my hub again.
Yea it's odd, 45 min download so either it's several parts, massive or riddled with retries.
LOLVirginMedia. Everyone knows their routing is crap verging on insane, but this takes the cake. My 'internet experience' has been getting worse and worse this last year, despite a large head-end uplift and upgrade, new segments added, new CMTS etc. Every peak time traffic would start to slow down, I'd lose packets, websites loaded slowly (obviously using self-hosted DNS not VM's) and it was just awful. Then, having used Unix (BSD, Linux etc) for 15-20 years and VPNs for more than half that, I decided to do something about it. As I briefly mentioned in an earlier post a while ago, my setup is as follows:
I had been running VPNs on various local devices individually but got sick of load balancing, swapping connections/servers/locations between them (especially for family member devices). So in between attending the OcUK Motors meet, I spent the weekend playing with FreeBSD 11.1 p10 and getting my hands dirty.
Now all devices route through my home made router as usual, but the VPNs (plural) have been moved off the local devices and on to that box. I now have interfaces as follows:
With manually set outbound NAT - plus hairpin NAT and proxy helper for self-hosted domain resolution due to the VPNs - each gateway (vpn.ac, NordVPN, AirVPN, PIA) has its own route to the 'real' WAN to maintain a connection 24/7. Extra locations and servers can be added trivially if or when the need arises. Originally I was running a single VPN and didn't know much about how to add (or even load balance between) a second or more. As I said, though, I've been busy playing with FreeBSD (11.1p10, Mate Desktop) for a few days though and digging around in ports and the networking stuff. Now I have it set so that all VPNs idle 24/7, all have NAT routes out via the main WAN gateway, and LAN access (or even individual client access) is controlled by pf rules like this:
LAN
* Pass, Source: LAN NET, Destination: ANY, Gateway: 'desired VPN or WAN gateway'
* Block, Source: ANY, Destination: ANY, Gateway: VM WAN
The second rule makes it impossible for the VPN to leak, as if the local clients can't resolve via the desired VPN gateway (chosen in rule 1), by default they would fall back to the 'normal' VM Gateway. With rule 2 in place, they now simply have all their packets dropped until I fix it again. For those who don't know, firewall rules (certainly in pf, ipfw, iptables etc) are read and used in order from top to bottom.
DNS is resolved separately per interface (VPN DNS per VPN interface, SecureDNS with DNSSEC over TLS for WAN). I noticed the TiVO v6 box didn't like this (the Netflix and YouTube apps would no longer work), so I set the DHCP daemon to provide the V6 with VM DNS servers as well as a static IP, while keeping the rest of the LAN devices 'clean' (encrypted with proper DNS). The TiVO still fetches its traffic over the VPN interfaces however, as does everything else LAN-side. Policy based routing FTW. The end result?
Using the bare naked VM350 connection (speedtest.net app to Vispa server):
Two clicks (Edit allow LAN rule, change output gateway from VM to VPN > Save):
Using my preferred VPN gateway (speedtest.net app, to the same Vispa server a moment apart from the first test):
Yes, you read that correctly. Yes, it was 'peak time' when the tests were undertaken. No, I haven't made a mistake with the labels (check the source network in the images for proof).
With the VPN enabled (AES-128-GCM) my pings to the same server from the same LAN machine (desktop PC, specs in sig) have gone down by 66%.
Jitter is improved by 50%. Speed is barely impacted outside of margin of error. No leaks, DNS working properly, policy based routing pushing everything to the right place both LAN and WAN side. Job's a good un... Until I decide to tweak something else.
Edited to add: For those who don't know, VPNs are 'supposed' to slow down your connection compared to the 'bare' ISP link. They're also 'supposed' to increase latency / make pings worse. They're also 'supposed' to make your routing more complicated. In this case, VM's is so poor my VPN actually fixed it. I'll spare you all the traceroute printouts, but suffice to say a trace from my desktop to a server now has five less hops, missing all the VM-node-28237 steps with abysmal response times and convoluted routing. I now go direct from desktop PC > VPN server > destination in less than 6 hops. Win!
I had been running VPNs on various local devices individually but got sick of load balancing, swapping connections/servers/locations between them (especially for family member devices). So in between attending the OcUK Motors meet, I spent the weekend playing with FreeBSD 11.1 p10 and getting my hands dirty.
Now all devices route through my home made router as usual, but the VPNs (plural) have been moved off the local devices and on to that box. I now have interfaces as follows:
With manually set outbound NAT - plus hairpin NAT and proxy helper for self-hosted domain resolution due to the VPNs - each gateway (vpn.ac, NordVPN, AirVPN, PIA) has its own route to the 'real' WAN to maintain a connection 24/7. Extra locations and servers can be added trivially if or when the need arises. Originally I was running a single VPN and didn't know much about how to add (or even load balance between) a second or more. As I said, though, I've been busy playing with FreeBSD (11.1p10, Mate Desktop) for a few days though and digging around in ports and the networking stuff. Now I have it set so that all VPNs idle 24/7, all have NAT routes out via the main WAN gateway, and LAN access (or even individual client access) is controlled by pf rules like this:
LAN
* Pass, Source: LAN NET, Destination: ANY, Gateway: 'desired VPN or WAN gateway'
* Block, Source: ANY, Destination: ANY, Gateway: VM WAN
The second rule makes it impossible for the VPN to leak, as if the local clients can't resolve via the desired VPN gateway (chosen in rule 1), by default they would fall back to the 'normal' VM Gateway. With rule 2 in place, they now simply have all their packets dropped until I fix it again. For those who don't know, firewall rules (certainly in pf, ipfw, iptables etc) are read and used in order from top to bottom.
DNS is resolved separately per interface (VPN DNS per VPN interface, SecureDNS with DNSSEC over TLS for WAN). I noticed the TiVO v6 box didn't like this (the Netflix and YouTube apps would no longer work), so I set the DHCP daemon to provide the V6 with VM DNS servers as well as a static IP, while keeping the rest of the LAN devices 'clean' (encrypted with proper DNS). The TiVO still fetches its traffic over the VPN interfaces however, as does everything else LAN-side. Policy based routing FTW. The end result?
Using the bare naked VM350 connection (speedtest.net app to Vispa server):
Two clicks (Edit allow LAN rule, change output gateway from VM to VPN > Save):
Using my preferred VPN gateway (speedtest.net app, to the same Vispa server a moment apart from the first test):
Yes, you read that correctly. Yes, it was 'peak time' when the tests were undertaken. No, I haven't made a mistake with the labels (check the source network in the images for proof).
With the VPN enabled (AES-128-GCM) my pings to the same server from the same LAN machine (desktop PC, specs in sig) have gone down by 66%.
Jitter is improved by 50%. Speed is barely impacted outside of margin of error. No leaks, DNS working properly, policy based routing pushing everything to the right place both LAN and WAN side. Job's a good un... Until I decide to tweak something else. Edited to add: For those who don't know, VPNs are 'supposed' to slow down your connection compared to the 'bare' ISP link. They're also 'supposed' to increase latency / make pings worse. They're also 'supposed' to make your routing more complicated. In this case, VM's is so poor my VPN actually fixed it. I'll spare you all the traceroute printouts, but suffice to say a trace from my desktop to a server now has five less hops, missing all the VM-node-28237 steps with abysmal response times and convoluted routing. I now go direct from desktop PC > VPN server > destination in less than 6 hops. Win!
Last edited:
Sorry about that, I don't know why. I used the forum's built-in indent code to format it, and it works on desktop (Chromium). I've changed the two layouts to png images snipped from my original post. They're dark background, so will look funny if you have the 'wrong' forum theme
but they should at least be legible now.
Last edited:
You'd need to do a tracert over your VM connection to your VPN endpoint and then from the VPN to the destination server to determine how many hops there are (excluding any MPLS or GRE inside other people's networks), so it's unlikely that your hop count has actually gone down. What you're seeing is a routing path that isn't bouncing around VMs network as each VPN tunnel is just one session rather than the hundreds you'd usually create if you weren't tunneling everything.
True. Either way the end result is a faster, smoother connection with better response times and much better throughput (especially for certain services). Smooth as butter, and much more private to boot. Win/win.
Yeah I don't really know what Virgin Media play at sometimes. I understand that cable is a shared medium and mistakes made in the past (and for some reason still being made) regarding the ridiculous number of subscribers they try and shove into each node can mean that peak-time congestion isn't really fixable without a digger or kicking people off the service, but it wouldn't cost them any more money to not route things halfway across the country and back on their own network before deciding to drop out onto the Internet
Even if they did, it would do you no good as you need to progress through frontline support before they can deal with you unfortunately. Faults were centralised many years ago, 2nd line was based in Liverpool, but i’ve been out if the loop for a long time now, so they may have been moved/outsourced/made redundant by now.
Would you possibly be able to give me a brief guide to what I can do to get a similar result to what you've had? Is it possible to use my existing router (ASUS N66U) and configure that to use a VPN in the same way? My SH3 is in modem mode.LOLVirginMedia. Everyone knows their routing is crap verging on insane, but this takes the cake. My 'internet experience' has been getting worse and worse this last year, despite a large head-end uplift and upgrade, new segments added, new CMTS etc. Every peak time traffic would start to slow down, I'd lose packets, websites loaded slowly (obviously using self-hosted DNS not VM's) and it was just awful. Then, having used Unix (BSD, Linux etc) for 15-20 years and VPNs for more than half that, I decided to do something about it. As I briefly mentioned in an earlier post a while ago, my setup is as follows:
I had been running VPNs on various local devices individually but got sick of load balancing, swapping connections/servers/locations between them (especially for family member devices). So in between attending the OcUK Motors meet, I spent the weekend playing with FreeBSD 11.1 p10 and getting my hands dirty.
With manually set outbound NAT - plus hairpin NAT and proxy helper for self-hosted domain resolution due to the VPNs - each gateway (vpn.ac, NordVPN, AirVPN, PIA) has its own route to the 'real' WAN to maintain a connection 24/7. Extra locations and servers can be added trivially if or when the need arises. Originally I was running a single VPN and didn't know much about how to add (or even load balance between) a second or more. As I said, though, I've been busy playing with FreeBSD (11.1p10, Mate Desktop) for a few days though and digging around in ports and the networking stuff. Now I have it set so that all VPNs idle 24/7, all have NAT routes out via the main WAN gateway, and LAN access (or even individual client access) is controlled by pf rules like this:
LAN
* Pass, Source: LAN NET, Destination: ANY, Gateway: 'desired VPN or WAN gateway'
* Block, Source: ANY, Destination: ANY, Gateway: VM WAN
The second rule makes it impossible for the VPN to leak, as if the local clients can't resolve via the desired VPN gateway (chosen in rule 1), by default they would fall back to the 'normal' VM Gateway. With rule 2 in place, they now simply have all their packets dropped until I fix it again. For those who don't know, firewall rules (certainly in pf, ipfw, iptables etc) are read and used in order from top to bottom.
DNS is resolved separately per interface (VPN DNS per VPN interface, SecureDNS with DNSSEC over TLS for WAN). I noticed the TiVO v6 box didn't like this (the Netflix and YouTube apps would no longer work), so I set the DHCP daemon to provide the V6 with VM DNS servers as well as a static IP, while keeping the rest of the LAN devices 'clean' (encrypted with proper DNS). The TiVO still fetches its traffic over the VPN interfaces however, as does everything else LAN-side. Policy based routing FTW. The end result?
Using the bare naked VM350 connection (speedtest.net app to Vispa server):
Two clicks (Edit allow LAN rule, change output gateway from VM to VPN > Save):
Using my preferred VPN gateway (speedtest.net app, to the same Vispa server a moment apart from the first test):
Yes, you read that correctly. Yes, it was 'peak time' when the tests were undertaken. No, I haven't made a mistake with the labels (check the source network in the images for proof).
With the VPN enabled (AES-128-GCM) my pings to the same server from the same LAN machine (desktop PC, specs in sig) have gone down by 66%.
Edited to add: For those who don't know, VPNs are 'supposed' to slow down your connection compared to the 'bare' ISP link. They're also 'supposed' to increase latency / make pings worse. They're also 'supposed' to make your routing more complicated. In this case, VM's is so poor my VPN actually fixed it. I'll spare you all the traceroute printouts, but suffice to say a trace from my desktop to a server now has five less hops, missing all the VM-node-28237 steps with abysmal response times and convoluted routing. I now go direct from desktop PC > VPN server > destination in less than 6 hops. Win!
When it comes to VPNs, I really don't have a clue what I'm doing. However I would like to start getting into using one.
I feel like I've been noticing VMs cappy routing quite a bit recently.
I'm happy to help you out if I can, and I've actually been debating starting a mini blog type site with all my BSD/Linux/networking tech bits - for my own future reference if nothing else. I already have a domain and plenty of options. As for your N66U though, you're going to struggle. They don't have x86 CPUs inside and perform all their routing (packet forwarding etc) in hardware. If you ask them to do any computational tasks they'll suffer. In plain English, they're rubbish for VPN and you'll struggle to get 30 - 50Mbps overall. It doesn't help that openvpn is a single threaded protocol either. Someone needs to set up a proper by nerds for nerds VPN service that's not reliant on openvpn. There are much faster, secure alternatives. I digress.
Thank you very much. That blog is definitely something I would read.
As for the N66U, I expected that would be the case. I am considering building my own router and installing PF sense on it. I've got a file server that I'm planning on upgrading soon, as I've got a dual socket motherboard around with dual 8 core Xeons, and running a VM with PfSense on it.
But I need a rack cabinet and a rackmount case with hotswap bays in first, which will be a big job setting up.
Give me a shout or drop me a mail in trust whenever you want to pick my brains.