
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.
-
Hey FuzzyG !
I was only aware of 3 ports that require being forwarded (according to my VPN server's guide):
500, 1701 and 4500
Here's the post I found which mentions the additional requirement the router should support - it's encapsulated security protocol (ESP).
https://forums.att.com/t5/U-verse-2014-Archive/Connect-to-home-L2TP-VPN-not-working/td-p/3907757
-
A few days ago I got a message indicating this request is under review. Just wanted make everyone in the community, and Eero product managers aware of the following:
I received confirmation from Eero support that this is already supported. Chris in support said the following in his support email to me:
Thanks for writing in! We shouldn't have an issue with ESP as it's a part of the IPsec protocol suite - we pass this traffic on its way between the VPN server and client. So long as you have the proper port forwarding setup on the eero that you need to access the VPN server (I'm assuming this is another device you have on the network), then you should be good to go.
I hope this helps and let me know if you have any other questions!
Best,
Christopher @ eero
---end of message---
I have yet to try it out, but I did a preliminary test and I think it is working. I will post again once I have had a chance to confirm everything is working as expected.
-
socaluser —
Sorry about that! We've been making a few changes to the eero community and this got moved over to Feature requests. Because of that, it was automatically designated with an "In review" and we've still been doing some cleanup since the change. I have moved this topic back over to discussion since it isn't a feature request.
-
I run macOS Server v5.2 on a Mac Mini with the VPN service running. I also have a dynamic DNS hostname for VPN. I'm able to VPN externally of my LAN either from another WiFi network or my iPhone via LTE. I made sure I port forwarded TCP port 1723 and UDP ports 500, 1701, 4500.
So, for me, VPN works great using eero.
-
Improvisit
I assume you setup your eero in Network Settings/Advanced Settings/Reservations & Port Forwarding.... Add a reservation for your Mac and opened the VPN ports? In that configuration I have separate entries for each of the UDP ports and TCP port. My dynamic DNS hostname is hosted by Noip.com and my Internet IP address for the DNS is the IP Address in eero's Network Settings/Advanced Settings/Internet Connection. The key is to have your DNS IP address at the host site set to your IP address the eero system uses to feed Internet activity.
-
I never got it working, but I think it has more to do with the fact that I was connecting my DiskStation to two distinct networks, which is probably not a normal thing to do (the second connection was a direct connection to a media server ). Anyways, the eero does support L2TP VPN in its port forwarding. I have it working with a Windows VPN Server. Am not saying it’s not possible with the DS, I just ended up going a different route so don’t have details.
-
I'm having the same problem. This may be the basic feature that Eero doesn't have or can't make work that is the last straw for me. This is so basic. Basically I enable the L2TP VPN on my Synology and open the ports on the Eero and it just doesn't work. I can open other ports and it works fine. Its something to do with the way Eero is handling these VPN ports.
-
I finally got mine to work.
these are the steps I did:
in the Eero app:
-make sure your disk station has a reservation/IP
-remove ports 500, 4500 and 1701 from any other devices
-add port forwarding rules for all 3 ports to your disk station reservation in eero
On your disk station:
-make sure you've setup the L2TP VPN configuration correctly.
-enable and save the config
Reboot the Eero and restart the VPN Server Service:
-On the disk station, go to packages, STOPm, then START THE VPN SERVER SERVICE
-Restart your whole eero network.
First try to VPN into your Diskstation WHILE on the Eero wireless network. That should work.
If it does, then disconnect the VPN, Reboot your Eero again, disconnect wifi on your mobile device, and try over your cellular connection once everything is up.
There were 2 reasons this worked for me. First the Eero (because it's UDP) Holds the port forwarding session open for a period of time. Rebooting the Eero will force it to clear any open connections. (especially if your reservation or port forwarding rules were incorrect and needed to be corrected. IE you were debugging the situation)
The VPN Server on the disk station was also blocking the connection for some reason. A restart fixed that issue. The auto-block feature may also be causing this.
Prior to Eero, I had issues with what appeared to be the Verison router not forwarding rules all the time. It may actually be something with the Disk Station VPN Server that's not quite right. I'll be switching to a Raspberry Pi as a VPN gateway (with proxy arp for even better support) if this continues.
But I can say, Eero does support L2TP VPN with the latest firmware.
-
I have the same problem. I have VPN setup on my Synology NAS, and it works just fine from within my LAN, so I know it is set up correctly. I've forwarded all the UDP ports I'm supposed to, but it doesn't work from outside the LAN. I've successfully forwarded ports for other services, so I can only conclude the eero is screwing up something. These are CLEARLY not designed for anybody but naive users who don't want to do anything remotely sophisticated. Regretting my decision to buy so many eeros...
-
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.
-
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.
-
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.