So I am attempting to build a roadwarrior L2TP/IPSec solution using a RouterBoard as home base.
So far the working setup is pretty simple. L2TP server enabled, a PPP secret set, and IPSec with a pre-shared key and policy generation active.
This works FINE with windows’ L2TP client. Until there’s NATing on the clients side.
I think I’ve isolated the issue to the policy generation. When a NATed client connects, the policy generation uses the internal address of the client (in this case a 192.168.0.x address because I just slapped on a default set linksys router into the test scenario).
I’m wondering if this is something that needs to be addressed in a RouterOS update, or if it’s the fault of the Windows client (which means I need to look at different L2TP/IPSec clients). If there was an option on the Mikrotik router to force the policy to generate using the address that it sees rather than what the client reports, that may fix it…
So, MTROS issue, Windows client issue (according to microsoft the client should have working NAT-T support), or something I’m missing?
Hi, i seem to be having a similar error to you, basically doing the same setup, (roadwarrier vpn) and am having problems connecting through NAT
Any chances of you posting up some ipsec and l2tp logs to confirm if we are having the same error? would be interested to see another persons experience with this issue if so. if you do make sure you hash out your ips and any other sensitive info
At client I have IPSec policy to encrypt all ICMP between client IP and above router.
When client is also on public IP, everything works perfect. But when I move the same client with same settings behind NAT, it just doesn’t work.
The negotiation looks successfull:
20:00:21 ipsec IPsec-SA established: ESP/Transport <NAT Public IP>[4500]-><Router Public IP>[4500] spi=264237757(0xfbff2bd)
20:00:21 ipsec IPsec-SA established: ESP/Transport <Router Public IP>[4500]-><NAT Public IP>[4500] spi=2813802196(0xa7b736d4)
Router also adds dynamic IPSec policy with source address 192.168.84.2 (internal address of client behind NAT) and dst address .
When I run “ping ” at client, there are packets going to (udp, srcport 4500, dstport 4500) and they reach the router. But there is no reply going back. There are some similar packets (udp, both ports 4500) going the other way, but their payload is just single byte (0xff). There is one each 20 seconds, so I guess it’s just some kind of keep-alive.
Another interesting thing shows, when I try to ping 192.168.84.2 from router. IPSec link should be already established, so I’d expect that the request should be encapsulated in udp and sent to :4500. But instead:
20:21:43 ipsec IPsec-SA request for 192.168.84.2 queued due to no phase1 found.
20:21:43 ipsec initiate new phase 1 negotiation: <Router Public IP>[500]<=>192.168.84.2[500]
20:21:43 ipsec begin Identity Protection mode.
20:22:15 ipsec phase2 negotiation failed due to time up waiting for phase1. ESP 192.168.84.2[500]-><Router Public IP>[500]
Well, it seems like we are having similar errors, my ipsec peer settings are identical to the ones you have posted here, and also the issue with the policy being generated with the internal address, originally i believed this to be a symptom of the NAT router at the client end. but quickly replicated the problem with a different type of router.
I havnt really had the time to get down to packet level troubleshooting as yet, when I have some time Ill have a look and post the results, though I believe ill see something similar.
what i have done so far is pretty much changed every setting possible on routerOS and client PC and watched the logs,and probably managed to generate every error possibly known to mikrotik in the process.
So looks like im asking the same question your asking, bug with routerOS,bug with microsoft ipsec, or have we both managed to miss something.
Not me. I’m digging in it mostly out of curiosity, I don’t really need it. I use IPSec only for site to site VPN with public addresses and it works fine. And for roadwarrior I found much simpler to set up OpenVPN, so I use that.
Other interesting question would be, is here someone who got this working?
I have exactly the same issue here…
Road warrior type setup L2TP with IPSEC. Server is on public IP un-natted client NATed.
Connection will work perfectly as long as there is no form of NAT involved, meaning i am on same LAN as device.
Once you add client side NAT in the mix it falls apart.
I have sent through a support ticket however hope to resolve this quickly as the company i now work for is using Sonicwall predominantly and i am trying to do a proof of concept for them to convince them of going Mikrotik in a few places.
This trial holds alot of weight for me in this aim.
I really hope someone from Mikrotik can advise on what should be done here…
Yes, I’ve tested L2TP to a RB 450G running v5.12 where the client is behind NAT [Windows 7/XP-SP3] and the server [RB450G v5.12] is not.
Works nicely.
However, only a single client behind the NAT device can connect to L2TP at a time. The second device will hijack the first devices connection.
However, firewall rules, either on the NAT device, or on the L2TP client machine itself can cause issues.
If you’re having no problem connecting with the same machine without NAT, then check the fw rules on the added NAT device, as well as local machine rules that might be configured differently in the two places. [Best is to remove all rules and port-forwarding and see if it works. then add back in stuff in small chunks until it quits working - then figure out what’s exactly at fault.]
