D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-130 => Topic started by: blk1948 on October 29, 2008, 09:10:53 PM
-
Other than setting up a Virtual Server using the L2TP application (which opens 1701 for UDP), are there any other Virtual Server entries necessary for a L2TP/IPSEC VPN?
-
Do you want to have this router act as a L2TP over IPsec server?
Or perhaps to pass the traffic to your LAN so a server on your LAN can handle the L2TP over IPsec connections?
Regardless you should not need to pass 1701 UDP as the L2TP connection should be encapsulated inside the IPsec tunnel.
-
I want the router to act as a server. I can connect to it using PPTP but not L2TP/IPSEC. What ports/protocols have to get to the router, how can I check if it is being blocked by my ISP?
-
You will need to be on 1.12 firmware for this to work.
You don't have to do any forwarding in that case.
You then should create an IPsec tunnel, then when you attempt to create your next tunnel it should give you the option of an L2TP over IPsec tunnel.
-
I am on the 1.12 firmware. My home has the DIR-130 router and I'm testing the VPN within my home network. I can connect to the DIR-130 VPN server from any computer at home using PPTP. Similarly, I can connect to the home DIR-130 VPN server from a remote site (through the internet) using PPTP. However, when I try and connect using L2TP/IPSEC (both at home and from remote site), I receive "error 792 -The L2TP connection attempt failed because security negotiation timed out." I'm assuming from this that something is not getting through.
-
You need to create an IPsec tunnel with the information you wish to use for the tunnel. Then you need to create an L2TP over IPsec tunnel inside it. Please call 1 877 354 6555 for more assistance with your set up.
-
I gather from your post that I have to enable IPSEC-Internet Protocol Security on the DIR-130. If I enable that can I also enable L2TP/IPSEC? I was under the assumption that only one profile can be enabled at one time.
I will try and call tomorrow.
-
Fatman,
I called the 877-354-6555 number and what they told me was that I had to purchase the DS-601 client software in order to connect using L2TP over IPSEC. Is that what you recommend too? If not, anything else you can advise.
-
They were mistaken, All 3 major OS'es have native or free tools to handle L2TP over IPsec.
To answer your previous post.
Yes, you must create an IPsec tunnel then create an L2TP over IPsec tunnel over it.
-
That's what I thought.
Okay, I now have the Greenbow client (winxp computer) IPSEC'd to the router. The next step is where I am hung up, how to create an L2TP/IPSEC tunnel.
In the router's IPSEC setup, I am using "remote user", "not Lan to Lan." Is that a problem as this prevents me from setting an L2TP/IPSEC VPN setting on the router. I want to be able to VPN from my laptop.
-
A Remote User VPN is fine, in fact it is exactly what we need. Unfortunately I am not familiar with the Greenbow client, my best advise would be to let Windows XP handle the L2TP pver IPsec client. They are right easy to set up on the client side and there is lost of information on the interwebs on the client side setup.
-
After the IPSEC connection, when I try and connect using the WINXP VPN client (using the Network Setting of L2TP/IPSEC), I receive a 789 error (connection attempt failed because the security layer encountered a processing error during initial negotiations). Is this because the DIR-130 is set up using IPSEC snd L2TP (separate settings), not IPSEC and L2TP/IPSEC as separate settings? I cannot use the latter because the IPSEC setting of "remote user" disallows this combination. Is there a way to set the IPSEC "Lan to Lan" setting to simulate the "remote user" setting?
-
If you create a Net to Net VPN with a remote net of 0.0.0.0/0 and a remote gateway of 0.0.0.0 that should work for you.
Additionally you should only have to dial the one Microsoft client, it handles both halves.
-
I can't seem to get your suggestion of using 0.0.0.0 and 0.0.0.0/0 in the net to net IPSEC settings to work. Is there any way you can test it in your workplace?
In order to use the WINXP Microsoft client, I had to add IPSEC policies using MMC. I did that according to instructions I found on the internet. My current DIR-130 setup is IPSEC enabled (using your 0.0.0.0 and 0.0.0.0/0 setup) and L2TP enabled as separate setups. When I try and connect using the Microsoft client, it gets to phase 2, then the following errors appear (i'm using a Microsoft program that tracks IPSEC):
no specific MM filters conveyed
no quick mode policies configured
no main mode sa exists
no quick mode sa exists
Any idea what these errors mean?
-
You don't have to go through all that trouble. XP has an all in one L2TP over IPsec client. Add a VPN like a normal PPTP VPN and change the type to L2TP and enter the PSK in the IPsec settings button. I know you had a bad experience last time around but since you need a step by step 1 877 354 6555 really is your best choice. Just tell them you are trying to use the XP L2TP over IPsec client and they will walk you through it.
-
I've done exactly that ("Add a VPN like a normal PPTP VPN and change the type to L2TP and enter the PSK in the IPsec settings button") and cannot connect. I think I'm close to connecting but Quickmode in phase 2 has a problem.
As I mentioned previously, I am testing the VPN within my home network (same subnet). Could this be causing a problem? How else could one test a VPN?
-
After much trial and error, I am now able to connect via an ipsec\l2tp connection within my home lan. Now the even harder part, connecting via the internet. My Dlink DIR-130 is now connected behind a Dlink DIR-655 router. All the passthroughs and virtual servers are set up on the DIR-655. Now, when I try and connect from work through the internet, the DIR-655 logs show the following:
"Blocked incoming ICMP packet (ICMP type 8) from xx.xx.xx.xx to yy.yy.yy.yy." (xx.xx.xx.xx is my work ip address, yy.yy.yy.yy is the DIR-655 public address).
Do you have any idea what is causing this error and how to overcome it as this seems to halt any attempt to connect via ipsec?
In the above configuration, I am able to ipsec/l2tp connect from within my lan (from my winxp computer with a local ip address of 192.168.1.254 to the DIR-310, local address of 192.168.1.251, and also from my Vista wireless portable with an ip address of 192.168.1.249). I am also able to connect via vpn PPTP from work to home.
Your assistance has been appreciated.
-
ICMP Type 8 is known as an Echo Request, or more commonly a ping. That traffic is not what is causing your bind here. Though I will say that putting the VPN router behind another router is bad joojoo. Ensure that you have done all nescesarry to forward IPsec on your DIR-655.
To stop those log messages either quit pinging your DIR-655 from work or enable WAN ping on your DIR-655.
-
I am a novice at this, can you explain why it is a no no to put the DIR-130 behind the DIR-655? To my way of thinking, if I set up a VPN server on an XP machine, it would be behind the router too, that supposedly works, why not the router?
My Microsoft IPSEC Diagnostic Tool logs show the following:
Oakley Diagnosis:
(If you did not repro the issue while the tool was running, ignore Oakley Diagnosis)
Information: The host machine is Initiator
Information : Retransmit failure for first IKE Packet. This machine tried to start IKE negotiation with the other machine but it never Received a response. Possible that the other side 1.didn't have a matching MM filter, 2.never received the packet sent by this system 3. This system didn't receive the packet sent by the other side
Live Debugging: End
RRAS Diagnosis:
--Passed : RRAS is switched off, implying no external policies
--Information: Disabling RRAS trace that was enabled during live debugging.RRAS logs copied.
Registry and Events Diagnosis:
--Passed: System, Application and Security event logs collected
IPsec filters, SAs Diagnosis:
--Passed : Generic MM Filters Configured
--Passed :Specific MM Filters Configured
--Information: No Specific Tunnel Filters Configured
--Passed: Main Mode Policies Configured correctly
--Passed: Quick Mode Policies Configured correctly
--Failed: No Main Mode SAs exist between 192.168.1.39 and zz.zzz.zzz.zzz
--Failed: No Quick Mode SA exists between 192.168.1.39 and zz.zzz.zzz.zzz
--Falied : No SA exists between 192.168.1.39 and zz.zzz.zzz.zzz
----However filters exist. Refer logs to debug the failure
Is there any hint here as to what is causing it to fail? The zz.zzz.zzz.zzz address is the public WAN address of the DIR-655. The DIR-130 has an internal address of 192.168.10.251. The logs seems to show an IKE transmit problem.
My DIR-655 has Virtual Server set up to forward UDP port 1701, UDP 500, UDP 4500 and Protocol 50 to the DIR-130. Also, the Application Level Gateway Configuration is enabled for PPTP and IPSEC(VPN).
-
It sounds like your passthroughs are set set up correctly on the DIR-655.
This is the primary reason that I recommend against it, more configurations to go wrong, however there is a second reason. This puts you into what is known as a double NAT'ed situation. Technically it should work, however connectivity from hosts behind the DIR-130 (including VPN'ed computers) to the web will be problematic. The problems that this generated are usually troublesome enough that if you were to call in they would tell you they can't help you.
-
"The problems that this generated are usually troublesome enough that if you were to call in they would tell you they can't help you"
I sort of figured that.
What would the security ramifications be to put the DR-130 connected to the DSL modem and thus in front of the DIR-655?
From your looking at the logs in my previous post, is there anything you could give me a hint on as to what is going wrong?
-
Only that you then have the clients behind the DIR-655 double NAT'ed.
The best solution is to do the following.
Turn off DHCP on the DIR-655.
Give it a LAN IP on the same network as the DIR-130.
Then if you connect the DIRs LAN to LAN.
Connect the modem to the WAN side of the DIR-130.
As far as your logs, it looks like your IPsec isn't even passing the DIR-655, which means you either need to take another look at the passthroughs in it or follow a plan like the one above.