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

    Wireguard tunnel up but traffic wont use it

    Scheduled Pinned Locked Moved WireGuard
    6 Posts 3 Posters 716 Views
    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.
    • opticalcO
      opticalc
      last edited by

      Im converting my Squid proxy server's outgoing interface from Cyberghost OpenVPN to ProtonVPN Wireguard.

      Since the OVPN is on top of squid, my configs dont require any outbound NATting configs like you do when the client traffic enters the router via regular ethernet egress; since we're using squid all I had to do was create the OpenVPN client, its interface, and gateway (that last one may not even have been necessary to use the OVPN connection directly on squid) and then set this config in Squid:
      f85c0dfd-6b87-45b1-98ab-279fe54cd917-image.png

      And that has worked just great for years as shown on ipinfo.io

      And now it just seems that WG should be a straight drop in, where I create the WG tunnel, peer, interface, and gateway. They are UP:
      1cab7c93-c982-48f0-a397-396f8f2adf25-image.png

      But any client using squid then just gets directed out my netgate's main default route to my ISP, as shown by ipinfo.io

      For WG, are some other things needed that I'm missing?

      Bob.DigB J 2 Replies Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8 @opticalc
        last edited by

        @opticalc said in Wireguard tunnel up but traffic wont use it:

        Squid

        Does it work without Squid? Not a Squid user.

        opticalcO 1 Reply Last reply Reply Quote 0
        • J
          Jarhead @opticalc
          last edited by

          @opticalc WG doesn't add routes automatically. Check diagnostic/routes to confirm, then add static route as needed.

          1 Reply Last reply Reply Quote 0
          • opticalcO
            opticalc @Bob.Dig
            last edited by opticalc

            @Bob-Dig
            @Jarhead
            Seems like not.. I went all the way with the config for my LAN that used the Cyberghost OVPN and replaced that LANS ruleset that sets the cyberghost interface for the outbound routing to the new route for ProtonVPN. I also went into the outbound NAT and replaced all the configs of cyberghost ovpn with the new protonvpn settings.

            Now, no one on that lan can get to the internet at all. I packed sniffed the WG tunnel interface and theres no traffic at all.

            I do have this:
            0ebf6e74-eee6-40fe-8552-69064000af4d-image.png

            So it seems WG is up. Not sure what is wrong. Im sure I missed something here, but not sure what it is. Ive done this kind of thing quite a few times with OVPN, this time doing WG is the first. I followed all the ProtonVPN instructions

            Bob.DigB 1 Reply Last reply Reply Quote 0
            • Bob.DigB
              Bob.Dig LAYER 8 @opticalc
              last edited by

              @opticalc Have you set the MTU on that interface?

              opticalcO 1 Reply Last reply Reply Quote 0
              • opticalcO
                opticalc @Bob.Dig
                last edited by

                @Bob-Dig
                No. I can ping out though on a shell on my netgate (freebsd uses ICMP for pings unlike cisco routers which are udp)

                and can specify no fragment with up to 1472:

                ping -D -t 1 -s 1472 10.2.0.1
                PING 10.2.0.1 (10.2.0.1): 1472 data bytes
                1480 bytes from 10.2.0.1: icmp_seq=0 ttl=64 time=148.918 ms
                
                --- 10.2.0.1 ping statistics ---
                1 packets transmitted, 1 packets received, 0.0% packet loss
                round-trip min/avg/max/stddev = 148.918/148.918/148.918/0.000 ms
                

                Where then trying at 1473 I get ping: sendto: Message too long
                The pings that do work, now show up in packet captures on that WG interface.
                So pretty sure MTU/MSS cant be the problem

                Whats really bizarre though is if I set my squids outgoing interface back to the cyberghost one, then squid clients going to ipinfo show an italian IP address as expected. But then if I set squids outgoing interface to the new WG tunnel interface then squid clients that use ipinfo return the local ISP WAN IP address.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.