Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 1 subscriber
  • Views 3139 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.
Parents
  • 0
    Is your DSL router at the VPN server end forwarding port 4500 to the external interface of your ASL box?
  • 0 in reply to JimmyM
    Hi Jim. Thanks for the response.

    In answer to the question, yes.

    I have configured the Router (Netgear DG824M) so that the ASL exists in the DMZ.  In this way all traffic that is not explicitly routed (elsewhere) goes to the external interface of the ASL.  The only ports I'm not forwarding are http and https.

    Thanks

    Paul
  • 0 in reply to paulkmoore
    Try getting rid of your router first of all. Your remote L2TP client addresses your VPN server by it's internet exposed address (router external) not the external IP of ASL. Your router is doing NAT. It's NATing all outbound traffic from inside to the internet and then forwarding all incoming requests to your DMZ set up address (ASL external).

    Get rid of the router and give it another try.
  • 0 in reply to JimmyM
    Hmmm.  It's a combined ADSL/router/firewall so if I get rid of it I will have little in the way of internet connectivity.  There are reports of this device working.  If I need to "remove the router" i'd have to buy a new DSL model - not ideal.

    Thanks

    Paul
  • 0 in reply to paulkmoore
    ASL can perform all of the services that the DSL router does in terms of connecting you to the internet. PPPoE right?
  • 0 in reply to JimmyM
    PPPoA (ATM).

    I can't just connect an ethernet NIC to the DSL wall termination - I need an ADSL modem to broker the traffic to Ethernet don't I?
  • 0 in reply to paulkmoore
    That's right. You need the DSL modem not a modem AND a router.
    Run an ethernet patch cord between the RJ-45 port on your DSL modem to the external NIC on your ASL machine.
  • 0 in reply to JimmyM
    As noted before it's a combined unit.  I can't sever the router from the modem - unless I get the souldering iron out!
  • 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
Reply
  • 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
Children
No Data
Cookie Information Banner