Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Chrysalis]

Absolutely not all of it, just the stuff to and from the home office, and even then only a subset as I choose to.

Could certainly push all traffic in the entire network through it but there's no real point just yet. Doing that would require me to either suck up the electricity bill of a server or buy a new one, alongside paying AWS bandwidth and CPU charges.

It actually functions as an offload and overflow for the most part - I compensate for the lack of upload capacity on VMB by overflowing traffic onto it once I reach a certain level. My office is permitted 15 Mb/s of the VMB line before traffic starts to waterfall onto LTE.

Using a VPN for everything is a bit silly.

What I have decided to do (or try to do) is just route stuff I want to "rate limit" inbound via a VPN, and then shape outbound on the VPN to me, so for now steam, battlenet, and other large download tools.  But stuff I dont care if not rate limited and ok to run through a generic fq_codel pipe I will feed direct.  AWS seems pretty expensive even when you pay up front reservation, so will try it out on a cheap VPS I have based in the UK and see how it goes.

You can shape inbound directly but I am finding its much harder to do it effectively than outbound traffic, for it to work 100% on my network I had to set my inbound pipe size all the way down to 48mbit/sec on a connection that can handle 70.5mbit throughput.  This is why your idea got my interest.  The VPS itself can burst to gigabit throughput so it has lots of spare capacity over the pipe limit I will set and also it will be on the easier outbound than inbound.  I will just mark the packets inbound so they tagged all ready for the outbound part.

[Chrysalis]

Did some quick testing.

Initial results are a very nice improvement.

So I can do basic fq_codel no issue on direct shaping, but actual classification and weighting of packets needs a high margin on the pipe size vs the connection throughput limit.
I then set a basic limiter on the tun0 device on my VPN to rate limit the speed about 5mbit/sec below my line rate and set my pipe to 2.5mbit/sec below my line rate on my pfsense unit, so 2.5mbit buffer on WAN, plus further 2.5mbit buffer to VPN limit, routed the steam traffic to lower weighted codel flow and the following works pretty smooth.

Single threaded ftp download max pipe speed.
Start steam download 24 threads across 6 ips, at same time hits about 400kB/sec as reported by steam client.
Single threaded ftp download drops by about 3 mbit/sec out of 67.
No jitter/loss on ssh packets.
If I stop the ftp download, steam then auto grabs the freed up bandwidth and fills up to the rate set on the VPN shaper.

This didnt require any packet marking on VPN server, the config that side was really simple, I just rate limited everything outbound from it to my side of VPN tunnel, and only sent steam traffic through it.

I did after try some iptables marking stuff but it wasnt working, linode dont allow loading kernel modules on their linux vps images, and I dont know if its statically compiled into the kernel, all I know is it wasnt working.  To do weighted classification VPN side would need marking working.  But classifying pfsense side and just routing traffic that needs "taming" through the VPN is effective.

--edit--

After some sleep realised I forgot the restore mark mangle rule and classification now also works should I choose to use it.