- User Since
- Mar 3 2016, 10:58 PM (255 w, 1 d)
Dec 2 2020
I think the intention here is by default build with no liveCD support, and use the flag to explicitly build liveCD images when needed. The justification is if an image is cloud type image, there are certain security assumptions about the live network the image is connected to (because many cloud providers provision an image via information over specific link local addresses). If you boot a physical PC with a cloud ISO, you run the risk of exposing cloud-init to the local network, which would allow trivial takeover.
Oct 26 2020
Don't some 10G/40G/100G gear support some megajumbo frame sizes now as well? Not sure about the 2.5/5G stuff though...
Oct 20 2020
I can see a case where people deliberately do NOT want to use ISP provided DNS servers (to avoid DNS NX hijacking) (and/or lock to a major internet DNS server like google 188.8.131.52 or Quad9 184.108.40.206 or Cloudflare 220.127.116.11 for example)
Sep 4 2020
I've previously mentioned light blocking (domain level, gTLD level), but with the increasing amount of DoH, having a means to kill off DoH and force special DNS processing, including offload to a separate DNS server (managed by a security appliance for example, say PiHole or similar) would be valuable.
Sep 1 2020
The bad behavior of udev/systemd was a topic of an interesting twitter thread...
Jun 24 2020
There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.
Nov 14 2019
The suggested debian package qrencode seems handy for terminal use. Actually, using QRcodes to transfer information would be interesting for other uses as well, such as exporting other kinds of keys such as OpenVPN. As a remote support measure, if a config is causing issues that prevent remote login, having a local login being able to emit the current config as a QRcode might be interesting...
Nov 4 2019
Wait, Argo tunnel uses Cloudflare's WARP VPN system, which under the hood is basically wireguard...
Oct 16 2019
One might need to differentiate between transparent bump-in-the-wire type squid deployments, and running it as a known proxy (delivered via DHCP and an onboard PAC file). Plus any kind of speedbump captive portal. I know one place specifically uses it to force clients to expose connecting hostname due to the use of the CONNECT command for TLS connections, for passive logging on the wire. Which will get interesting with the emergence of DoH and DoT in mainstream browsers, and enterprise efforts to kill that off.
Sep 10 2019
Actually somebody made a nifty websocket tunnel named wstunnel (similar to stunnel conceptually, but websockets is more natural for tunneling generic binary protocols thanks to webRTC...) that seems to work alright for Wireguard.
As long as the local nginx is not listening on the external interface on udp/443, functionally there should be no limitation to running wireguard on 443 there. A convoluted script to check that the current config has no existing 443 mapping is one solution, but that seems a bit fragile, and wouldn't really tell you where in the config the blocking 443 instance is.
Jun 27 2019
Just to confirm, HTTP proxy in this context being nginx being a reverse proxy frontend for GUI and API HTTP servers, likely living on localhost bindings, right?
Apr 25 2019
Nov 5 2018
I think Intel now even recommends using Brocade 1gigabit modules for SFP+ modules when needing to down grade a 10G port to gigabit now, since they no longer manufacture 1G modules, so this is bound to bite people. Perhaps default to adding the allow_unsupported_sfp=1 for the various intel drivers perhaps?
Aug 8 2018
Apparently Linus loves Wireguard as well now.
Jun 29 2018
Jun 27 2018
Jun 13 2018
Added a child feature request for iPXE.
Jun 12 2018
If you are going to do this, then there's the related issue of whether or not to put in PXE/gPXE/iPXE related stuff to support netbooting things.
May 28 2018
Algo VPN, the premier personal IPSEC VPN distro is now preparing to bake in wireguard. Admittedly their distro is intended for disposable VPN VM's but they seem to think wireguard is is close to production ready. It seems they are moving to wireguard for android client connections.
May 21 2018
I wasn't sure if we were maintaining our own package or not. If we're pulling updates from Debian security updates directly, then I see no problem. The researcher is still collecting and analyzing the fuzzer run so no published reports as of yet.
May 17 2018
fair warning, there's a security research currently fuzzing tcpdump who has been finding some stack overflow bugs so expect a package update or two in the not so far future...
Feb 9 2018
straight firewalling won't help if the logon attempts still come from a presumably trusted LAN. I like the idea of at least a temporary lockout to prevent mass attempts when someone is running a big password list, though the utility of this naturally drops if VyOS can be fingerprinted before the attempt and the instance runs with a default password, but that's a sysadmin problem.
Nov 29 2017
I suppose I should also mention that I am also using a proxy PAC file hosted on the internal lighttpd instance as well over HTTP (again, can't use HTTPS due to certificate trust issues for unknown client PC's) which is important due to DHCP server URL designation of a PAC/WPAD file currently.
Nov 27 2017
I do use squid in production, but without the hardcoded blacklists, rather my own local list only, and as an explicit proxy with a rejection message locally hosted as HTTP on the inbuilt lighttpd instance (can't serve HTTPS rejections because of certificate trust issues).