Bekijk de volledige versie : 500g, PPTP issues
Could somebody help me to understand what this nice grey box with Linux inside whats to tell? Part of Syslog attached.
Connection details:
- Internet access through VPN-tunnel (Russia)
- MAC-address cloned with ASUS box
- Static IP address 10.13.1.24
- Gateway and VPN-server address 10.0.0.2
- DNS 85.93.128.2 and 85.93.129.2
First come observations:
- WAN LED blinking quickly like hell
- Data transmitted from 500g amounts 10 MB per about 1 min (as syslog says)
- Ping from LAN PC to ISP gateway fails
- Ping from 500g to ISP gateway using telnet gives 70% loss
As long as PPTP connection between 500g and my ISP is not established yet, I think it would be good idea to inform everybody about further progress.
At the very begining there was an error which arose just after CHAP authentication
Jan 1 03:02:24 pppd[81]: CHAP authentication succeeded: Welcome!!
Jan 1 03:02:24 kernel: mppe_decomp_alloc: options rejected: o[0]=12, o[1]=06, o[2]=00, o[3]=00, o[4]=00, o[5]=00
Jan 1 03:02:24 pppd[81]: Received bad configure-ack:
Thanks to Oleg these two bad lines left syslog. He suggested adding nomppe nomppc parameters in field Additional pppd options on page IP Config | WAN & LAN.
After all very designing part of syslog looks like lines in attached file. Most interesting is the amount of data which 500g sends to ISP without any PC connected to it from LAN side.
Jan 1 03:05:52 pppd[81]: Connection terminated.
Jan 1 03:05:52 pppd[81]: Connect time 1.2 minutes.
Jan 1 03:05:52 pppd[81]: Sent 10476658 bytes, received 70 bytes.
On of this forum guru, Kitsok supposed all VPN traffic, control and data, redirected to tunnel. And therefore some additional routes and rules should be added somewhere in 500g.
Tomorrow I'll get my 500g from ISP test lab, where now IT-guys try to make it works with their VPN-server. I hope they will take a win :)
Anyway, all suggestions are welcome.
Most likely, nomppe and nomppc options will not be needed. For me the only line, which could cause problem is
Jan 1 03:04:41 pppd[81]: remote IP address 10.0.0.2
It seems to me, that they need to return external address instead of the internal address of their PPTP server, although I'm not sure.
It seems to me, that they need to return external address instead of the internal address of their PPTP server, although I'm not sure.
Sure, looks like complete mess with external and internal IP
Jan 1 03:04:41 pppd[81]: local IP address 85.93.136.163
Jan 1 03:04:41 pppd[81]: remote IP address 10.0.0.2
Above local is my external to the Internet, and remote is GW/VPN server address.
By the way, very nice resource PPPD manual (http://www.routerlinux.com/docs/manual/man8/pppd.8.html), especially section
ROUTING
When IPCP negotiation is completed successfully, pppd will inform the kernel of the local and remote IP addresses for the ppp interface. This is sufficient to create a host route to the remote end of the link, which will enable the peers to exchange IP packets. Communication with other machines generally requires further modification to routing tables and/or ARP (Address Resolution Protocol) tables. In most cases the defaultroute and/or proxyarp options are sufficient for this, but in some cases further intervention is required. The /etc/ppp/ip-up script can be used for this.
Sometimes it is desirable to add a default route through the remote host, as in the case of a machine whose only connection to the Internet is through the ppp interface. The defaultroute option causes pppd to create such a default route when IPCP comes up, and delete it when the link is terminated.
In some cases it is desirable to use proxy ARP, for example on a server machine connected to a LAN, in order to allow other hosts to communicate with the remote host. The proxyarp option causes pppd to look for a network interface on the same subnet as the remote host (an interface supporting broadcast and ARP, which is up and not a point-to-point or loopback interface). If found, pppd creates a permanent, published ARP entry with the IP address of the remote host and the hardware address of the network interface found.
When the demand option is used, the interface IP addresses have already been set at the point when IPCP comes up. If pppd has not been able to negotiate the same addresses that it used to configure the interface (for example when the peer is an ISP that uses dynamic IP address assignment), pppd has to change the interface IP addresses to the negotiated addresses. This may disrupt existing connections, and the use of demand dialling with peers that do dynamic IP address assignment is not recommended.
IT-guys from ISP test lab are still fighting with daemon of PPPD ;) inside my router and their VPN server. They told me server log is full with router attempts to establish certain type of encryption. Don't ask me what they meant :D
ISP howto web page about setting up VPN tunnel in Microsoft Windows contains important step regarding encryption. By default option Encryption required (otherwise disconnect) in Security tab of VPN connection properties window is enabled. ISP requires this option to be set disabled.
As far as I can join two above points there is a chance that router's VPN client (i.e. PPPD) by default is set up the same way as MS Windows client. And to become broadband happy I have to override this default setting.
Could somebody tell me the name of this magic PPPD option? I'll immediately input this word in Additional pppd options field. :)
well, the answer is nomppe, but the problem is with routing as seems.
...the problem is with routing as seems.
While I've been waiting for feedback from ISP side (with my router as well), Google brings another good page about routing Routing HOWTO (http://pptpclient.sourceforge.net/routing.phtml).
All stories should have their happy end :)
At long last I brought my router at home with ISP conclusion - this ASUS box would not be able to interact with their VPN server. And sticking point was disabling PPTP encryption in router VPN client.
You have already seen in previous posts how Oleg recommended to solve above stickiness. Just adding nomppe nomppc options did really work and switched VPN tunnel encryption off.
Second Oleg's step was as geniusly simple as the first one. It seemed 500g tried unsuccessfully to encapsulate itself, i.e. put in a single route data and control stream - probably Oleg will give us more scientifically correct explanation :) In telnet session I enetered
route add -host 10.0.0.2 dev eth1
and PPTP tunnel immediately poped up.
Sequential changings in 500g routes are as follows:
From scratch
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 br0
10.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
Command entered
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 br0
10.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
PPTP connection established
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
10.0.0.2 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 br0
10.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 10.0.0.2 0.0.0.0 UG 40 0 0 ppp0
So, through the next steps I had to make route to 10.0.0.2 permanent. There was simple way (too simple for *nix expert like me :) ) to do it using post-boot script. Oleg pointed out undocumented feature in 1.9.2.7-4 firmware, and I left Default gateway field empty and typed gateway IP address in Heartbeat server field. Then my heart begun to beat much quicker :D because I've got connection to ISP without telnet workarounds!
Great final, many thanks to Oleg!
Would this also work to setup a permanent VPN connection to my work?
In order to use Outlook at home, the VPN connection is needed. Also, one of our customers only gives access to their LAN to a specific IP address range (my work's and so not my IP at home). I have an "always on" connection with my ISP and what I would like to achieve is to transfer only the necessary traffic through the VPN if it concerns Outlook data or transfers to/from the customer. Can this be done?
/update
I entered the same command via telnet, but the pptp does not come up :(