2Support 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.
-
Hi @socaluser
You've already forwarded the 4 standard ports correct ?
-
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
-
Yeah sorry, the last one on the list is ESP. You are correct that there isn't a place to create this.
-
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.
-
KeithG Hi Keith, you give me hope. We have macOS Server v5.2 running and all the port settings you suggested. We have a domain name from a free DNS service. Under the macOS VPN tab, it says "available - reachability unknown." Any other tricks or suggestions for us?
-
Any update from op
-
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 was curious if the OP was sorted
-
Truly thank you for your support, we've dropped this and have taken another approach.
-
Did anyone ever get this working. I have a Synology Diskstation and the proper ports forwarded in the eero but I can't connect to my L2TP/IPSec VPN
-
I have the same issue. Both TCP & UDP forwarded on the above ports, but doesn’t work.
-
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.
-
imahawki which ports have you forwarded? also, am assuming but just wanted to confirm - have you opened up your modem's firewall to forward as well?
-
socaluser 500, 1701 and 4500. I have them forwarded on the Eero. There are no settings I can change on my modem. I called my ISP (Cox) and they said they don’t block those ports.
-
imahawki A suggestion: call Cox back and see if you get a different answer. I would be surprised if their modem doesn’t have any kind of firewall. Also, google your modem model and learn how to change its configuration. Even if Cox is right, you should be able to verify the modem’s firewall is turned off. If it’s not (which is my guess) you should be able to poke 3 holes in it for your VPN ports. if you share your modem’s model number I can help you research it. Good luck!
-
socaluser Its an Arris SB8200. I've logged into it. There are literally zero editable fields for the end user. I can try calling again today but I don't have high hopes that I'll get anyone technical enough to help.
-
-
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.
-
Karlg100 Good lord. I'll give that a try but I have to ask, once you did this dance and got it working was it stable or did you have to redo the dance every time you rebooted the NAS or Eero?
-
Karlg100 It didn't work. And if I go here https://www.yougetsignal.com/tools/open-ports/ it says 500, 4500, and 1701 are not open. Something is working because I have port 5000 open on my Eero and that same site reports that as open. So port forwarding is working on some level... just not for those other 3 ports.
-
Karlg100 I just got off the phone with Cox. They swear up and down they aren't blocking these ports. I'm not going to get a different answer from them at this point.
-
imahawki pretty sure that site only checks TCP. You need UDP working.
If you have a Mac or Linux box on your network for testing, forward those rules to a test host. Reboot the Eero. Then use a tool like netcat to establish a UDP session.
On the internal host: nc -lu 500
On the external host: nc -uvv [external IP] 500
Repeat for ports 4500 and 1701.
Run wireshark on the internal host for more insight listening on those 3 ports and you should see the packets come in when you attempt to connect.
If cox is not blocking, and Eero is forwarding, then anything you type on the remote end should show up on the local side. (You can try TCP as well, just drop the u flag on both sides). Test for each of the 3 ports.
As a bonus, while running “nc -ul 500” on the test host, initiate a VPN session from your VPN client on an external network, and see if you get garbage from netcat when the session starts. If so, that tells you Eero and Cox are doing everything right.
If all that checks out, then it’s your Diskstation where the trouble lies.
Otherwise, something is blocking your traffic. Either the remote provider, your local provider, or something in between.
Remember when you redo the forwarding rules on the Eero back to the Diskstation, reboot the Eero each time.
-
-
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.
-
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.
-
-
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.
