Problems with connecting IPFire Router to a Self-hosted Wireguard VPN Server. (Unresolved)

Virtual Private Networks WireGuard
21

:thinking:
Mullvad is paid, so for testing I would suggest using Protonvpn.
Protonvpn has been pretested
-configuration files imported without errors
-connection between IPFire and Protonvpn works.

For testing, the free plan is sufficient.

22

Sorry I havenā€™t been feeling well lately. Iā€™ve been feeling burned out and overwhelmed from trying to get Wireguard to work (spent over a week of constant stress trying to get it to work.) when I couldā€™ve went with the more standard easier trivial options such as Tailscale as most of the Wireguard configuration on routers (such as OpenWRT, OPNSense, even IPFire that I am using currently, etcā€¦) seems to be more of for network enthusiasts that have the ability, money, time, resources and the means to expose a port when I clearly donā€™t have that capability at home. (Still 17 in high school.)

Not to mention I tried reinstalling IPFire and doing all the steps all over again but I could never get it to work. It seems that it keeps resulting in the same looping error message again and again. I will have to turn to using Tailscale as most of the Wireguard configurations of configuring on IPFire seems to be riddled with unexplainable errors. Maybe in the future IPFire will get better and finally address this issue. But for now, this issue will still currently remain unresolved* till this day.

(Sorry I need to take a break, itā€™s really starting to have a huge toll on my mental health.)

23

During the break you could review the following information. :wink:

Regards

24

Just to be clear, there are many users on here who are not having issues. Iā€™ve been using IPFire for close to 15 years and it has been the easiest open source firewall Iā€™ve worked with. Wireguard works for many on here, as well as myself. Iā€™ve only used it in ā€œroadwarriorā€ mode but it was pretty painless to set up and get working. I wish you the best and I hope your break will yield fruit moving forward.

25

I have been trying a similar case like yours, that is, to set up a wireguard tunnel to a another wireguard peer and route all Blue and/or Green traffic via the tunnel.

Ipfire uses a Dual Mode System:

  • Host-to-Net for client VPN connections

    • this is your normal Roadwarrior setup, ipfire acting like your VPN provider, issuing wg configuration files for clients to remotely connect to your local network
    • Here you expect the [Interface] to contain values for LocalAddress and DNS

  • Net-to-Net for site-to-site connections

    • this is about enabling point to point traffic (neither is a client, joined up networks) hence the wg configuration file produced by ipfire is for setting up the other endpoint.
    • Here the [interface] has only the private key for the other end-point (since ipfires has its public key). There is no need here for LocalAddress or DNS

So using a wg config created for Host-to-Net (this is what your VPN provider or VPN Server produces), on a Net-to-Net configuration will result in what you are experiencing, wireguard connection not getting activated or nothing routed through.

To activate a Net-to-Net connection from a RW-like config you have to

  1. under console, open /var/ipfire/wireguard/peer, find the line that has net type, and append at the end the LocalAddress i.e.. ..,25,10.5.0.2/32
    1. when RW config is imported it seems that the LocalAddress is not persisted hence needs to be added manually (@ms is this an issue or expected behaviour ?)

This will result in

  1. wireguard peer connection gets activated
  2. wg{id} gets assigned your designated VPN client IP
  3. Masquerading is setup over wg{id} (WGNAT)
  4. routes & rules are setup
  5. :high_voltage: DANGER :high_voltage: any unsolicited packet on wg{id} is allowed from 0.0.0.0/0 ā†’ local routes (via WGBLOCK, WGINPUT)

At this point from the ipfire console you can do the below which shows the tunnel is up and running

# ip addr show | grep wg
54: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
57: wg3: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.5.0.2/32 scope global wg3

# curl --interface wg3 https://ipinfo.io/ip
156.167.93.133

However, at this point green0 and blue0 traffic are not forwarded

image
image1882Ɨ258 44.9 KB

Need to investigate further both green and blue traffic everything gets dropped.

PS: This is what the wireguard init.d script performs which could be replicated for setting up the VPN tunnel

For road warrior interface (wg0):

  • Sets private key and listen port from global settings

  • Adds client pool to routing table

  • For each enabled host-type peer, adds a [Peer] section with public key, preshared key (if set), and allowed IPs

For network-to-network interfaces (wg{id}):

  • Sets interface alias to connection name

  • Assigns local IP address if specified

  • Configures NAT with iptables

  • Creates [Interface] section with private key and listen port

  • Creates [Peer] section with public key, endpoint, allowed IPs, and keepalive settings

  • Sets up routing for remote subnets

  • Adds firewall rules to allow traffic between local and remote subnets

26

I have spent some time looking into this and concluded that

  • :high_voltage: It is unsafe:high_voltage: to meddle with Roadwarrior-type profiles on Net-2-Net configuration as this can open your network to unsolicited internet traffic.
  • Selectively tunneling a local subnet over VPN is a use case in itself, and is not supported by the current IPFire WireGuard design

To summarise the goal, we are looking for a way to have

  • Traffic from the Blue Zone (192.168.2.0/24) exit to the internet via the VPN tunnel.
  • Traffic from the Green Zone (192.168.1.0/24) and the firewall itself use the primary WAN connection.
  • Local services on the firewall (DNS, DHCP) must remain accessible to all internal clients.

Therefore a solution should

  • Read the VPN providerā€™s Wireguard config file
  • Set up the wg interface and gets the tunnel activated
  • Set up the routing and routing policies,
    • in my case blue0ā†’wgā†’VPN serverā†’ inet
  • Set up the NAT & Forward policies, while preserving the security of ipfire

I have put a more detail explanation on why net-2-net wonā€™t work along with the script that can get your subnet tunneled over VPN to

  1. your Wireguard Server
  2. your VPN service provider

The solution aims to remain within the bounds of ipfireā€™s current design/architecture, therefore it can be adjusted so we can take advantage of ipfireā€™s Firewall WebUI to create rules for toggling VPN tunnelling on/off across a subnet of our preference.