Help Us Test L2TP PSK For Android!

Hi everyone,

With the amount of Android devices out there, we are looking to accommodate the L2TP over IPSec VPN capabilities of these users. TLDR: Android asks for Plain Chap authentication and Astaro at the moment says "nope'.

Rather than develop support in ASG for plain chap, another solution which brings the feature available much sooner is to have ASG just respond with "no, but give me ChapV2" which most Android devices can actually do just fine. Also we don't want to have anyone need to root their phone or do complex operations.  However rather than just say you MUST have android 2.3 and on a "new"  phone, we'd like to know the results others have on various hardware and  android-version combinations.

The solution is quite easy to "test".
On ASG
1) enable and configure L2TP in Webadmin the way you want it
2) login to ASG as root and go to /var/chroot-ipsec/etc/ppp
3) edit (joe or pico) "options" (if you havent enabled l2tp in webadmin yet this file wont exist, just a defaults file, see step 1).
4) at the bottom of the file, add the line "require-mschap-v2" (no quotes, no caps).
5) save the file
6) *OPTIONAL* restart IPSec service (warning will disconnect site-site tunnels and connected roadwarriors!) /var/mdw/scripts/ipsec-starter restart) optional because PPP options get applied during L2TP client reconnect, but if you notice weird log entry spam or oddities it might help.

On your Android Phone:
1) make an L2TP over IPSec with PSK connection to your ASG. (eg. Settings-->Wireless and network-->VPN Settings--"Add VPN")
*note that enable L2TP secret should be left blank!

Now connect. You should get a tunnel. Let us know how you did, and if this affects anything else like other L2TP tunnels which were working fine, or any abnormalities. If a tunnel wont connect, please give us a snippet of the ipsec.log (preferably with debug options from the advanced tab in ASG enabled). 

**Remember** if you cause ASG to rewrite the options file (by say making a change to L2TP in WebAdmin) you need to re-add that line to the options file again. Please double check that your addition is still there to the options file before claiming it doesn't work. A few testers have made this mistake already. You can also add the line to options-default. This way it stays if mdw rewrites the options file, but then is more permanent, which you might not want to "test" with.

Anything we can do to help? Let us know! We will look to add this for 8.200 if it looks promising without any big downfalls perhaps.
Parents Reply Children
  • Hello,

    I had managed to set up a VPN connection with my Android Tablet using L2TP/IPSec previously. The initial problem was how the password was being sent over (chap/md5). This issue was fixed, and VPN worked for a while, but now I am faced with another problem.

    When connecting, I get as far as #78: IPsec SA established {ESP=>0x04e19e67 

    2011:07:20-11:55:27 ASTARO pluto[4950]: packet from 74.X.X.X:49046: received Vendor ID payload [RFC 3947] 
    2011:07:20-11:55:27 ASTARO pluto[4950]: packet from 74.X.X.X:49046: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] 
    2011:07:20-11:55:27 ASTARO pluto[4950]: packet from 74.X.X.X:49046: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] 
    2011:07:20-11:55:27 ASTARO pluto[4950]: packet from 74.X.X.X:49046: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00] 
    2011:07:20-11:55:27 ASTARO pluto[4950]: packet from 74.X.X.X:49046: ignoring Vendor ID payload [FRAGMENTATION 80000000] 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[55] 74.X.X.X:49046 #75: responding to Main Mode from unknown peer 74.X.X.X:49046 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[55] 74.X.X.X:49046 #75: NAT-Traversal: Result using RFC 3947: peer is NATed 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[55] 74.X.X.X:49046 #75: Peer ID is ID_IPV4_ADDR: '192.168.19.6' 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[56] 74.X.X.X:49046 #75: deleting connection "S_REF_ItiSrGkIxh" instance with peer 74.X.X.X {isakmp=#0/ipsec=#0} 
    2011:07:20-11:55:27 ASTARO pluto[4950]: | NAT-T: new mapping 74.X.X.X:49046/60984) 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[56] 74.X.X.X:60984 #75: sent MR3, ISAKMP SA established 
    2011:07:20-11:55:27 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[56] 74.X.X.X:60984 #75: ignoring informational payload, type IPSEC_INITIAL_CONTACT 
    2011:07:20-11:55:29 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #76: responding to Quick Mode 
    2011:07:20-11:55:29 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #76: IPsec SA established {ESP=>0x02b1171b 


    After running this test, I went for lunch and found this additional log information:


    2011:07:20-12:50:59 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #89: initiating Quick Mode PSK+ENCRYPT+DONTREKEY to replace #76 {using isakmp#75} 
    2011:07:20-12:52:09 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #89: max number of retransmissions (2) reached STATE_QUICK_I1 
    2011:07:20-12:52:09 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #89: starting keying attempt 2 of at most 3 
    2011:07:20-12:52:09 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #90: initiating Quick Mode PSK+ENCRYPT+DONTREKEY to replace #89 {using isakmp#75} 
    2011:07:20-12:53:19 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #90: max number of retransmissions (2) reached STATE_QUICK_I1 
    2011:07:20-12:53:19 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #90: starting keying attempt 3 of at most 3 
    2011:07:20-12:53:19 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #91: initiating Quick Mode PSK+ENCRYPT+DONTREKEY to replace #90 {using isakmp#75} 
    2011:07:20-12:54:29 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #91: max number of retransmissions (2) reached STATE_QUICK_I1 
    2011:07:20-12:55:29 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984 #76: IPsec SA expired (--dontrekey) 
    2011:07:20-12:55:29 ASTARO pluto[4950]: "S_REF_ItiSrGkIxh"[19] 74.X.X.X:60984: deleting connection "S_REF_ItiSrGkIxh" instance with peer 74.X.X.X {isakmp=#0/ipsec=#0}


    As you can see, this is almost a fill hour after the initial connection request.

    Does anybody have idea what is happening? I doubt Astaro is the faulting party since I am able to connect from other devices. This issue seems to have creeped up after some updates from android (probably 3.1 update for Honeycomb).
  • I upgraded from 8.103 to the final 8.200, and I am trying to get the vpn working.
    My android phone is  Samsung Galaxy S II running android 2.3.3

    It does not connect and give no specific error on the android side,

    in the logs I can see:

    2011:07:21-21:31:20 plasmashield pluto[7488]: packet from 216.218.29.142:59900: received Vendor ID payload [RFC 3947]
    
    2011:07:21-21:31:20 plasmashield pluto[7488]: packet from 216.218.29.142:59900: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2011:07:21-21:31:20 plasmashield pluto[7488]: packet from 216.218.29.142:59900: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2011:07:21-21:31:20 plasmashield pluto[7488]: packet from 216.218.29.142:59900: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2011:07:21-21:31:20 plasmashield pluto[7488]: packet from 216.218.29.142:59900: ignoring Vendor ID payload [FRAGMENTATION 80000000]
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[3] 216.218.29.142:59900 #3: responding to Main Mode from unknown peer 216.218.29.142:59900
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[3] 216.218.29.142:59900 #3: NAT-Traversal: Result using RFC 3947: peer is NATed
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[3] 216.218.29.142:59900 #3: Peer ID is ID_IPV4_ADDR: '10.156.130.142'
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[4] 216.218.29.142:59900 #3: deleting connection "S_for Charles"[3] instance with peer 216.218.29.142 {isakmp=#0/ipsec=#0}
    2011:07:21-21:31:20 plasmashield pluto[7488]: | NAT-T: new mapping 216.218.29.142:59900/53937)
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[4] 216.218.29.142:53937 #3: sent MR3, ISAKMP SA established
    2011:07:21-21:31:20 plasmashield pluto[7488]: "S_for Charles"[4] 216.218.29.142:53937 #3: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2011:07:21-21:31:21 plasmashield pluto[7488]: "S_for Charles"[1] 216.218.29.142:53937 #4: responding to Quick Mode
    2011:07:21-21:31:21 plasmashield pluto[7488]: "S_for Charles"[1] 216.218.29.142:53937 #4: IPsec SA established {ESP=>0x077b67a1 
  • Looks like a lot of people get stuck at:
     IPsec SA established {ESP=>0x02b1171b