Custom firmware: can't access Inet via VPN

[Posader]

Hi everyone!

This forum is a great storage for valuable experience and information, and I used to take advantage of it for quite a while already. However now it is time to beg for your help because I am really stuck. :( Here's my story...

I bought a WL500g thing quite a time ago and configured it the way it served as a simple gateway to my tiny home network. My ISP provides me with Internet access through VPN (NT server with MSCHAP+MPPE). And since the ASUS thing lacks support for this kind of PPTP connection I had to access the Inet from one computer at a time (my ISP blocks more than one VPN connection from the same IP). To make things worse, I had very weak experience with *nix systems, so I just waited for a suitable firmware from the ASUS guys, which I hoped had been planned for sure. Communications with them shed no light to when the problem with VPN would be fixed. I downloaded the sources and planned to dig into the code when I have enough time.

Then I discovered this site and found out that there was really no support for MSCHAP and MPPE/MPPC. I added MS VirtualPC to my XP box and installed the KNOPPIX 3.7 distribution (btw, VMWare sucked at that point as I tried it first). I installed the latest sources from ASUS (1.9.2.7) and patched it with Oleg's custom sources (1.9.2.7-2) (Oleg, great job!!!). Close inspection revealed absence of so badly required MSCHAP+MPPE/MPPC, so the latest PPPD with all that stuff was added. Kernel and PPPD patches (which add MPPE/MPPC support) were also installed.

Once compiled and uploaded, this custom stuff in fact established a connection with my provider, and I was able to PING everyone around the Inet side from the router shell session. But I was not able to connect to Internet sites from my XP box (internal network). I even put "1" to ip_forward and re-built the kernel with advanced routing turned on. Nothing changed. IPTABLES were flushed, and ACCEPT any/any/any rules were inserted in all chains (both filtering and mangle tables - I just had no idea what else to do). This also had no success. The routing table was modified by PPPD automatically.

So now I am stuck with the following configuration:
1. ASUS running a working VPN connection at ppp0. I can browse Internet sites from my ASUS box.
2. XP box located in internel LAN (connected directly to LAN1 port) - br0.

What I can do:
1. Telnet to ASUS from XP box.
2. PING and connect to servers located in WAN (eth1) (my neighbours) from XP box.
3. Establish a VPN connection from the ASUS with my ISP's VPN server (which is also in WAN).
4. Connect to sites in Internet via ppp0 from within ASUS (in telnet session, for instance).
5. But I cannot connect to Internet sites (by their IP addresses) from my XP box - packets just get lost somewhere.
6. I can ping ASUS' external ppp0 IP address from XP. But I cannot ping the ppp0 gateway (ISP's server through ppp0) from XP.

I know that packets get lost somewhere in the ASUS. The routing table is OK, IPTABLES accept everything. And I just have no idea what to check next... (thinking of libpcap and tcpdump :((() :( I am not a Linux guy.

Guys, I am not asking to solve my problem, just give me a hint... Please...

[Oleg]

You've done a big job. ;) The problem is probably missing masquarading or tcp mss setting.
How you've configured your connection (I mean WAN connection type)? Is it PPTP?
Anyway, I've added MSCHAP and MSCHAP v2 support to the 1.9.2.7-3 firmware, probably MPPE could also be added.

[Posader]

Thanks, Oleg. :)
The WAN is configured as Static IP, because I have similar routing problems with WAN sites when PPTP is set (I cannot even access WAN sites from XP box - this works pretty fine with Static IP. The same messing with IPTABLES and the routing table brought no effect).
I have NAT turned off. I will check the masquerading feature, thanks.
I saw your firmware (1.9.2.7-3) but had no time to add MPPE and recompile it yet. I suspect I will face the same troubles there so I keep kicking the code with working VPN. :)

[Oleg]

Well, you need to turn NAT on, otherwise nodes on the outside will not be able to send data back (because they have no idea of your LAN IPs).

[Posader]

Exactly, silly me. Thank you, Oleg! I added a new masquerading rule and it worked. :)
Now I will integrate MPPE in your latest firmware. New Year holidays were not wasted indeed.

[Oleg]

Ok, let me know, when you complete this. I'm interesting in integrating this to the firmware.

[Posader]

OK, Oleg, I will do it within the next few days.

[Oleg]

Could you please try using 1.9.2.7-3b? I've added MPPE support to it.

[Posader]

OK, I will give it a try tomorrow. BTW, I merged the stuff into your 1.9.2.7-3a but haven't overcome some strange pppd behaviour yet, therefore I did not send the diffs to you. :(

[Oleg]

3b contains older ppp, which works reliable.

[Posader]

I tried 3b and it worked fine, thank you, Oleg! I just had to remove 'noccp' and add 'refuse-eap' in order to be able to connect to my ISP.
Though I witnessed the following behavior (in my customization it was present too): once a PPP connection gets lost, the pppd tries to reconnect due to 'persist' option, it's ok. However, two new processes get spawned: 'sh -c /usr/sbin/pptp ...' and '/usr/sbin/pptp'. If a new reconnection is required, two new processes appear in the list. There are two bad things about it: 1) reconnection does not succeed. 2) Killing a pptp process (when there are many) results in system restart.
So I guess I have to customize an ip-down operation to kill unnecessary pptp processes (or even additionally kill the existing pppd and start a new pppd afterwards).
The second problem which I did not thoroughly analyze is that I am not able to establish either an HTTP connection to www.microsoft.com, or connect through MSN messenger. Many other sites work ok. My understanding is that something is wrong with my iptables rules, but I haven’t had time for that yet.

[Oleg]

I tried 3b and it worked fine, thank you, Oleg! I just had to remove 'noccp' and add 'refuse-eap' in order to be able to connect to my ISP.

Ok, I will remove noccp and add refuse-eap - it does not make any sense for other things.


Though I witnessed the following behavior (in my customization it was present too): once a PPP connection gets lost, the pppd tries to reconnect due to 'persist' option, it's ok. However, two new processes get spawned: 'sh -c /usr/sbin/pptp ...' and '/usr/sbin/pptp'. If a new reconnection is required, two new processes appear in the list.

Well, yes, this is how things should work - looks like failed pptp has not exited for some reason... We need to investigate on this - either pptp-client should be replaced or fixed.


There are two bad things about it: 1) reconnection does not succeed.

This is probably due to the existing connection, made by still alive pptp.


2) Killing a pptp process (when there are many) results in system restart.

Hm... This should not result in this... Looks like a bug...


So I guess I have to customize an ip-down operation to kill unnecessary pptp processes (or even additionally kill the existing pppd and start a new pppd afterwards).

Well, for me this looks like a hack - try to fix pptp instead, it should exit once connection is dropped, as seems to me.


The second problem which I did not thoroughly analyze is that I am not able to establish either an HTTP connection to www.microsoft.com, or connect through MSN messenger. Many other sites work ok. My understanding is that something is wrong with my iptables rules, but I haven’t had time for that yet.
Most likely this is MSS problem. Try launching this command and let me know if it works:



iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452

[Posader]

Thank you, Oleg, I got your idea. Could you please add 'nomppe-stateful' as well? It seems like stateful is bad enough as any synchronization loss breaks the connection.
Microsoft is still not accessible, but I will play more with iptables.

[Posader]

I tried setting mss to 999 (just on testing purposes) and it worked. Thank you, Oleg! MSN is functional as well.

[Posader]

I downloaded fresh sources of pptp-client 1.5.0 and compiled them. A nice thing is that the stripped executable took only 80K instead of 180K of the original 1.1.1 one. And it really ran great, no reboots, no hangs, correct reconnection, and no parasite process spawning.
Oleg, I strongly recommend to include the new version in the firmware. :)

[Oleg]

Ok, will do. Please check your PM.