2

Support Port Forwarding Required for VPN

I recently got 3 EEROs and as I was trying to work them into my home network topology, I realized I wouldn't be able to use them fully because the port forwarding feature wasn't working as I needed. 

A little background:  I have a Synology Disk station which runs a VPN server.  It enables me to access my home network while I am not at home.  In order to be able to reach it from outside of my home network (which is really, the only time I need to access it). I have to setup port forwarding on my modem and router.  I had previously been using an older VPN protocol, but had to change it as I usually access it from my iPhone, which stopped supporting that protocol.

The new protocol I had to setup is L2TP.  The port forwarding is on multiple ports, but apparently because this port forwarding is specifically for VPN, routers often have additional "built-in" capabilities to support VPN.  I am not sure what exactly these are.

I do know that when I tried to setup my EERO to perform the port forwarding, I was not able to connect to my VPN server when outside of my network.  So, to get around this, I have used my EEROs in bridge mode, and have my older router performing DHCP and port forwarding.

This is now working but I essentially have an additional piece of hardware in my network just to perform those functions.  Where as, if the EERO was able to support port forwarding for VPN, it wouldn't be necessary.  I realize it's a bit of an ambiguous request, because port forwarding is supported on the EERO.  So the feature request is:  support port forwarding for all VPN protocols, especially the ones supported by iOS devices.

29 replies

    • lesterchan
    • 4 yrs ago
    • Reported - view

    Sill having the same issue a year later.

     

    Been Googling a lot and it seems that there is no clear answers. Did anybody get L2TP VPN on Synology to work? I forwarded UDP 500, UDP 1701, and UDP 4500 and to no avail. Of course internally it works. 

    It seems eero is not opening those ports or forwarding it correctly. I have no issues with other ports.

      • slidvendetta
      • 4 yrs ago
      • Reported - view

      lesterchan I am giving up on eero implementing true VPN support. I am going to set my eero in bridge mode and try an Ubiquiti Networks EdgeRouter X to set up VPN. I will discontinue eero plus if all goes well.

    • Cyberskier
    • 4 yrs ago
    • Reported - view

    I just stumbled on this post. My Synology L2TP VPN, through my eero network, is working fine outside the home, with the ports forwarded that lesterchan mentioned in his post. I do have my own domain name for my home network (such as mysite.com) although I doubt that is what has it working. I connect via the VPN settings on iOS, and using an app called Shimo on my Mac. My settings in Shimo are attached.

    • roselma
    • 11 mths ago
    • Reported - view

    I am having this problem, too.

    Logging in over the LAN works fine.  Logging in over the WAN does not.  I have confirmed that the three ports (500, 1701, and 4500) are open for UPD.  It seems that this may be an issue with the DiskStation's VPN software.  I ran tcpdump to see what was going on during the failed connection attempt...

     

    15:42:02.846134 IP 172.58.43.130.3947 > 192.168.4.29.500: isakmp: phase 1 I ident

15:42:02.917251 IP 172.58.43.130.3947 > 192.168.4.29.500: isakmp: phase 1 I ident

15:42:02.977416 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 1 I ident[E]

15:42:03.916325 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]

15:42:03.959133 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]

15:42:03.959150 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x1), length 120

15:42:03.959356 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:04.607137 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x2), length 120

15:42:04.961126 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:05.963126 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:06.636616 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x3), length 120

15:42:10.619283 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x4), length 120

15:42:10.619545 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:11.621128 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:12.623128 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:13.929025 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I inf[E]

15:42:14.619110 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x5), length 120

15:42:14.619377 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:15.621099 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:16.623129 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:18.628755 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x6), length 120

15:42:18.628960 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:19.629131 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:20.631128 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:22.088310 IP 192.168.4.29.138 > 192.168.7.255.138: NBT UDP PACKET(138)

15:42:22.656151 IP 172.58.43.130.29827 > 192.168.4.29.4500: UDP-encap: ESP(spi=0x01f46163,seq=0x7), length 120

15:42:22.656395 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:23.389165 IP 172.58.43.130.29827 > 192.168.4.29.4500: isakmp-nat-keep-alive

15:42:23.657126 ARP, Request who-has 172.58.43.130 tell 192.168.4.29, length 28

15:42:23.689072 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I inf[E]

15:42:23.999293 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I inf[E]

15:42:23.999327 IP 172.58.43.130.29827 > 192.168.4.29.4500: NONESP-encap: isakmp: phase 2/others I inf[E]

15:42:24.039260 IP 172.58.43.130 > 192.168.4.29: ICMP 172.58.43.130 udp port 29827 unreachable, length 36

15:42:24.039282 IP 172.58.43.130 > 192.168.4.29: ICMP 172.58.43.130 udp port 29827 unreachable, length 36

    As you can see, the DiskStation is repeatedly trying to ARP the address I'm trying to connect from.  But, of course, this address isn't on the local network, so there will be no ARP reply.  This is bizarre behavior.  The routing table is correctly configured, as far as I know, and the DiskStation certainly has no trouble reaching outside hosts.  I do note that the VPN software runs (or can run) in the kernel.  Kernel modules are free to do weird stuff, so perhaps it's erroneously ignoring the routing table and assuming that the source is on the local network?

    I'm also mystified by the two ICMP packets sent by my external device at the end.

Content aside

  • 2 Likes
  • 11 mths agoLast active
  • 29Replies
  • 5887Views
  • 14 Following