WireGuard can be configured/run via the web interface, or at the command line. Either interface lets you configure Wireguard settings and generate configuration scripts. This page describes how to configure Wireguard through the web interface.

To configure WireGuard manually, and for some basic theory, see the HOWTO: Set up WireGuard . That page is more appropriate when you're not using an external VPN provider. It is more intended to discuss the configuration VPNs with a hub-and-spoke or mesh topology.

Unless using an external VPN provider, it's best to “nominate” a main router that will produce configurations. Clients, such as other FreshTomato routers and other devices, must import the configuration generated by this main router. Relevant configuration changes may require you to delete and reimport the configuration on those client devices.

The WireGuard web interface menu has been working since r2024.1. IPv4 is fully supported, but IPv6 is not supported at this time.

Policy-based Routing and the kill switch feature are supported since r2025.3. Split-tunneling is supported within Policy-based Routing.

Two serious bugs in r2025.3 and earlier can cause kernel panics. See the WireGuard Notes and Troubleshooting section at the bottom for details.

Starting with r2025.3, FreshTomato supports the import of preconfigured Wireguard configuration scripts from external VPN providers.

These VPN providers' scripts have been tested as working:

• Coming soon: IVPN
• Integrity VPN
• NordVPN
• PIA (Private Internet Access
• ProtonVPN
• SurfShark
• Windscribe
  

Alternatively, many have successfully used the following tutorial to manually configure settings for an external VPN Provider:

How to Connect to a VPN Provider's WireGuard Tunnel on FreshTomato

Icons here indicate the tunnel/service status, and also allow you to stop and start the tunnel/service.

indicates the Wireguard service isn't running and no VPN tunnel currently exists on this interface.

clicking this starts the WireGuard service, and makes the interface negotiate a VPN tunnel to peers.

indicates the selected WireGuard connection is running, and connected to the configured peers.

terminates the current WireGuard VPN tunnel and stops the service.

WireGuard uses virtual network adapters (or “network interfaces”) on which to operate a VPN tunnel. WireGuard creates a virtual network interface (such as “wg0”) on your device that behaves like a standard network adapter. This virtual adapter routes your traffic through the encrypted tunnel between peers.

Wireguard allows you to create 3 separate virtual network adapters to allow for 3 separate VPN configurations (or “instances” in WireGuard terminology). In Freshtomato, each virtual adapter is represented by a tab, such as wg0, wg1, or wg2.


the first Wireguard interface/instance.

the second Wireguard interface/instance.

the third Wireguard interface/instance.

Each interface/tunnel tab can contain its own unique configuration, encryption keys, and so on. Options for each interface are explained below.

here, you enter the main configuration settings for the chosen interface.

Enable on Start - makes FreshTomato start Wireguard at boot, build the tunnel and connect to peers.

This is currently NOT recommended until some serious bugs are fixed. See the WireGuard Notes and Troubleshooting section for details.

Poll Interval - WireGuard's PersistentKeepalive setting.

This determines how often the client sends keepalive packets to maintain NAT mappings when behind NAT.

• The recommended setting is 25 seconds. This causes WireGuard
  to send a small packet to its peer every 25 seconds when no
  other traffic occurs. This keeps the connection alive through
  NAT or firewalls that might otherwise close idle UDP sessions.
• Default: 0. This disables the feature, so packets are sent only
  as needed. This is fine for most users not behind restrictive NAT.

Config file - here, enter the path to a WireGuard configuration file.

If a path/file is specified here, all other settings in the web interface will be ignored.

Port - the UDP the port on which the interface’s tunnel will be built with the remote endpoints.

This is the same as the “ListenPort” setting in a wg-quick configuration file. Leaving this blank causes WireGuard to automatically choose a different free UDP listening port each time the interface starts.

Private Key - here, enter the private key for the VPN tunnel.

If you import a prebuilt configuration file from an external VPN provider, this should populate automatically.

Public Key - displays the tunnel's public key.

WireGuard automatically generates this using the Private Key. This field cannot be directly edited.

VPN Interface IP - the IP address to be assigned to the virtual network interface.

This is used to communicate only inside the tunnel. It is independent from the physical network interface's IP addresses. To prevent addressing conflicts on participating networks or VPN peers, this must be a unique address space, specifically set aside for the VPN.

It must be written using CIDR notation. For example: “10.0.0.1/32”. Addresses should be separated by commas or newline characters.

DNS Servers (out) - the nameservers the client device will use for DNS lookups once the tunnel is active.

These can be:

• Internal (private) to the VPN, such as a DNS resolver reachable only via the VPN.
• Public, such as Google DNS (8.8.8.8) or Cloudflare (1.1.1.1).

This is usually wanted in site-to-site topology VPNs.

This setting is the same as the “DNS” setting in a wg-quick configuration file

FWMark - used to mark outgoing encrypted packets with a firewall mark.

Use of this mark is helpful for configuring advanced routing decisions, such as policy-based routing. It lets the system differentiate and route WireGuard traffic based on the mark, often associating it with a specific routing table. This is the same as the “FwMark” setting in a wg-quick configuration file.

For example, packets marked with a fwmark can be routed through a dedicated route table. This allows you to run complex routing scenarios, such as routing some traffic through the WireGuard tunnel (split-tunnel) or even using multiple tunnels with different policies.

MTU - lets you set the Maximum Transmission Unit.

This is the largest packet size that can be sent over the WireGuard interface without fragmentation.

• Setting the MTU correctly helps avoid packet fragmentation.
  Fragmentation can cause slow speeds, connection drops,
  and other inefficiencies.
• If MTU is too high, packets may exceed the size supported by
  the underlying network. This could cause fragmentation or
  packet drops.
• If set too low, it reduces efficiency by sending smaller packets
  than necessary.
• Default for IPv4: typically around 1420 bytes (with 60 bytes
  used for tunnel overhead).
• Default for IPv6: typically, the recommended MTU is 1280 bytes.

Respond to DNS - enables dnsmasq to resolve DNS queries arriving on this interface.

Routing Mode - Here, select the mode to used on the WireGuard interface.

This option appears only when one of the Internal hub-and-spoke or mesh VPN types is selected.

• Off - FreshTomato won't add any routing rules for the the
  WireGuard interface.
  
• Auto - choosing this means the WireGuard interface will be routed
  using the default table (the same number as the interface port)
  
• Custom Table - this option will route the WireGuard interface
  using a custom table number. If you choose this option, you must
  include the table number in the additional field.

Firewall - lets you choose the appropriate firewall setting for your WireGuard setup.

• Create NAT on tunnel - enables Network Address Translation on the tunnel.
  When checked, FreshTomato rewrites the source addresses
  of packets going through the tunnel, making them appear as if
  they originated from the router itself (using the router’s VPN tunnel IP),
  rather than from their original LAN addresses.
  
  This helps VPN clients behind the tunnel to access external networks,
  such as the Internet. It can also simplify routing by hiding the client's
  real IP behind the tunnel's IP. This is useful if the VPN clients are on
  private or overlapping IP ranges, or if the destination network only knows
  about the server IP address.
  
  
• Inbound Firewall - adds firewall rules to let inbound Wireguard traffic through the WAN interface.
  This opens the necessary WireGuard port so clients can connect
  from outside networks. As a result, incoming Wireguard traffic is
  accepted without requiring additional manual firewall rule configuration.
  This supports NAT and other, related WireGuard security rules.

Type of VPN - lets you set the type of VPN topology generated.

• Hub and Spoke - All peers can only communicate via the Hub.
• Full Mesh (defined Endpoint only) - FreshTomato will try to create
  a full mesh among peers with EndPoint defined.
• Full Mesh - FreshTomato will try to establish a full mesh
  between all peers.
• External VPN Provider - FreshTomato will try to establish
  a VPN connection with an external VPN provider.

Depending on the setting you choose, other fields will appear in which to configure more settings.

To learn about WireGuard topologies, see this webpage: Procustodibus: Primary WireGuard Topologies

Redirect Internet traffic -

• 
  
• All
  
• Routing Policy
  
• Routing Policy (Strict)

in this tab, enter information about the peer parameters.

Status

1. A bug in FreshTomato's CTF support for Wireguard resulted in
   a kernel panic and router reboot right after bringing up the wg0
   interface. This is believed to have been fixed. The fix should be
   available in r2025.4 or in an image built from the current git.
   For earlier releases, there are some reports of disabling CTF
   working as a workaround.
2. Another serious bug exists in which a kernel panic and reboot
   may occur if the WAN interface is disconnected.
   This may occur even when the disconnect is expected,
   such as after clicking Release Connection in the Overview menu.
3. Some users have reported speed issues when enabling CTF
   with Wireguard running, while others have experienced no issues
   or even greatly increased throughput.

Please remember these troubleshooting tips when trying to configure your VPN:

• wg show (via the command line) output will help you
  understand the relationship between peers.
• route (via the command line) can help you to verify
  routing decisions when the VPN is connected.
• traceroute is a must when verifying end-to-end connectivity.
  A good approach is to test the following in order:
  • Local LAN IP
  • Local VPN IP
  • Remote VPN IP
  • Remote LAN IP

The point of failure found will provide critical insight into the type of issue you are facing.