Announcement

Collapse
No announcement yet.

Redirect traffic in OpenVPN

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Wow, the Hilton...Not a bad choice. Yeah, I reckon the problem is not the main airports (Beijing, Shanghai), but the smaller ones, that for some reason won´t take a 5min delay and reschedule your flight 2h later. So from the plane they always remember to blame the destination´s airport traffic control. Regarding your picture, actually Chengdu this time looked close enough to that. Happily we also took a trip to Jiuzhaigou, to breath some good fresh air and to freeze ourselves a little bit.

    Anyway. It´s been a whole week, with the VPN successfully working all the time without a hitch. It still won´t come up on it´s own after a reboot, but that was a minor issue, as SSH also worked fine and could remotely bring it up. Sometimes it was rather slow, but I blame here the ****ty connection we had there. It was otherwise a very good experience. Thank you so much man!
    Last edited by timonoj; Feb 17, 2013, 07:45 AM.

    Comment


      #17
      I have a similar requirement. Can you please guide me how to do this??

      Comment


        #18
        I have a similar need, can you please guide me how to do this. Here's my scenario



        Also is it possible too reach my Home PC (192.168.1.30) using the same tunnel, or a separate tunnel would be required.

        Please help

        UPDATE !!!

        Got it working already.
        Last edited by maxsujoy; Dec 11, 2013, 10:47 PM.

        Comment


          #19
          Originally posted by SteveRiley View Post
          I set up an OpenVPN server at home and successfully duplicated your desired scenario.

          Here's a comparison of the sample server configuration (on left) with the one I created (on right):
          Code:
          root@mini2140:~# diff --side-by-side --suppress-common-lines server.conf /etc/openvpn/server.conf 
          cert server.crt                                     | cert mini2140.crt
          key server.key  # This file should be kept secret   | key mini2140.key  # This file should be kept secret
          ;push "redirect-gateway def1 bypass-dhcp"           | push "redirect-gateway def1 bypass-dhcp"
                                                              > push "dhcp-option DNS 4.2.2.1"
          ;client-to-client                                   | client-to-client
          ;tls-auth ta.key 0 # This file is secret            | tls-auth ta.key 0 # This file is secret
          ;user nobody                                        | user nobody
          ;group nogroup                                      | group nogroup
          verb 3                                              | verb 4
          ;mute 20                                            | mute 20
          Of note, I:
          • uncommented the redirect-gateway option so that all connected VPN clients will have their default gateways changed to the local tunnel adapter
          • pushed Verizon's DNS server to the clients. I probably could have used my own but I wanted to eliminate variables from the test
          • allowed client-to-client visibility
          • generated the additional TLS authentication key to protect the logon sequence more strongly
          • reduced the service's permissions
          • increased the logging level and muted log redundancies


          Also of note, I do not have a push route because that is unnecessary when all the resources behind the VPN server are on the same subnet as the VPN server's physical NIC. In my setup, this is indeed the case.

          To get the server to route Internet traffic back to the Internet, the following commands were necessary. Note that I log into my server as root, so I'm not prefacing the commands with sudo.

          Code:
          sysctl -w net.ipv4.ip_forward=1
          iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
          iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
          iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
          These settings will not persist across reboots. To remedy that, first change a sysctl variable to enable always-on IP forwarding. Edit the file /etc/sysctl.conf, find the line containing net.ipv4.ip_forward=1, and remove the comment sign at the beginning of the line.

          Next, install the packge iptables-persistent. This creates the file /etc/iptables/rules.v4 which will always be loaded at startup:
          Code:
          sudo apt-get install iptables-persistent
          Answer yes when asked about IPv4; answer no when asked about IPv6.

          If, at some point in the future, you add more rules to iptables, you'll need to run the package configuration script to update the rules file:
          Code:
          sudo dpkg-reconfigure iptables-persistent
          Finally, reboot your server to make sure everything still works:
          Code:
          sysctl -a | grep net.ipv4.ip_forward
          should show that the variable remains set to 1.
          Code:
          cat /proc/net/ip_tables_names | xargs -L 1 iptables -L -t
          should display the MASQUERADE rule in the POSTROUTING chain in the nat table, and the two ACCEPT rules in the FORWARD chain in the filter table.
          I have a similar need, can you please guide me how to do this. Here's my scenario



          Also is it possible too reach my Home PC (192.168.1.30) using the same tunnel, or a separate tunnel would be required.

          Please help

          UPDATE !!!!

          Got it working already. Thanks....
          Last edited by maxsujoy; Dec 11, 2013, 10:47 PM.

          Comment


            #20
            The steps in my post #8 should be sufficient guidance. Have you tried yet?

            Comment


              #21
              Got it running already..

              Originally posted by SteveRiley View Post
              The steps in my post #8 should be sufficient guidance. Have you tried yet?
              Couldn't wait, I've figured it out already and things are working properly as I needed. Sorry I didn't update it here.

              Comment


                #22
                OK, glad you got it sorted.

                Comment

                Working...
                X