Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 1 subscriber
  • Views 3141 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

Windows XP client L2TP with PSK madness

paulkmoore
Hi

Can anybody please help?  

Am a relative newbie to VPN and am struggling...

I have setup an Astaro firewall mainly for VPN use and am trying to connect from a standard Windows XP client using PSK (this should be simple?)

The config is:


RoadWarrior client (192.168.123.xxx)
|
ADSL router (81.137.180.xxx)
|
Internet
|
ADSL router (81.174.248.xxx)
|
ASL eth0 (192.168.0.xxx)


I have setup the virtual pool with the appropriate PSK under the VPN Connections menu.  

I have setup the client as per the L2TP roadwarrior instructions, discovered about the "uncheck" security box, patched the client with the NAT-T patch and still can't get it to work.

I have been able to connect from outside the firewall (but inside the router) using an address in the 192.168.0.0/24 range, so it seems to be basically working.  

However when connecting from the Roadwarrior at the remote location the IPSec negotiation doesn't succeed and I can't for the life of me find out why (despite trawling the posts here for more hours than I care to think about)

I have looked in the ipsec.log, it detects that both sides are NATed:

2004:09:29-19:17:28 host pluto[2667]: "S_WindowsRemote_1"[158] 81.137.180.xxx #99: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are NATed

but then gives me the following error:

2004:09:29-19:17:28 host pluto[2667]: "S_WindowsRemote_1"[159] 81.137.180.xxx:64421 #99: sent MR3, ISAKMP SA established
2004:09:29-19:17:28 host pluto[2667]: "S_WindowsRemote_1"[159] 81.137.180.xxx:64421 #99: cannot respond to IPsec SA request because no connection is known for 81.174.248.xxx/32===192.168.0.xxx:4500:17/1701...81.137.180.xxx:64421[]:17/%any{}

I have seen lots of posts about left/right config and subnets and wonder if this is what I am experiencing?  Or is it something to do with the NAT traversal.

Eitherway the only way to fix seems to be to hand crank ipsec.conf which I am reluctant to do unless really required.

Any help really, really appreciated.  It's driving me nuts

Thanks

Paul [:S]


This thread was automatically locked due to age.
  • 0 in reply to paulkmoore
    Oh, sorry, didn't catch the whole "combined unit" part.
    OK. Well, did you try the DMZ part I suggested. Also, is IPSEC passthrough enabled?
  • 0 in reply to JimmyM
    I don't have any options to enable IPSec passthrough.  I have verified that the model supports VPN pass through and others have claimed success with it so I think it's OK.

    I believe am getting further than this though.  The initial PSK key exchange is working successfully (if I provide a wrong key I see an earlier failure).

    The ASL is configured to be in the DMZ.  I have tried this with no other rulebase on the Netgear, all open (outbound and inbound) and the packet problem is still the same. 

    Could it be a problem with the client end router and it's support for VPN pass through (which I haven't successfully verified).

    I didn't understand your comment about packets on the "inside of the internet" being forwarded????

    Interestingly (?) I see other packets from the router ext address in the packetfilter.log as drops.  But presumably everything coming from the router to the ASL should be from it's internal (gateway) address.

    It's very strange.

    Thanks

    Paul
  • 0 in reply to paulkmoore
    Yeah, that is a little odd. Can you connect your client to the internet directly via dialup or something to remove the client end router from the equation.
  • 0 in reply to JimmyM
    OK, have tried the client as a direct dial-up.  The logs indicate that only the ASL side is detected as NATed (correctly).  The negotiation fails at exactly the same point.  Now convinced that this is something server side.

    Thoughts?

    Paul
Cookie Information Banner