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).

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

  • Thank you for answer, but it don't solve my problem. – Alex. A Jan 11 at 17:41

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.