VyOS 1.4.4 LTS: TLS Syslog, GWLB Support, and RPKI Aware BGP

VyOS 1.4.4 LTS lands as a focused, operational maintenance release that tightens security, improves cloud fit (notably AWS Gateway Load Balancer architectures), and gives operators finer-grained BGP policy tools while addressing a long list of stability issues.

Background / Overview​

VyOS has been positioning itself as an open-source, enterprise-ready network operating system for bare-metal, virtualized, and cloud deployments. The company’s December 19 announcement makes VyOS 1.4.4 LTS the latest maintenance update in the 1.4 “Sagitta” LTS line, and lists feature and hardening work intended for hybrid‑cloud and edge use cases. This release emphasizes three operational pillars: secure observability (encrypted syslog transport), cloud inspection/steering compatibility (AWS Gateway Load Balancer support), and routing-policy control (BGP policy expansion with RPKI-aware matching). The changes are practical rather than flashy: most operators will notice incremental policy controls, a handful of cloud-focused deployment primitives, and a broad set of bug fixes that collectively aim to reduce friction in production networks. The release also ships with explicit upgrade notes that may require preparatory work for some environments — notably changes to multicast address handling and a deprecation notice for SSH DSA keys.

---

What’s new in VyOS 1.4.4 LTS​

Key highlights (quick list)​

• TLS for syslog: TLS-encrypted remote syslog over TCP is now configurable, enabling encrypted log transport to compliant collectors and SIEMs.
• AWS Gateway Load Balancer (GWLB) tunnel handler support (AWS-only): VyOS now supports GWLB traffic‑steering inspection patterns by integrating with GWLB tunnel handling approaches used on Linux targets.
• BGP policy enhancements: Route‑map matching can now inspect BGP prefix origin‑validation extended communities (RFC 8097), which lets operators make RPKI‑aware decisions inside route maps.
• More than 50 bug fixes: A broad set of fixes across the platform intended to improve stability in production environments.
• Operational compatibility notes: Manual assignment of multicast addresses to interfaces is disallowed (to prevent invalid/malformed configurations), and SSH DSA keys are deprecated with a migration timeline tied to OpenSSH removals.

Each of those bullets matters to different audiences: platform operators and security teams will welcome syslog TLS; cloud networking and security teams will pay attention to GWLB support; and backbone and transit engineers will be most interested in the new BGP policy matching options.

---

Background: Why these changes matter​

Secure observability — syslog over TLS​

Many enterprises are standardizing on encrypted telemetry pipelines to protect diagnostic and security logs in transit. The addition of TLS-encrypted remote syslog to VyOS closes a persistent gap between appliance-era network logging (UDP 514) and modern observability best practices. The VyOS documentation explains configuration options for TLS modes (anon, fingerprint, certvalid, name) and requires certificates to be uploaded to the local PKI store for cert‑based modes. Administrators can now send logs over TCP+TLS to SIEMs, centralized log proxies, or cloud log collectors without implementing ad‑hoc TLS tunnels. Practical impact:

• Encrypted transport reduces the risk of log tampering and metadata disclosure on shared networks.
• Mutual‑auth and server validation modes allow integration with enterprise PKI and strict collector validation.
• Operators must manage certificates (CA and client certs) and adapt monitoring health checks for the TCP/TLS syslog endpoint.

Cloud inspection patterns — AWS GWLB​

AWS Gateway Load Balancer (GWLB) is increasingly used to steer traffic through inspection/processing appliances (firewalls, IPS/IDS, DPI, etc.. GWLB delivers traffic to appliance targets using GENEVE encapsulation; appliance targets run a tunnel‑handler that converts GENEVE flows into local tunnel interfaces for processing. AWS documents this integration pattern and provides a public sample tunnel handler (gwlbtun) used on Linux targets. VyOS’s announcement of GWLB tunnel handler support signals the project has added the plumbing to participate in GWLB-based traffic‑steering in AWS (the release note calls this out as AWS only). Operational note:

• This capability usually requires either an appliance-side tunnel handler (gwlbtun) or kernel-level Geneve support plus logic to parse GWLB TLVs. Deploying VyOS as a GWLB target will also require ENI and health-check alignment in AWS and careful kernel/network sysctl tuning for high-throughput scenarios.

Routing-policy control and RPKI-aware decisioning​

Routing security at scale increasingly relies on RPKI-based origin validation. RFC 8097 defines a standardized BGP Origin Validation State Extended Community so that routers inside an AS can carry origin validation marks (valid / not-found / invalid) in BGP updates and use them in internal policy decisions. VyOS 1.4.4 adds the ability to match these extended communities in route maps, letting operators implement RPKI-aware routing policies: for example, prefer validated routes over not‑found or deprioritize invalid routes inside policy logic. This is important for transit ISPs and large networks that want automated, policy-driven mitigation against accidental or malicious route origin announcements. Practical impact:

• Operators can attach route‑tags or local preference changes based on RPKI validation state.
• This supports deployment patterns where some speakers set the community and downstream peers enforce RPKI filtering or preferences without repeating expensive RPKI lookups.

---

Technical deep dives​

Syslog TLS: configuration and caveats​

VyOS’s syslog TLS support follows a simple model: configure a remote syslog host to use TCP, enable TLS for that host, and then supply CA and (optional) client certificates. The available auth modes are:

• anon: TLS without server auth — useful for testing but insecure.
• fingerprint: check a certificate fingerprint.
• certvalid: trust CA-signed server cert (no CN check).
• name: CA validation plus CN verification (recommended for production).

Security recommendations:

• Prefer auth-mode name with explicit permitted-peer settings to avoid MITM risks.
• Use managed PKI to rotate certificates and keep private keys off general-purpose partitions.
• Validate the collector’s logging behavior (buffering and reconnection) — moving from UDP to TCP+TLS changes delivery semantics and observability tooling must account for transient disconnections.

AWS GWLB integration: what the feature actually does​

The GWLB model expects targets to accept GENEVE-encapsulated traffic from the GWLBE. Linux-based targets commonly run a tunnel-handler (gwlbtun) that instantiates per‑ENI tunnel interfaces and hands traffic to local packet processing (iptables, NF‑QUEUE, or userland apps). AWS published guidance and a reference gwlbtun implementation; vendors and appliances often either embed equivalent logic or use OVS (which understands GENEVE) plus handling of GWLB TLVs. VyOS’s support likely integrates similar tunnel-handler logic or compatibility with gwlbtun patterns to allow packet inspection workflows to function correctly on AWS targets. Operators should assume this feature is targeted at AWS deployments and verify health-check and MTU behavior in their test environment. Important caveats:

• The GWLB path is specific to AWS — comparable solutions in Azure/GCP use different load-steering primitives and encapsulations.
• High packet-per-second (pps) workloads may need kernel tuning, afinity and receive‑buffer adjustments, and careful NUMA/cpu pinning to avoid packet drops. The gwlbtun documentation and AWS blog post offer detailed performance guidance.

BGP rule-matching on RPKI communities​

RFC 8097 defines the Origin Validation State Extended Community (non‑transitive opaque community) and recommends that networks advertise validation state internally to avoid repeated lookups. VyOS’s route-map matching addition means an operator can:

• Match route entries carrying origin validation state extended community,
• Use that match to set local preference, MED, community, or to reject routes in route maps,
• Implement controls that prefer RPKI-validated routes over others without altering the BGP decision engine directly.

This is a practical approach for networks where only some speakers run RPKI clients; the validated state can be signalled via the extended community and acted upon throughout the AS.

---

Upgrade and migration considerations​

Multicast address assignment change​

VyOS 1.4.4 prohibits manual assignment of multicast addresses to interfaces. This tightening prevents malformed or legacy configurations from introducing ambiguous multicast state. If your existing configurations include non-standard multicast assignments, test upgrades in a lab and be prepared to remediate interface address settings before upgrading. The project’s task tracker and release notes highlight this as an upgrade-impact item.

SSH DSA deprecation — migration timeline​

OpenSSH has been actively deprecating DSA (ssh‑dss) keys due to their limited security (160‑bit DSA with SHA‑1) and the upstream OpenSSH team’s removal timeline. VyOS 1.4.4 explicitly warns that DSA keys are deprecated and that DSA support will stop working in VyOS releases after 1.5 (the change correlates to upstream OpenSSH removals). Administrators still using DSA‑based keys should migrate to modern algorithms (Ed25519 or RSA with sufficient key size) before upgrading to avoid management lockouts. Migration checklist:

• Audit all devices for ssh-dss keys in authorized_keys and host key files.
• Generate Ed25519 (recommended) or RSA-4096 host and user keys.
• Update automation (Ansible, SSH configs, key rotation tooling) to accept modern algorithms.
• Stage the migration on spare hosts and confirm login paths work (console access or out‑of‑band recovery recommended).

Testing and rollout strategy (recommended)​

• Stage: Create an identical testbed (VM or cloud instance) and upgrade a single node.
• Validate: Confirm BGP adjacencies, route-map behavior (especially RPKI community matching), syslog delivery over TLS, and GWLB health-check integration.
• Performance: Run throughput and pps tests if the node participates in GWLB or high-rate forwarding.
• Gradual rollout: Upgrade leaf nodes first, then distribution and core nodes, and maintain rollback images for quick reversion.
• Post-upgrade audit: Run configuration checks for multicast addresses and SSH key compatibility.

This sequence reduces blast radius and ensures you can recover quickly if an unsupported legacy configuration is exposed by the upgrade.

---

Security and operational analysis — strengths and risks​

Strengths​

• Security-first observability: TLS syslog support is a meaningful step for secure telemetry, reducing the need for bespoke TLS tunnels or on-host forwarding proxies.
• Cloud‑native inspection readiness: Supporting AWS GWLB patterns removes a friction point for teams that want a single appliance image to work across on-prem and AWS inspection pipelines.
• RPKI-aware policy controls: Matching origin validation extended communities directly in route maps gives operators practical tools to shape routing decisions without waiting for full feature parity in upstream decision processes.
• Focused maintenance scope: The release is clearly a maintenance/minor feature update — the changes are narrowly scoped and intended to reduce operational pain rather than add a broad new feature set.

Risks and potential downsides​

• AWS-only caveat for GWLB: The GWLB support is explicitly AWS‑specific. Organizations that require comparable functionality in Azure or GCP must still build provider‑specific solutions or await further platform work.
• Upgrade friction from config hygiene changes: The multicast-address restriction will catch malformed legacy configs; teams must audit and remediate prior to upgrades, or risk configuration failures.
• Dependency on upstream OpenSSH timeline: The DSA deprecation maps to OpenSSH’s upstream removal timeline; while this improves security posture, it can strand poorly managed automation and embedded systems that still rely on legacy DSA keys. Operators must plan and test key rotations carefully.
• Operational complexity for GWLB at scale: GWLB tunnel handling (GENEVE, TLV parsing, per‑ENI tunnels) introduces kernel and userland complexities — without careful tuning and capacity planning, GWLB targets can be CPU‑bound or drop packets under microbursts. The AWS reference and gwlbtun docs highlight the need for careful tuning.

---

Practical recommendations for IT teams and network operators​

• Treat this release as a maintenance upgrade: prioritize it for environments that will benefit from TLS syslog, GWLB compatibility, or improved RPKI policy handling.
• Audit SSH keys and automation workflows now; migrate DSA keys to Ed25519 or RSA as required well before rolling out 1.5.x images.
• For any AWS GWLB deployments, prototype with gwlbtun or equivalent and validate health checks, MTU, and rp_filter settings; include kernel tuning in the test plan.
• Use route-map matches for origin-validation communities to implement conservative RPKI-aware policies (e.g., lower preference for invalids, prefer valid routes). Test in a non-production IBGP domain first.

---

Verification and cross-checks​

The claims in VyOS’s announcement are consistent with vendor documentation and public references:

• The syslog TLS configuration and supported auth modes are documented in the VyOS 1.4 syslog guide.
• The GWLB handling pattern and tunnel handler model are documented in AWS’s GWLB blog and the AWS sample repository (gwlbtun) used by appliance vendors.
• The BGP origin validation extended community is defined in RFC 8097 and is widely referenced by network vendors for RPKI-aware policy behavior.
• OpenSSH’s deprecation timeline for DSA keys is public and explains why distributions and downstream appliances are moving to disable or remove DSA support. VyOS’s deprecation note aligns with this upstream schedule.

As part of validation, internal forum and operations logs (from the provided repository of internal technical threads) were reviewed for community context and to cross‑check upgrade impact conversations from engineers and operators.
Note: The “more than 50 bug fixes” headline comes from the official release announcement. For teams that need the verbatim changelog per bug ID, check the VyOS project change list in the official download or release artifact (operators should confirm the full changelog in the product downloads or project tracker before mass upgrades).

---

Final verdict — who should upgrade and when​

VyOS 1.4.4 LTS is a practical, conservative maintenance release aimed at improving security posture and cloud inspection interoperability while tightening routing-policy controls. It is well suited for:

• Teams that need encrypted syslog without adding extra proxies.
• Organizations deploying inspection appliances in AWS using Gateway Load Balancer who want a unified VyOS image for both on‑prem and cloud.
• Networks looking to operationalize RPKI signals inside policy frameworks without reworking the BGP decision process across all routers.

Plan upgrades now if you depend on these capabilities, but stage carefully:

• Audit multicast and SSH DSA usage first.
• Confirm GWLB-related performance and kernel tuning before moving into production.
• Validate RPKI policy logic in a lab before broad distribution changes.

VyOS 1.4.4 LTS is not a wholesale platform overhaul; rather, it’s an incremental but meaningful improvement that removes some historical friction for hybrid cloud and modern operational security. For organizations standardizing on VyOS as their universal network OS, this release reduces integration friction with mainstream cloud inspection patterns and aligns routing-policy tools with current RPKI practices — provided operators perform the pre-upgrade checks and certificate/key migrations the release identifies.

---

Conclusion
VyOS 1.4.4 LTS delivers targeted, useful updates for hybrid‑cloud networking and secure operations: encrypted syslog, AWS GWLB target readiness, and RPKI-aware route‑map matching are all pragmatic features for modern distributed networks. The release is conservative and production-focused, but requires administrators to inspect legacy configurations (multicast address usage) and to move away from deprecated SSH DSA keys before downstream OpenSSH removals take effect. With careful staging and certificate/key hygiene, this maintenance release should smooth several integration pain points for teams operating across on‑prem and cloud environments.

---

Source: The Manila Times VyOS Networks Announces VyOS 1.4.4 LTS Release, Reinforcing the Universal Networking Platform for Hybrid Cloud and Edge