Community discussions

 
User avatar
dserarols
just joined
Topic Author
Posts: 4
Joined: Thu May 16, 2019 7:09 pm
Location: Spain
Contact:

Mikrotik VPN server behind ISP router

Thu May 16, 2019 7:19 pm

Hi,

I am trying to configure a VPN server in a Mikrotik router behind an ISP router, this is the públic IP is not in my Mikrotik :-(

I've tried at first with a L2TP IPSec VPN without succes. The same configuration works fine if the Mikrotik has the public IP, so I think the problem is in a wrong port forwarding; if I am not wrong, I need UDP 500 and UDP 4500.
I've tried the same with PPTP VPN but it did not work. Forwarded port was 1723 UDP.

I read somewhere that in L2TP IPSec I have to allow (pass-through) ESP protocol, and GRE if I am using PPTP. I can not find these options in my ISP router (HG8245H).

Any clue about this issue?

PS: Using my HG8245H as a simple ONT and a PPPoE client in my Mikrotik is not an option, because these devices must be "plug and play" in the customer premises so there is not IT staff there.
Happy to help and willing to learn.
 
Sob
Forum Guru
Forum Guru
Posts: 4187
Joined: Mon Apr 20, 2009 9:11 pm

Re: Mikrotik VPN server behind ISP router

Fri May 17, 2019 5:44 pm

Do you use Windows client? There's a problem with L2TP/IPSec behind NAT. Search for "AssumeUDPEncapsulationContextOnSendRule".

Other option would be different VPN type, SSTP or OpenVPN need only one port and work fine with NAT.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
sindy
Forum Guru
Forum Guru
Posts: 3473
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik VPN server behind ISP router

Fri May 17, 2019 5:52 pm

It is a bit more complex than it seems.

First regarding PPTP which is a simpler case (but PPTP is anything but secure so better don't use it). There, TCP/1723 is used to authenticate the client and negotiate the connection, GRE is used as transport for the actual tunnel packets. GRE is a dinosaurus protocol which doesn't have the notion of ports, so in NAT environment, ony one device on the private side of the NAT can talk to the same device on the public side of the NAT no matter how clever the NAT device would be. Some NAT devices cannot forward GRE at all, some will open a pinhole if the private side device sends a packet to the public side one but no public->private forwarding is configurable.

With L2TP, the behaviour changes depending on the overall situation. If there is no NAT at all, neither at "server" (responder) nor at "client" (initiator) side, IPsec indeed uses ESP as transport. Like GRE, ESP has no notion of ports, so the same type of limitations applies, except that the NAT device may support ESP forwarding but not GRE forwarding or vice versa. But an ESP packet is only sent when there is a payload packet which needs to be sent, so even if the NAT device supports ESP forwarding, the packet from client will not be let in until the server sends its own packet to the client.

If there is NAT at client or server side (or both), IPsec detects that and starts encapsulating ESP into UDP to allow NAT traversal. However, the embedded VPN client in Windows by default doesn't accept a situation where the NAT exists at server side, so although technically the IPsec would deal with it, the Windows client refuses to establish such connection. One possibility is to change this default behaviour in Windows' registry, but I have no idea whether the howto for Win7 which you can google out is applicable also for newer versions of Windows. Another possibility is to make the Mikrotik think it has the public IP on itself, but in that case ESP will be used if the client has a public address (i.e. no NAT on its end), so the ISP's box may not let it through.

And last, to have several L2TP/IPsec clients behind the same public IP at their end, you need to do some black magic at the server end.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
dserarols
just joined
Topic Author
Posts: 4
Joined: Thu May 16, 2019 7:09 pm
Location: Spain
Contact:

Re: Mikrotik VPN server behind ISP router

Wed May 22, 2019 11:47 am

Do you use Windows client? There's a problem with L2TP/IPSec behind NAT. Search for "AssumeUDPEncapsulationContextOnSendRule".

Other option would be different VPN type, SSTP or OpenVPN need only one port and work fine with NAT.
Yes, I use indeed a Windows client, but only for testing purposes. This L2TP/IPSec VPN should be formed by two Mikrotik. I will test it again without the Windows 7 Client.
Happy to help and willing to learn.
 
User avatar
dserarols
just joined
Topic Author
Posts: 4
Joined: Thu May 16, 2019 7:09 pm
Location: Spain
Contact:

Re: Mikrotik VPN server behind ISP router

Wed May 22, 2019 11:58 am

It is a bit more complex than it seems.

First regarding PPTP which is a simpler case (but PPTP is anything but secure so better don't use it). There, TCP/1723 is used to authenticate the client and negotiate the connection, GRE is used as transport for the actual tunnel packets. GRE is a dinosaurus protocol which doesn't have the notion of ports, so in NAT environment, ony one device on the private side of the NAT can talk to the same device on the public side of the NAT no matter how clever the NAT device would be. Some NAT devices cannot forward GRE at all, some will open a pinhole if the private side device sends a packet to the public side one but no public->private forwarding is configurable.

With L2TP, the behaviour changes depending on the overall situation. If there is no NAT at all, neither at "server" (responder) nor at "client" (initiator) side, IPsec indeed uses ESP as transport. Like GRE, ESP has no notion of ports, so the same type of limitations applies, except that the NAT device may support ESP forwarding but not GRE forwarding or vice versa. But an ESP packet is only sent when there is a payload packet which needs to be sent, so even if the NAT device supports ESP forwarding, the packet from client will not be let in until the server sends its own packet to the client.

If there is NAT at client or server side (or both), IPsec detects that and starts encapsulating ESP into UDP to allow NAT traversal. However, the embedded VPN client in Windows by default doesn't accept a situation where the NAT exists at server side, so although technically the IPsec would deal with it, the Windows client refuses to establish such connection. One possibility is to change this default behaviour in Windows' registry, but I have no idea whether the howto for Win7 which you can google out is applicable also for newer versions of Windows. Another possibility is to make the Mikrotik think it has the public IP on itself, but in that case ESP will be used if the client has a public address (i.e. no NAT on its end), so the ISP's box may not let it through.

And last, to have several L2TP/IPsec clients behind the same public IP at their end, you need to do some black magic at the server end.
Thank you very much.

My idea is configure this VPN behind a router with just one server on one side and just one client on the other side. So I think the problem could be on my ISP router, which is not forwarding GRE or ESP protocols :-(
Happy to help and willing to learn.
 
sindy
Forum Guru
Forum Guru
Posts: 3473
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik VPN server behind ISP router

Wed May 22, 2019 1:43 pm

If both the server and the client will be Mikrotiks, it should be enough to do port forwarding for UDP port 4500 from the public address to Mikrotik's address at responder side for IKEv2 (which I prefer myself), and UDP ports 500 and 4500 for IKE(v1); in the latter case don't forget to also set nat-traversal=yes in /ip ipsec profile. Do not set the public address on the Mikrotik itself.

This way the IPsec stack will notice the NAT and will encapsulate ESP into UDP, which costs some MTU but circumvents the blocked ESP.

IPsec doesn't notify the network about MTU reduction and silently fragments the packets, which adds unnecessary overhead. So it is better to find out what the actual payload maximum size is with the particular encryption and authentication algorithms used and set the TCP MSS accordingly using mangle rules. But you don't need to do this right from the start, first make the tunnel work.

And forget about PPTP of course, there is no way to make PPTP use UDP instead of GRE.

Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
dserarols
just joined
Topic Author
Posts: 4
Joined: Thu May 16, 2019 7:09 pm
Location: Spain
Contact:

Re: Mikrotik VPN server behind ISP router

Tue May 28, 2019 6:19 pm

Thank you very much. It worked!

If both the server and the client will be Mikrotiks, it should be enough to do port forwarding for UDP port 4500 from the public address to Mikrotik's address at responder side for IKEv2 (which I prefer myself), and UDP ports 500 and 4500 for IKE(v1); in the latter case don't forget to also set nat-traversal=yes in /ip ipsec profile. Do not set the public address on the Mikrotik itself.

This way the IPsec stack will notice the NAT and will encapsulate ESP into UDP, which costs some MTU but circumvents the blocked ESP.

IPsec doesn't notify the network about MTU reduction and silently fragments the packets, which adds unnecessary overhead. So it is better to find out what the actual payload maximum size is with the particular encryption and authentication algorithms used and set the TCP MSS accordingly using mangle rules. But you don't need to do this right from the start, first make the tunnel work.

And forget about PPTP of course, there is no way to make PPTP use UDP instead of GRE.

Happy to help and willing to learn.

Who is online

Users browsing this forum: No registered users and 45 guests