Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    wireguard->protonvpn policy routing broken since 25.07.01

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 658 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • 4 Offline
      4o4rh
      last edited by 4o4rh

      I previously had wireguard working for a long time already on a dual wan failover and a wireguard to openvpn failover for with the original settings below

      WAN1 igb0 -> eth to Fritzbox -> PPPoE fibre
      WAN2 igb1 -> eth to cable modem

      Original MTU/MSS settings that worked
      pppoe MTU (default i.e. 1500)
      pppoe MSS 1452 (-40)
      tun_wg0 MTU 1412
      maxmss 1452
      opnvpn tun-mtu 1500
      opnvpn tun-mtu-extra 32
      opnvpn mssfix 1452

      wireguard has been playing up for about a week, and chatgpt gives me the below calculations

      pppoe MTU 1492
      pppoe MSS 1492 (-40)
      tun_wg0 MTU 1412
      maxmss 1452
      opnvpn tun-mtu 1480
      opnvpn mssfix 1452

      openvpn and the wan seems to be working fine.

      from a client

      curl -vk https://scmp.com
* Host scmp.com:443 was resolved.
* IPv6: 2606:4700::6812:cc2b, 2606:4700::6812:cd2b
* IPv4: 104.18.204.43, 104.18.205.43
*   Trying [2606:4700::6812:cc2b]:443...
* Immediate connect fail for 2606:4700::6812:cc2b: Cannot assign requested address
*   Trying [2606:4700::6812:cd2b]:443...
* Immediate connect fail for 2606:4700::6812:cd2b: Cannot assign requested address
*   Trying 104.18.204.43:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

      ping from pfsense over the wireguard interface works fine. I have tried lowering the MTU for wireguard, but i can't seem to get a value that actually works

      EDIT: the it is not a MTU/MSS issue. I have set the bridge and WG and WAN interfaces to have MSS of 1372.

      T 4 2 Replies Last reply Reply Quote 0
      • T Offline
        TheNarc @4o4rh
        last edited by

        @4o4rh How low did you try? I have a wireguard connection to ProtonVPN and set MTU and MSS to 1420 (for the wireguard interface) and have never had an issue.

        4 1 Reply Last reply Reply Quote 0
        • 4 Offline
          4o4rh @TheNarc
          last edited by 4o4rh

          I set MTU 1472 and MSS to 1432 on both links.
          I have tried a range of mtu-tun for wireguard down to 1320.
          everything causes SSL error

          An error occurred during a connection to thermalright.com. PR_END_OF_FILE_ERROR
Error code: PR_END_OF_FILE_ERROR
    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

          just started about 2 weeks ago. have tried switching to configs from different countries, routing through different wans. nothing works

          1 Reply Last reply Reply Quote 0
          • 4 Offline
            4o4rh @4o4rh
            last edited by 4o4rh

            After extensive testing.

            • I have deleted the tunnels/peers/gateways and recreated.
            • switched NAT from Hybrid to Manual and back to Hybrid (although none of these had changed)
            • deleted the interfaces / gateways and recreated

            So:

            • it is not a corrupted config file.
            • the config was working prior to 25.07.01 upgrade

            Noticeable behavior that is different

            • saving a change to an interface, causes wireguard to stop reaching the monitoring 1.1.1.1 address (never used to have this problem)
            • switching the default gateway from WAN1 to 2, or 2 to 1 restores connection to the monitoring address
            • client on bridge1 (vlan40) network can ping the gateway 10.2.0.1
            • client on bridge1 can NOT ping 1.1.1.1 or any internet address via WG gateway (but WAN / OPNVPN gateways no problem)
            • curl to any internet address returns error 0A000126:SSL unexpected EOF while reading via WG ( but WAN/OPNVPN gateways work)
            • if you edit the wg gateway and try to save, it also gives the error "The gateway address 10.2.0.1 does not lie within one of the chosen interface's subnets." when the tunnel end is 10.2.0.2/32 - this is new behaviour as well
            scrub from any to <vpn_networks> no-df max-mss 1372 fragment reassemble
scrub from <vpn_networks> to any no-df max-mss 1372 fragment reassemble
scrub on pppoe0 inet all no-df max-mss 1372 fragment reassemble
scrub on igb1 inet all no-df max-mss 1372 fragment reassemble
scrub on bridge1 inet all no-df max-mss 1372 fragment reassemble
scrub on lagg0.40 inet all no-df fragment reassemble
scrub on igb6.40 inet all no-df fragment reassemble

            Do I need to set the mss max on the individual interfaces even though i have the below settings

            net.link.bridge.pfil_member 	Packet filter on the member interface 	0 	
net.link.bridge.pfil_bridge 	Packet filter on the bridge interface 	1 	
net.inet.ip.forwarding 	Enable packet forwarding between interfaces (required for NAT reflection) 	1 	
net.link.bridge.vlan_filter 	Enable VLAN filtering on the bridge (required if you use VLAN‑aware bridges). 	1

            tcpdump -i bridge1 icmp

            tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bridge1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:35:50.896835 IP v110.lan > one.one.one.one: ICMP echo request, id 51, seq 1, length 64
12:35:51.897180 IP 110.lan > one.one.one.one: ICMP echo request, id 51, seq 2, length 64
12:35:52.921189 IP v110.lan > one.one.one.one: ICMP echo request, id 51, seq 3, length 64
12:35:53.945298 IP v110.lan > one.one.one.one: ICMP echo request, id 51, seq 4, length 64
12:35:54.969258 IP v110.lan > one.one.one.one: ICMP echo request, id 51, seq 5, length 64

            tcpdump -i tun_wg0 icmp

            tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun_wg0, link-type NULL (BSD loopback), snapshot length 262144 bytes
---- nothing going through the tunnel

            tcpdump -i igb1 icmp

            tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:38:11.325166 IP ip-xxx-xxx-xxx-xxx.um05.pools.vodafone-ip.de > one.one.one.one: ICMP echo request, id 39605, seq 8620, length 9
12:38:11.325207 IP ip-xxx-xxx-xxx-xxx.um05.pools.vodafone-ip.de > 145.253.xx.xx: ICMP echo request, id 42609, seq 8620, length 9
12:38:11.333470 IP one.one.one.one > ip-xxx-xxx-xxx-xxx.um05.pools.vodafone-ip.de: ICMP echo reply, id 39605, seq 8620, length 9
12:38:11.334976 IP 145.253.xx.xx > ip-xxx-xxx-xxx-xxx.um05.pools.vodafone-ip.de: ICMP echo reply, id 42609, seq 8620, length 9
12:38:11.825337 IP ip-xxx-xxx-xxx-xxx.um05.pools.vodafone-ip.de > 145.253.xx.xx: ICMP echo request, id 42609, seq 8621, length 9

            So it seems, even though the rules are on the bridge per below, policy routing is not working
            201e6b7b-61ae-4828-a9c5-ee7ce5638676-image.png

            I have made work off those !LOCAL rules to allow any protocol and disabled the other. No difference

            NAT is being used in Hybrid and worked previously
            3c9eb8a4-78e1-4511-8e74-238cc1e67a72-image.png

            Also, switching the gateway from wg to opnvpn and everything is working.

            This looks like a defect introduced from 25.07.01 onwards, or, am I missing something?
            some compatibility issue between wireguard and bridge?

            1 Reply Last reply Reply Quote 0
            • 4 4o4rh referenced this topic on
            • Bob.DigB Bob.Dig referenced this topic on
            • First post
              Last post
            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.