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

    "redirect-gateway" and internet access

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 2 Posters 16.2k 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.
    • iorxI
      iorx
      last edited by

      I've got this set up.

      WAN office (10.12.88.0/24): Tomato 1.22vpn2.0005
      Central Office (192.168.180.0/24): pf latest 1.2.1-RC4 built on Tue Dec 16 00:17:48 EST 2008

      fpSense OpenVPN server:
      Address pool: 10.11.0.0/24
      Local Network: 192.168.180.0/24
      Client-to-client VPN: Off
      Authentication method: PKI
      Custom Option: route 10.12.88.0 255.255.255.0;route 192.168.180.0 255.255.255.0;push "redirect-gateway"

      Tomato:
      OpenVPN: Create NAT tunnel: Off
      DNSMASQ: dhcp-option=6,192.168.180.31 (DNS server at the main office)

      Works:
      Client machines behind Tomato (10.12.88.x) connect beautifully to the LAN and all resources inside the LAN.
      Server and Client machines has no trouble reaching machines behind the Tomato (10.12.88.x).

      But…

      As I send the push "redirect-gateway" to the OpenVPN client (Tomato router) all traffic from the client is pushed down the OpenVPN-pipe. That includes things which should go out/in on the internet.

      This is where I'm stuck. I can't figure out how to make the traffic from 10.12.88.x to be let through out on the internet.

      Is it possible?

      Tests from a client machine behind 10.12.88.0/24

      tracert -d 62.119.189.4
      1  10.12.88.1
      2  10.11.0.1
      3  *

      pf; I've got a LAN rule like this:
      ALLOW
      Source: LanNetworks (which is an alias for all LAN-addresses e.g 192.168.180.0/24 + 10.12.88.0/24 + 10.11.0.0/24. I've also tried separate rules with address hard coded on the rule)
      Destination: *
      Port: *
      Gateway: *

      And a WAN rule which let in 1194 UDP.

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

        Create an AoN rule.
        http://forum.pfsense.org/index.php/topic,7001.0.html
        (the red part)

        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
        • iorxI
          iorx
          last edited by

          Thank you!

          That solved that issue. And I who thought that I searched thoroughly on the subject…

          Now when that is resolved I got a chance to test the connection.

          Performance! Or should I say the lack of it... :-)
          Internet: I get around 7Kbit/s downloading from the internet through the tunnel. pfSense is on a 10Mbit connection and the remote office is connected on a ADSL 20down/3up-Mbit connection.

          LAN: Windows File copy from main office. This gets an average speed of 1,5-2Mbit

          The solutions pfSense is in the works replacing, a Windows 2000 machine with OpenVPN and Kerio Firewall, was letting through about 2-2,5Mbit/s (max what the wrt54gl hardware allow with OpenVPN i think).

          Any possibilities to improve things here a little bit? :-)

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

            hmm. not sure where the problem lies.
            What transport protocol are you using?
            You should use UDP since TCP can be problematic and should only be used if you HAVE to use it.

            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
            • iorxI
              iorx
              last edited by

              There was something fishy with the connection yesterday (or a couple of hours ago). Did a new test (tptest here in sweden, www.bredbandskollen.se). And I can only say one thing. Whoho! Throughput this time is way over my expectations.

              I had to verify it a couple of time and really check that the traffic went through the tunnel. And it did.

              avg 4Mbit up, top 5.2Mbit/s (which is a bit strange because the uplink is only 3Mbit/s. Compression?)
              avg 4Mbit/s down, top 4.3Mbit/s

              Windows file copy: 58MB PPT-file, ~500Kbyte/s (Vista copy speed indicator showed 524Kbyte/s)
              Windows file copy to server: same file as above. 250Kbyte/s (expected I suppose; wrt54gl router does the all the compression and encryption. Or the uplink speed…)

              Now we're talking! Not bad for a tomato flashed wrt54gl (233Mhz; a little bit tweaked from standard 200Mhz)

              1 Reply Last reply Reply Quote 0
              • iorxI
                iorx
                last edited by

                Forgot to answer you on the protocol used: UDP

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

                  How are you testing this?
                  With iperf? I had similar experiences that sometimes i got 2Mbit upstream on a 512kbit line….
                  Though i havent had the time to investigate further.

                  But 500 Kbyte/s on windows is pretty much 4Mbit which seems strange on a 3Mbit line.
                  So yeah there is probably some compressing going on.

                  If you hit the CPU-max while doing the transfers you could try to use a different encryption for the tunnel.
                  Maybe something less CPU intensive.

                  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
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.