Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 1 subscriber
  • Views 24554 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[SOLVED] Vista/Win7 L2TP over IPSec Connection Issues

jshockley
Ok gang, I am feeling like a total noob right now. I have my Astaro up on v8.001 and things are going great for the most part. One thing I never could get going on v7 was L2TP over IPSec. So, I have decided to look at this again and my head is hurting from it hitting the wall so many times right now.

Let's start with my Astaro configuration:
l2tpconfig.JPG
As you can see, I am using my External interface with PSK and assigning address from the pool. I have pull my RAS group out and put my credentials in only.

I have set advanced RAS details used by my PPTP and SSL VPN connections as well.

Here is my Windows 7 configuration:
win7l2tp.JPG

Here is the log file I have seen when I tried to connect to my Astaro via L2TP: 
2010:08:19-16:05:12 asg pluto[7825]: | 

2010:08:19-16:05:12 asg pluto[7825]: | *received 384 bytes from 96.253.145.114:879 on eth0

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [RFC 3947]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [FRAGMENTATION]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [Vid-Initial-Contact]

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: ignoring Vendor ID payload [IKE CGA version 1]

2010:08:19-16:05:12 asg pluto[7825]: | preparse_isakmp_policy: peer requests PSK authentication

2010:08:19-16:05:12 asg pluto[7825]: packet from 96.0.0.114:879: initial Main Mode message received on 74.0.0.145:500 but no connection has been authorized with policy=PSK

2010:08:19-16:05:12 asg pluto[7825]: | next event EVENT_REINIT_SECRET in 3116 seconds


I see connection but the second to last line in the log says "initial Main Mode message received ... but no connection has been authorized with policy=PSK".

Any thoughts? I am loving the learning I am doing on the Astaro products and really do appreciate the help you all give us junior members.

*ponders if he can change his title in the Forum to "complete n00b"*

Jared


This thread was automatically locked due to age.
Parents
  • 0
    Well, one of my customers came up with this issue.  I searched pretty hard here and all over with Google for L2TP Win 7 and for L2TP Vista and especially:

    IPSec Transform [NULL (0), HMAC_SHA1] refused due to insecure key_len and enc. alg. not listed in "esp" string


    - but, I found nix, zero, nada that would solve the problem.  I finally logically eliminated everything except the 'Data encryption' setting on the 'Security' tab of the 'VPN Connection Properties'...

    In XP, you must disable 'Require data encryption (disconnect if none)'.  In Vista/Win7, do not select 'No encryption allowed (server will disconnect even if it requires encryption)' - you must select one of the other choices that allows/requires encryption.

    Badabingbadaboom!

    Cheers - Bob
  • 0 in reply to BAlfson
    Bob,

    The secret here is the error being received.  If you required some kind of encryption in the OS, but the tunnel is only using SHA for authentication and ESP payload is NULL then it isn't going to satisfy that encryption requirement.

    With these parameters, the tunneling works just like a normal tunnel, but anyone with a packet sniffer can see the traffic within.  Also, since there is no encryption your PSK would also be forfeit.

    Really don't recommend running it like this unless you're just doing this to make sure all ports are open between source and destination by use of tunnel.

    Chris
Reply
  • 0 in reply to BAlfson
    Bob,

    The secret here is the error being received.  If you required some kind of encryption in the OS, but the tunnel is only using SHA for authentication and ESP payload is NULL then it isn't going to satisfy that encryption requirement.

    With these parameters, the tunneling works just like a normal tunnel, but anyone with a packet sniffer can see the traffic within.  Also, since there is no encryption your PSK would also be forfeit.

    Really don't recommend running it like this unless you're just doing this to make sure all ports are open between source and destination by use of tunnel.

    Chris
Children
No Data