Print

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

[Chrysalis]

Yeah thats a big selling point of the firebricks, the automatic failover.

Pfsense can automatically switch connectivity but that is in the sense when all the connectivity is always online and it just switches its routing policy, to actually disable one connection (rather than just change the active gateway) and then auto enable another that I think is more specialised as Weaver said.

[Alex Atkin UK]

Yeah the big drawback with pfSense is if your backup connection goes wobbly, all connections go wobbly, its extremely frustrating.

It seems almost pointless having a backup if it actually causes downtime where not having one would have been more stable.  You just end up having to force the gateway as always online and then if it HAS stopped working, should your main connection go down you have no backup.

[bogof]

I suppose the failover you want ideally is quite complex, too.  Ideally I'd probably prefer for it to be AAISP (main line) -> AAISP (L2TP over alternative transit) -> Alternative transit (in case the reason for failure is actually an issue at AAISP, and not a transit issue).  In the last case you might not have all services up (if there are things reliant on the static IP setup over L2TP).  But you'd at least have basic connectivity.

[Chrysalis]

Alex probably will be killing IPv6 on my consoles.

Downloaded two games today (DSL hooked up to pfsense again but ipv4 routed via VM).

Noticed download was slow, and was going over the DSL IPv6, and isnt really a way router side to allow IPv6 but force downloads over IPv4, at least not trivially so for now just added a reject rule on IPv6 traffic for consoles as a quick fix, but will probably kill the DHCP6 allocation for them.  If I cant get Teredo working, then what I might do is keep IPv6 on, keep the reject rule but allow traffic specifically to the multi player gaming ports.

[Weaver]

I’m definitely going to be looking at L2TP over 4G once my health improves. I’ve booked AA to help me with the Firebrick config but have told them it won’t be soon, as I’m going through a real health slump just now, having caught the flu from Janet.

What’s the AA L2TP payload MTU ? Can AA take IP_PDU_size=1500 bytes so that the L2TP_PDU_size (= 1500 + L2TP_header_size ) > 1500 ? Mind you, even if AA can, I doubt the 4G carriers can handle more than 1500 bytes - I’m not thinking straight.

[XGS_Is_On]

Offtopic but very sorry to hear that you are both unwell there. Speedy and full recovery. 

[Weaver]

Much appreciated. Have been feeling like crap, totally exhausted too.

[Chrysalis]

Sad to hear Weaver, I hope you get better quickly.

I dont know how high the MTU can go but if I check my MTU on speedguide analyzer tool with MTU left as unset in pfsense it reports a MTU of 1460 and MSS of 1420.  This is on a host connection that has 1500 MTU.

1432 bytes is the highest unfragmented ping I can do.

[Chrysalis]

L2TP been something I have never used before I am discovering some things.

So pfsense defaults to 1492 MTU for the L2TP interface, which is too high, so I changed that to 1460, this next thing has me bamboozled though.

The host link which in this case is my VM connection gets a fairly consistent 3ms overhead simply for having L2TP enabled, even if idle.  This doesnt happen if I run L2TP inside windows.  I dont know if this is normal and expected for L2TP or it indicates a problem.  I havent looked yet to see if the same happens using it on top of EE.

[Weaver]

Is this something to do with non-neutrality in VM then? L4 and/or L7 protocol-aware middleboxes of some sort?

[Chrysalis]

I think its probably a pfsense/freebsd problem, tomorrow I will see if the same occurs on top of EE.

[Chrysalis]

Its cable modem related, there is a few reports of people finding oddities with dpinger and cable modems, and indeed the issue is not apparent with normal ping from both client machines and even pfsense itself, dpinger is doing something "different".  There is no actual performance issues either, download speeds, streaming etc, is fine over the tunnel.

[Alex Atkin UK]

I've always found gateway monitoring rather "different" and often not reflecting real-world events.  Not least on some occasions it fails completely but pinging the same IP manually works.

[Chrysalis]

Ok I have a little update.

I made some adjustments on the L2TP client side, MTU and MRU set to 1460, AAISP left at auto as oddly they dont have a 1460 option for MTU.

I decreased the ping interval on dpinger, and there is now no measurement of increased latency on tbb, pings from any network device, and pfsense itself are also normal, its now only dpinger been odd, and is threads on reddit about dpinger weirdness with bridge mode modems (higher latency vs normal pings), so this seems fine now and just a dpinger oddity.

The SLAAC issue I think is due to a pfsense bug, I have the same issue on some servers in datacentres, the problem seems to be triggered when the gateway is not pingable, when it isnt pingable (which seems common on ipv6) it will stay in pending state causing the routing to never get activated, choosing another IP to ping doesnt resolve it as I think pfsense expects the gateway to always be pingable, the workaround is to disable the monitoring at the loss of having no monitoring data or auto behaviour that relies on the monitoring.  I am going to post on redmine bug tracker about it.

There is an existing bug report (fixed in 2.7.0) which was really interesting I read last week which had another similar issue where the debugger posted the process of scripts that are run to explain how he fixed it, which was really nice info but I have ended up losing the link.  So will need to check my browser history on that one.

[Chrysalis]

Some more info related to dpinger, I checked the historical readings from it on DSL and it was having fluctuations with an average of 1-2ms jitter measurements when on DSL, this doesnt correlate with any historical remote monitoring or live usage observations.  So I now consider dpinger as a measurement of jitter/latency to be of low accuracy, this is more of a pfsense/opnsense observational post rather than related to L2TP.