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

    Routing all traffic through the tunnel doesn't work

    OpenVPN
    3
    7
    4.1k
    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.
    • M
      mihai
      last edited by

      Hello folks.

      I've installed pfSense and started in a dual-wan load-balancing/failover config.
      I'm an older fan of OpenVPN but I was never actually able to have all client traffic routed through the tunnel.

      I can ping the endpoint, I can ping out both of it's WANs, I can ping every machine behind the NAT, i've used the:
      push "redirect-gateway def1";push "dhcp-option DNS (nameserver's_ip)"
      directives, yet no packet gets out on any of the machine's WANs and I'm basically like a local internal workstation with no internet access.

      netstat -r -n
      on my local machine indicated the default gateway as being the remote endpoint so everything's OK.

      I'm assuming that the machine doesn't know how to route my traffic out so it's likely that I did everything OK but I don't know how to route OpenVPN's traffic out.

      Any help, greatly appreciated. Thanks a lot.

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        do you get anything blocked in your firewall-log?

        i have this exact setup working at my home.

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • M
          mihai
          last edited by

          @GruensFroeschli:

          do you get anything blocked in your firewall-log?

          i have this exact setup working at my home.

          Aug 6 05:02:00 pf: 000097 rule 375/0(match): block in on rl1: (tos 0x0, ttl 128, id 60301, offset 0, flags [none], proto: UDP (17), length: 128) 192.168.0.1.1029 > 255.255.255.255.100: UDP, length 100

          Could this be? This is after using the TCP protocol, because previously it bitched about about some UDP packet being too short.

          Anyway, another noticeable thing is that when opening a IE window and trying to access Google, it actually resolves the name, while on my previus attempts this wasn't the case.

          Anyway, it seems to me like a routing problem more and more, except I don't know exactly what should I do.

          On openvpn.net, in their how-to, they said that once I do these settings, I have to set up the router somehow, making it able to handle this traffic. This is what I don't know.

          1 Reply Last reply Reply Quote 0
          • F
            foobar
            last edited by

            mihai, did you solve this? i have the very exact same problem. i reach all my lan clients when i connect to the vpn from a road-warrior state but i cant reach internet via the vpn, also using redirect-gateway.  DNS lookups seems to work but ping is dead. routes on my laptop seems ok via netstat.

            please share your solution if you have one :)

            1 Reply Last reply Reply Quote 0
            • GruensFroeschliG
              GruensFroeschli
              last edited by

              on thing you could try:
              i have an OpenVPN server running on a few setup's but they all use Advanced outbound NAT.
              do you use it too? you need to add a rule that your OpenVPN subnet gets NAT'ed out.

              if not.
              try enabling AoN and add a rule for the OpenVPN subnet.

              We do what we must, because we can.

              Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

              1 Reply Last reply Reply Quote 0
              • M
                mihai
                last edited by

                @GruensFroeschli:

                on thing you could try:
                i have an OpenVPN server running on a few setup's but they all use Advanced outbound NAT.
                do you use it too? you need to add a rule that your OpenVPN subnet gets NAT'ed out.

                if not.
                try enabling AoN and add a rule for the OpenVPN subnet.

                Worked like a charm !!!

                Thanks a lot, GruensFroeschli.

                Foobar, here's what I did, following GruensFroeschli's instructions.
                First, I've reenabled the:
                push "redirect-gateway def1";push "dhcp-option DNS 10.20.1.1"
                directive in my OpenVPN server config (you should replace the pushed DNS server (in my case 10.20.1.1) with your pfSense OpenVPN endpoint IP - this is not the LAN IP address)

                Next I went to the Firewall::NAT menu, clicked the Outbound tab then selected:
                Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))
                Next, I manually configured the natting my pfSense machine was doing while working with Automatic outbound NAT.
                In my case, because I have to ISPs and I am loadbalancing/failover them, I had to enter three rules:

                Interface: WAN
                Source: My local network IP class.
                2.
                Interface: WAN2
                Source: My local network IP class.
                3.
                Interface: WAN
                Source: 10.20.1.0/24 (my OpenVPN class)

                It's likely that you will only have to enter rules 1 and 3, unless of course you don't have a similar setup.

                Please let me know if that worked for you.

                1 Reply Last reply Reply Quote 0
                • F
                  foobar
                  last edited by

                  ahhh finaly!! thanks GruensFroeschli and mihai, i love you <3

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