3proxy via pptp-linux VPN

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















Good day. I have a situation: a computer with debian (K) is connected to the router (A), which distributes the network 192.168.1.0/24. There is another router (B) (it has a “white” ip), which distributes the network 172.16.1.0/30, on which the pptp server is running, on which NAT is enabled. The pptp client is installed on the "K", which creates the ppp1 interface with ip 172.16.1.2 (but the mask for some reason / 32 is also on the keenetic ("B") route from / 32 - apparently "to the node"). Connection passes, the ping goes. The problem is the "triangular" route (well, I still think it is). When I connect to "K" (SSH, for example) from network "A", then everything works (eth0 - network "A" - default route). On the router "B" there is nat, forwarding connections from the Internet (to certain ports) to "K". Only in the packages "source" does not change to the one that the router has. However, this would not solve the problem entirely, because "K" has http-proxy, whose task is to send traffic from eth0 to ppp1. In the proxy settings (3proxy) I specified the "input" and "output" ip. Should work, probably, but does not work. The default route to change is not an option, since access to the Internet via eth0 is faster 7 times + another openvpn server is planned on the same computer that will accept connections from ppp1, and create connections via eth0 itself.
Thanks for answers.

ifconfig:



eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
ether 02:02:20:02:47:8f txqueuelen 1000 (Ethernet)
RX packets 5248 bytes 343827 (335.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 512 bytes 54725 (53.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 37

ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1350
inet 172.16.1.2 netmask 255.255.255.255 destination 172.16.1.1
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 8 bytes 118 (118.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 99 (99.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



/etc/3proxy/3proxy.cfg:



setgid 115
setuid 109

#nserver 192.168.1.1
nserver 172.16.1.1

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

#In theory, from this point on, traffic should go through the ppp1 interface.
external 172.16.1.2

internal 192.168.1.20

users $/etc/3proxy/.proxyauth

daemon

log /var/log/3proxy/3proxy.log D
logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

auth cache strong

proxy -n -p8080 -a





And more: DNS traffic sent by 3proxy goes freely (goes and returns) via ppp1 (watched with tcpdump).










share|improve this question


























    1















    Good day. I have a situation: a computer with debian (K) is connected to the router (A), which distributes the network 192.168.1.0/24. There is another router (B) (it has a “white” ip), which distributes the network 172.16.1.0/30, on which the pptp server is running, on which NAT is enabled. The pptp client is installed on the "K", which creates the ppp1 interface with ip 172.16.1.2 (but the mask for some reason / 32 is also on the keenetic ("B") route from / 32 - apparently "to the node"). Connection passes, the ping goes. The problem is the "triangular" route (well, I still think it is). When I connect to "K" (SSH, for example) from network "A", then everything works (eth0 - network "A" - default route). On the router "B" there is nat, forwarding connections from the Internet (to certain ports) to "K". Only in the packages "source" does not change to the one that the router has. However, this would not solve the problem entirely, because "K" has http-proxy, whose task is to send traffic from eth0 to ppp1. In the proxy settings (3proxy) I specified the "input" and "output" ip. Should work, probably, but does not work. The default route to change is not an option, since access to the Internet via eth0 is faster 7 times + another openvpn server is planned on the same computer that will accept connections from ppp1, and create connections via eth0 itself.
    Thanks for answers.

    ifconfig:



    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
    ether 02:02:20:02:47:8f txqueuelen 1000 (Ethernet)
    RX packets 5248 bytes 343827 (335.7 KiB)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 512 bytes 54725 (53.4 KiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    device interrupt 37

    ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1350
    inet 172.16.1.2 netmask 255.255.255.255 destination 172.16.1.1
    ppp txqueuelen 3 (Point-to-Point Protocol)
    RX packets 8 bytes 118 (118.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 8 bytes 99 (99.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



    /etc/3proxy/3proxy.cfg:



    setgid 115
    setuid 109

    #nserver 192.168.1.1
    nserver 172.16.1.1

    nscache 65536

    timeouts 1 5 30 60 180 1800 15 60

    #In theory, from this point on, traffic should go through the ppp1 interface.
    external 172.16.1.2

    internal 192.168.1.20

    users $/etc/3proxy/.proxyauth

    daemon

    log /var/log/3proxy/3proxy.log D
    logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

    auth cache strong

    proxy -n -p8080 -a





    And more: DNS traffic sent by 3proxy goes freely (goes and returns) via ppp1 (watched with tcpdump).










    share|improve this question
























      1












      1








      1








      Good day. I have a situation: a computer with debian (K) is connected to the router (A), which distributes the network 192.168.1.0/24. There is another router (B) (it has a “white” ip), which distributes the network 172.16.1.0/30, on which the pptp server is running, on which NAT is enabled. The pptp client is installed on the "K", which creates the ppp1 interface with ip 172.16.1.2 (but the mask for some reason / 32 is also on the keenetic ("B") route from / 32 - apparently "to the node"). Connection passes, the ping goes. The problem is the "triangular" route (well, I still think it is). When I connect to "K" (SSH, for example) from network "A", then everything works (eth0 - network "A" - default route). On the router "B" there is nat, forwarding connections from the Internet (to certain ports) to "K". Only in the packages "source" does not change to the one that the router has. However, this would not solve the problem entirely, because "K" has http-proxy, whose task is to send traffic from eth0 to ppp1. In the proxy settings (3proxy) I specified the "input" and "output" ip. Should work, probably, but does not work. The default route to change is not an option, since access to the Internet via eth0 is faster 7 times + another openvpn server is planned on the same computer that will accept connections from ppp1, and create connections via eth0 itself.
      Thanks for answers.

      ifconfig:



      eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
      inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
      ether 02:02:20:02:47:8f txqueuelen 1000 (Ethernet)
      RX packets 5248 bytes 343827 (335.7 KiB)
      RX errors 0 dropped 0 overruns 0 frame 0
      TX packets 512 bytes 54725 (53.4 KiB)
      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
      device interrupt 37

      ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1350
      inet 172.16.1.2 netmask 255.255.255.255 destination 172.16.1.1
      ppp txqueuelen 3 (Point-to-Point Protocol)
      RX packets 8 bytes 118 (118.0 B)
      RX errors 0 dropped 0 overruns 0 frame 0
      TX packets 8 bytes 99 (99.0 B)
      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



      /etc/3proxy/3proxy.cfg:



      setgid 115
      setuid 109

      #nserver 192.168.1.1
      nserver 172.16.1.1

      nscache 65536

      timeouts 1 5 30 60 180 1800 15 60

      #In theory, from this point on, traffic should go through the ppp1 interface.
      external 172.16.1.2

      internal 192.168.1.20

      users $/etc/3proxy/.proxyauth

      daemon

      log /var/log/3proxy/3proxy.log D
      logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

      auth cache strong

      proxy -n -p8080 -a





      And more: DNS traffic sent by 3proxy goes freely (goes and returns) via ppp1 (watched with tcpdump).










      share|improve this question














      Good day. I have a situation: a computer with debian (K) is connected to the router (A), which distributes the network 192.168.1.0/24. There is another router (B) (it has a “white” ip), which distributes the network 172.16.1.0/30, on which the pptp server is running, on which NAT is enabled. The pptp client is installed on the "K", which creates the ppp1 interface with ip 172.16.1.2 (but the mask for some reason / 32 is also on the keenetic ("B") route from / 32 - apparently "to the node"). Connection passes, the ping goes. The problem is the "triangular" route (well, I still think it is). When I connect to "K" (SSH, for example) from network "A", then everything works (eth0 - network "A" - default route). On the router "B" there is nat, forwarding connections from the Internet (to certain ports) to "K". Only in the packages "source" does not change to the one that the router has. However, this would not solve the problem entirely, because "K" has http-proxy, whose task is to send traffic from eth0 to ppp1. In the proxy settings (3proxy) I specified the "input" and "output" ip. Should work, probably, but does not work. The default route to change is not an option, since access to the Internet via eth0 is faster 7 times + another openvpn server is planned on the same computer that will accept connections from ppp1, and create connections via eth0 itself.
      Thanks for answers.

      ifconfig:



      eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
      inet 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255
      ether 02:02:20:02:47:8f txqueuelen 1000 (Ethernet)
      RX packets 5248 bytes 343827 (335.7 KiB)
      RX errors 0 dropped 0 overruns 0 frame 0
      TX packets 512 bytes 54725 (53.4 KiB)
      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
      device interrupt 37

      ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1350
      inet 172.16.1.2 netmask 255.255.255.255 destination 172.16.1.1
      ppp txqueuelen 3 (Point-to-Point Protocol)
      RX packets 8 bytes 118 (118.0 B)
      RX errors 0 dropped 0 overruns 0 frame 0
      TX packets 8 bytes 99 (99.0 B)
      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



      /etc/3proxy/3proxy.cfg:



      setgid 115
      setuid 109

      #nserver 192.168.1.1
      nserver 172.16.1.1

      nscache 65536

      timeouts 1 5 30 60 180 1800 15 60

      #In theory, from this point on, traffic should go through the ppp1 interface.
      external 172.16.1.2

      internal 192.168.1.20

      users $/etc/3proxy/.proxyauth

      daemon

      log /var/log/3proxy/3proxy.log D
      logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

      auth cache strong

      proxy -n -p8080 -a





      And more: DNS traffic sent by 3proxy goes freely (goes and returns) via ppp1 (watched with tcpdump).







      debian networking routing vpn http-proxy






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 8 at 18:09









      Александр А.Александр А.

      62




      62




















          1 Answer
          1






          active

          oldest

          votes


















          0














          That is maybe due to the lack of the right module in the proxy; module in charge of "natin" the pptp. Try the following:



          lsmod |grep nf_nat_pptp



          If the module is not there you would have to type:



          modprobe nf_nat_pptp



          echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf



          sysctl -p



          With these changes the pptp traffic should go accross the proxy.



          For enabling the module permanently for future reboots you would have to add it to the modules file by:



          echo 'nf_nat_pptp' >> /etc/modules






          share|improve this answer























          • Thank you for answer, but it don't solve my problem.

            – Александр А.
            Jan 11 at 17:41










          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493296%2f3proxy-via-pptp-linux-vpn%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          That is maybe due to the lack of the right module in the proxy; module in charge of "natin" the pptp. Try the following:



          lsmod |grep nf_nat_pptp



          If the module is not there you would have to type:



          modprobe nf_nat_pptp



          echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf



          sysctl -p



          With these changes the pptp traffic should go accross the proxy.



          For enabling the module permanently for future reboots you would have to add it to the modules file by:



          echo 'nf_nat_pptp' >> /etc/modules






          share|improve this answer























          • Thank you for answer, but it don't solve my problem.

            – Александр А.
            Jan 11 at 17:41















          0














          That is maybe due to the lack of the right module in the proxy; module in charge of "natin" the pptp. Try the following:



          lsmod |grep nf_nat_pptp



          If the module is not there you would have to type:



          modprobe nf_nat_pptp



          echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf



          sysctl -p



          With these changes the pptp traffic should go accross the proxy.



          For enabling the module permanently for future reboots you would have to add it to the modules file by:



          echo 'nf_nat_pptp' >> /etc/modules






          share|improve this answer























          • Thank you for answer, but it don't solve my problem.

            – Александр А.
            Jan 11 at 17:41













          0












          0








          0







          That is maybe due to the lack of the right module in the proxy; module in charge of "natin" the pptp. Try the following:



          lsmod |grep nf_nat_pptp



          If the module is not there you would have to type:



          modprobe nf_nat_pptp



          echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf



          sysctl -p



          With these changes the pptp traffic should go accross the proxy.



          For enabling the module permanently for future reboots you would have to add it to the modules file by:



          echo 'nf_nat_pptp' >> /etc/modules






          share|improve this answer













          That is maybe due to the lack of the right module in the proxy; module in charge of "natin" the pptp. Try the following:



          lsmod |grep nf_nat_pptp



          If the module is not there you would have to type:



          modprobe nf_nat_pptp



          echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf



          sysctl -p



          With these changes the pptp traffic should go accross the proxy.



          For enabling the module permanently for future reboots you would have to add it to the modules file by:



          echo 'nf_nat_pptp' >> /etc/modules







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 8 at 19:53









          DaselDasel

          4497




          4497












          • Thank you for answer, but it don't solve my problem.

            – Александр А.
            Jan 11 at 17:41

















          • Thank you for answer, but it don't solve my problem.

            – Александр А.
            Jan 11 at 17:41
















          Thank you for answer, but it don't solve my problem.

          – Александр А.
          Jan 11 at 17:41





          Thank you for answer, but it don't solve my problem.

          – Александр А.
          Jan 11 at 17:41

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493296%2f3proxy-via-pptp-linux-vpn%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay