I am trying to create an L2TP/IPSEC server on an existing MikroTik to connect in “road warrior” mode.
The server is at a public, addressable IP, not behind a NAT. I have tested with three clients: iPhone, Mac, and Windows 10. I have tested with all of them within the same NAT network as each other (no relation to the server’s network), and I have tested with the iPhone on its public (cell) address. Every configuration connects successfully and works properly except Windows 10, which will not connect.
To align the phase 1 proposal, set the enc-algorithm, hash-algorithm, and dh-group in /ip ipsec peer configuration to include the strongest combination of these algorithms suggested by the Windows client; to align the phase 2 proposal, align the /ip ipsec proposal parameters auth-algorithms, enc-algorithms, and pfs-group with the Windows client’s proposal.
Here is a screenshot of the log with the successful iPhone connection on the left, the unsuccessful Windows 10 connection on the right.
Other than the Windows local port number, I don’t see any difference in the logs up to the point where the level 2 negotiation on the iPhone works right off the bat, while the level 2 negotiation on Windows gets retried over and over and eventually fails to connect. If Windows is proposing some phase 2 encryption protocol I haven’t enabled, I don’t know how to determine what that is from this log output.
Here is an image of my proposal parameters in case it is immediately apparent to someone familiar with Windows 10 what Windows 10 may be requiring that the Mac and iPhone apparently don’t need.
It looks that way, but it really isn’t. The phone company modem is in bridge mode, translating its world-facing public address to 192.168.100.1 for the local network. (I mean, technically, that’s a NAT, but it’s a one-to-one NAT.) The MikroTik is at 192.168.100.2 at the other end of a short cable. NAT happens inside the MikroTik, but so does the L2TP service, so it’s not NATted. If I connect to the modem’s public address, I get the MikroTik directly (or I would if the firewall allowed that) with no port forwarding required anywhere. And, as I mentioned, the server services iPhones and Macs just fine, so if NAT were the issue here, I would assume they would not have been successful either. Also, /ip cloud runs just fine without giving me the nag message that it’s on the inside of a NAT.
However, in case Windows doesn’t like the one-to-one NAT, I will try the information in the link provided sometime in the next 48 hours and post back here about whether or not it worked. Thanks for the link.
Yes, all of the above. (It’s notable that the hit count on the ipsec-exp rule sits at zero, despite successful connections from Macs and iPhones, and multiple attempts from Windows 10.)
I lied. It does, in fact, give me that message. Apparently the AT&T modem doesn’t have a pure bridge mode so it’s configured as a DMZ which is the best it can do. I will definitely try the registry patch when I can get to it.