2

I am trying to get my VPN (L2TP IPSec PSK) to work. I have a Synology NAS where I have setup everything as it says on the Synology support page.

In my Asus RT-N66U router I have opened UDP ports 500, 1701 and 4500 for port forwarding to my NAS that has the VPN service running. See the picture below. enter image description here

But from outside the network I can't connect to my VPN. I have tried both from my computer and from my Android phone. If I am inside the network and set the host of my VPN client to the IP of the NAS/VPN given by my router, it works, so I suppose it has something todo with my Asus RT-N66U router that maybe does not forward the packets properly.

Any ideas on this issue?

EDIT
No logs from my VPN log. Here is a packet dump with only the UDP packets of the L2TP IPsec communication captured by my NAS, so it seems the router forwards the packets accordingly:

DiskStation> tcpdump -i eth0 -n udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:36:41.676327 IP 192.168.1.1.500 > 192.168.1.6.500: isakmp: phase 1 I ident
21:36:41.678225 IP 192.168.1.6.500 > 192.168.1.1.500: isakmp: phase 1 R ident
21:36:41.681985 IP 192.168.1.222.500 > 192.168.1.6.500: isakmp: phase 1 ? ident
21:36:41.691981 IP 192.168.1.6.500 > 192.168.1.222.500: isakmp: phase 1 R ident
21:36:41.705949 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 1 ? ident[E]
21:36:41.709625 IP 192.168.1.6.4500 > 192.168.1.222.4500: NONESP-encap: isakmp: phase 1 R ident[E]
21:36:42.675037 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 2/others ? oakley-quick[E]
21:36:42.676606 IP 192.168.1.6.4500 > 192.168.1.222.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
21:36:42.678285 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 2/others ? oakley-quick[E]
21:36:42.679253 IP 192.168.1.1.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x1), length 116
21:36:43.294988 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x2), length 116
21:36:44.689496 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() *FIRM_VER(1680) *HOST_NAME(DiskStation) *VENDOR_NAME(xelerance.com) *ASSND_TUN_ID(25553) *RECV_WIN_SIZE(4)
21:36:45.296703 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x3), length 116
21:36:46.699567 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x1), length 164
21:36:46.699611 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() *FIRM_VER(1680) *HOST_NAME(DiskStation) *VENDOR_NAME(xelerance.com) *ASSND_TUN_ID(25553) *RECV_WIN_SIZE(4)
21:36:46.700226 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x2), length 68
21:36:47.709533 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x3), length 164
21:36:47.709571 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() *FIRM_VER(1680) *HOST_NAME(DiskStation) *VENDOR_NAME(xelerance.com) *ASSND_TUN_ID(25553) *RECV_WIN_SIZE(4)
21:36:48.719556 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x4), length 164
21:36:48.719600 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() *FIRM_VER(1680) *HOST_NAME(DiskStation) *VENDOR_NAME(xelerance.com) *ASSND_TUN_ID(25553) *RECV_WIN_SIZE(4)
21:36:49.301815 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x4), length 116
21:36:49.302278 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x5), length 68
21:36:49.729532 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x6), length 164
21:36:49.729575 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() *FIRM_VER(1680) *HOST_NAME(DiskStation) *VENDOR_NAME(xelerance.com) *ASSND_TUN_ID(25553) *RECV_WIN_SIZE(4)
21:36:50.388037 IP 192.168.1.222.21327 > 255.255.255.255.21327: UDP, length 112
21:36:50.388972 IP 192.168.1.222.21327 > 255.255.255.255.21328: UDP, length 112
21:36:50.739621 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x7), length 164
21:36:51.749767 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(25553) *RESULT_CODE(1/0 Timeout)
21:36:52.759548 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x8), length 100
21:36:52.759663 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(25553) *RESULT_CODE(1/0 Timeout)
21:36:52.829697 IP 192.168.1.6.4500 > 192.168.1.222.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
21:36:52.962544 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
21:36:53.307101 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x5), length 116
21:36:53.307540 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0x9), length 68
21:36:53.769512 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xa), length 100
21:36:53.769553 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(25553) *RESULT_CODE(1/0 Timeout)
21:36:54.779555 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xb), length 100
21:36:54.779597 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(25553) *RESULT_CODE(1/0 Timeout)
21:36:55.789545 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xc), length 100
21:36:55.789589 IP 192.168.1.6.1701 > 192.168.1.1.51432:  l2tp:[TLS](22/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(25553) *RESULT_CODE(1/0 Timeout)
21:36:56.799555 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xd), length 100
21:36:57.311344 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x6), length 116
21:36:57.311810 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xe), length 68
21:37:01.315211 IP 192.168.1.222.4500 > 192.168.1.6.4500: UDP-encap: ESP(spi=0xd949debf,seq=0x7), length 116
21:37:01.315643 IP 192.168.1.6.4500 > 192.168.1.222.4500: UDP-encap: ESP(spi=0x090a5fbd,seq=0xf), length 68
21:37:01.979832 IP 192.168.1.6.4500 > 192.168.1.222.4500: isakmp-nat-keep-alive
21:37:01.979868 IP 192.168.1.6.4500 > 192.168.1.222.4500: isakmp-nat-keep-alive
21:37:02.645006 IP 192.168.1.222.4500 > 192.168.1.6.4500: isakmp-nat-keep-alive
21:37:02.687529 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
21:37:02.688145 IP 192.168.1.222.4500 > 192.168.1.6.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
21:37:02.688189 IP 192.168.1.6.4500 > 192.168.1.222.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
21:37:02.711699 IP 192.168.1.6.4500 > 192.168.1.222.4500: NONESP-encap: isakmp: phase 2/others R inf[E]
21:37:03.881937 IP 192.168.1.222.17500 > 255.255.255.255.17500: UDP, length 104
21:37:03.882667 IP 192.168.1.222.17500 > 192.168.1.255.17500: UDP, length 104
Rox
  • 441
  • 1
  • 6
  • 13
  • Have you forwarded 443? That would be my first suggestion as IPSEC sets up on 443 and transfers traffic on 500. – MartinC Oct 27 '14 at 19:55
  • Yeah, I just opened TCP port 443 but it still does not work. :( – Rox Oct 27 '14 at 20:16
  • Is there any type of logging feature on the NAS to indicate if it is receiving requests or what part of the process it may be failing at? If so, clear the logs and make another attempt and post the logs as an edit to the question. Logs are incredibly helpful when working with VPN tunnels. If NAT-Traversal is an option, that should probably be enabled as well since the NAS is behind a NAT Router – MartinC Oct 27 '14 at 20:28
  • I added the packet capture from my NAS. These packets seem to be forwarded by my router. So it must be something else I have missed? – Rox Oct 27 '14 at 20:43
  • @MartinC "Have you forwarded 443? That would be my first suggestion as IPSEC sets up on 443 and transfers traffic on 500." Umm, what? IPsec has nothing to do with port 443. – EEAA Oct 27 '14 at 20:55
  • @EEAA after supporting vpn capable routers/nas/etc. for several years, I can assure you that a good many of them require 443 even if it is not part of the specification. Not necessarily the case here, but it was a good place to start. – MartinC Oct 27 '14 at 21:21
  • @MartinC Well,I've never seen that (Windows IPSec, FreeBSD, Linux, etc.), and I'd give a strong sideways glance to any IPsec implementation that requires it. – EEAA Oct 27 '14 at 21:22
  • @EEAA I'm not saying that it is a good way for devices to implement IPSEC, merely that I have seen it more often than I like. I should have phrased my initial comments better. – MartinC Oct 27 '14 at 21:28
  • @Rox Any kind of NAT-Traversal options on the NAS? – MartinC Oct 28 '14 at 18:45
  • @Rox Did you manage to make this work? I have the same problem with the same hardware. – iPDFdev Jan 28 '15 at 15:34

2 Answers2

2

Im sorry about my English. I have same problem and after..... many hours........... I see a option in the Networks Interfaces..... need edit the Interface LAN when you have the connection Server VPN and check box Set as default gateway

Cant upload image.... cos my first post here.

Alex41
  • 21
  • 2
  • That was exactly the issue I ran into and your comment solved it. My Synology is connected via 1 of it's 4 LAN ports to a DMZ on the router, the VPN is assigned to that LAN port. The 3 other ports are on VLANs which have routing back to the internet but via an addition layer of NAT. The IPSEC connection was being established on the DMZ side but the L2TP was responding via one of the non-DMZ VLANs. This failed to use the IPSEC tunnel and clearly caused the connection to fail. Going into "Network->General" and changing the order of the "Default Gateway" solved it. Hours saved, thanks! – BHowell Jul 04 '16 at 20:58
  • Old question, yet so very relevant in 2017. The default gateway is the solution for me as well. Have the DMZ routed to one of the LANs but not the first. Needed to change the default gateway and now everything works like a charm. Thank you! – fxstein Jul 03 '17 at 13:43
0

This is an old post but on google searching this came up as I was having the same issue. This is what I did to help people with the issues above.

I am using Synology 415+ using a VPN Server and connecting my iPad via L2TP, and my router is RT-AC68U.

First Steps: ROUTER port forwarding - RT-AC68U.

  1. Log in to your router via the web console
  2. WAN on the left menu bar
  3. Virtual Server / Port Forwarding Tab
  4. Enable port forwarding
  5. Add your service ports 4500, 500 and 1701 all UDP ports don't forget to add the synology's internal ip address
  6. Click the + sign to add and repeat for the other ports
  7. Once done apply button below or these won't be saved.
  8. Router should look like above.

Log into your synology box

SYNOLOGY NAS

  1. Install VPN Server if not already done and open it up: L2TP/IPSec Synology
  2. Click General settings and make sure you select the correct network card that is connected and routed to the outside world. I have 2 but these are bonded together for redundancy General Settings
  3. Make sure you check the privilege option and that the user account has been granted access.

You should be all good to go!

If still an issue go to network settings under Control Panel on the synology nas box.

  1. Select the interface that is connected to the outside world.
  2. Select IPv4 and make sure the gateway is selected as the router's ip address, and tick the set as default gateway
  3. Double check your General Settings under the VPN server and that is pointing to that network interface.
  4. Secret password is set to something very basic like 1234 for testing purposes
  5. Account has access to run and log in via VPN

DONE!

TheNerdyNerd
  • 101
  • 2