What works:
[] Radius works, took a while to get it working, but it does.
[] I can log in, and get an IP address
[*] I can ping the router
What doesn’t work:
[] VPN is not in “split” mode, when I connect to the VPN, internet goes away (is this a client setting?)
[] Client doesn’t get default gateway
What I have set up:
Router IP is 10.0.0.103, most local clients are on an IP pool for 10.0.1.0/24, there is a route for 10.0.0.0/22 with distance 0 for those local clients.
We also have OpenVPN set up on 10.8.2.0/24 which is routed with a distance of 1 to gateway 10.0.0.250 and this works.
I have the L2TP pool set up for 10.0.70.0/24 with the same route and distance and gateway as above, to mirror openvpn settings.
And yet I get no gateway, here’s the output from ipconfig /all:
There should be an option to “set the default route to the VPN” and even to “set the class-based route” but
as Windows 10 has degraded more and more it probably now is on the super-advanced settings page you never
find back once you first encountered it, or it can only be set using powershell. That is how things go.
Windows also has a proprietary method to send specific routes from the server to the client, but it is not supported
by MikroTik as a L2TP server.
It is a generic problem in the VPN world. It is surprisingly difficult to setup a simple VPN that connects a client
to some network with a couple of subnets, while leaving it connected to internet (often called split-tunneling).
Proprietary solutions exist but in general standards it is often near to impossible. That is also the reason why
every once in a while a “new standard” of VPN develops that is actually just yet-another-proprietary-solution
available only on a few platforms. When you are lucky, it can cover your needs.
For a quick solution when interconnecting networks between MikroTik routers over different VPN technologies
(L2TP/IPsec, GRE/IPsec, GRE6/IPsec, SSTP) I am using BGP. The VPN is used to make a simple point-to-point
link between te routers, and BGP is used to distribute the subnet routes over that. This has the advantage that
you can have multiple redundant tunnels (e.g. GRE/IPsec and GRE6/IPsec in parallel) and send the traffic over
the other one when the preferred one fails.
But for connecting road warrior Windows users to a company network that is usually not a viable solution, as
it requires a router at the client side as well. Or BGP under Windows. Good luck.
The router is not involved in this process, it must be a client-side issue.
Maybe related to permission?
And yes my use case is explicitly the road warrior windows user.
I don’t quite get how BGP is connected to this…
I use BGP to tell the other side which subnets to route over the VPN. But that only makes sense when the client can talk BGP.
In my use case (only VPNs between MikroTik routers) it works OK but for the road warrior windows user it is not an option,
unless they take something like a mAP lite along with them.
As I explained, it is a hard to solve problem. Certainly when you want to route a couple of subnets over the VPN and not everything,
and you want to use a MikroTik router as the server. It is missing the proprietary implementations that OS vendors are trying
to push onto others. Where other router manufacturers apparently followed them, MikroTik didn’t.
How does the client know the default gateway for the network if the router does not tell it? Having the same issue here, the checnbox to use the default gateway on remote network is enabled for the VPN L2TP Server connection in microtik, yet windows reports default gateway to be 0.0.0.0. Similar setup with pfsense instead of microtik at friend’s works well…
L2TP is a PPP connection, it has 2 IP addresses: the server and the client.
After the client has made the connection, when it wants to set the default gateway, it sets it to the address of the server (that it has just obtained making the connection).
That is why you find the option to set default gateway only on the client side, the server is not involved in that.
That being said, there are de-facto standard ways of setting routes on such a connection, as there often is the desire to route one or more subnets over the VPN and keep the default route direct to internet.
Several (different) of such “standards” exist, e.g. Windows does a DHCP request over the connection to obtain a subnet list to route over the connection.
In recent versions MikroTik apparently can handle that (I have no personal experience with this).
As @pe1chl answered, the client choice is between routing everything (except the tunnelling packets themselves) through the tunnel or use just the tunnel for the tunnel traffic. If your client sends the traffic through the tunnel and the server does not route/nat it it is because there is some problem in the firewall rules of the server. You can see all the traffic that the server gets from the client with a command (in the server) like /tool sniffer quick interface= (whatever interface name you have) and check if the server is routing answers to traffic, properly natted, etc.
I think default gateway is a red herring in my case, thank you for the advice about /tool sniffer quick interface=<l2tp-user> it made things a bit more clear.
I’m a home user and I’m trying to setup Windows 10 access from the internet to my home network. The network is default hAP ac 192.168.88.0/24
Since I’m using local/remote address in the same subnet where everything else is I do not expect to need any special routers or nat. When I run /tool sniffer quick interface=<l2tp-user> and try to access a computer on the network from the l2tp client I can see packets coming from the client but no response. Client times out trying to reach the computer on the network eventually. I can ping mikrotik itself at 192.168.88.1 but nothing else. When I do that the sniffer shows packets in both directions. What am I missing?
That assumption is wrong!
The systems on your local subnet expect to be able to reach your VPN client directly and this does not work.
You need to put your client in a different subnet and then it will work.
Or you can enable “proxy-arp” on your LAN bridge.
Hey. I succeeded in getting routes from dhcp server with specific option via pptp server which was tunneled in strongSwan on ubuntu server. And I don’t know how to export routes by ROS… If you see some sence in this, try to read forums about dhcp via pptp on ubuntu.
I wonder if there is a way to do it automatically, with a DHCP option or something…
What I find interesting that the lease on 192.168.87.0 do not appear in the Leases tab of DHCP server in mikrotik… In a way it makes sense it does not look like Mikrotik DHCP server is used at all for giving out that IP, but if not, then how are these IP(s) are assigned?
Yes this is what I referred to earlier: the problem of setting specific subnet routes on a PPP VPN.
PPP does not use DHCP. The address is assigned (either directly on the user or via a pool) statically to the connection.
With Windows, after this a DHCP request is made which can retrieve other info like subnet routes, DNS server, etc.
So you can additionally setup a DHCP server on your L2TP server interface and put the appropriate DHCP options in its network.
This DHCP server needs no pool, but it has the other usual settings.
To construct a subnet route you need some handcrafting to make a DHCP option in hex. Probably there are some topics about it, as I said I have no personal experience with this.
(I make VPN tunnels between routers and so I do not need to worry about this, I can use protocols like BGP for it)
So I tried that as well and it also worked - thank you so much! I have a few more questions though.
Are the any side effects of enabling “proxy-arp” on my LAN bridge? That is is there any reason why I do NOT want to do that? I have a second subnet at home for VMs that are hosted on a VM server and second mikrotik router. It is probably too vague without a diagram, but generally speaking is this a potential for problems?
If this set up is for a single person, that is me, then I probably can instead of remote-address=tp-pool for /ppp profile use something like local-address=192.168.88.109 remote-address=102.168.88.110, and then instead of proxy-arp just add /ip arp add address=192.168.88.110 interface=bridge published=yes. Will this work? Are there any disadvantages? What will happen if I try to login from another machine if I already have a connection up elsewhere?
If I want to give access to my network also to a friend, then I will need to set up a separate secret for him, but the /ppp profile can be the same, in this case I still need pool instead of a single remote address. I should be able to use the same local address, right? If I use a pool, I can use rather short one, say 10 addresses and then add all these 10 addresses as published arp. Will this work? Is there any downside?
Finally, currently I’m working to enable access from windows 10 machine. I do not care about windows 7 or 8 or other flavours, but I do care about linux and mac clients, because I’m frequently using these too, so when I’m satisfied with the windows setup I’m going to move on to testing that it also working for linux and mac. Is there anything that is likely not to work for those? Is l2tp best choice?
I did not choose sstp because it would require a trusted CA cert installed in certificate store on windows client, and this is not something I’d like to deal with. I did not choose OpenVpn because of sub-par performance and also because of the certs I’d need to lug around. So l2tp felt like the most obvious choice.
The disadvantage of proxy-arp is mainly that it causes all ARP requests to reply with the router address, and so internal (to your LAN) traffic can end up being “routed” and this can load your router or reduce the performance of that traffic (e.g. when you have a fileserver and workstations exchanging a lot of data, which would normally be direct).
Indeed putting single ARP entries in the router is going to solve that.
You do not need to use a pool. You can set a “remote address” in the PPP secret for every user and it will be the fixed IP for that user on the VPN.
Note that this means the connection will fail when the same user connects more than once (from different device, or because the link fails and they quickly re-connect before the router has noticed that the previous connection actually failed).
“VPN that always works for everyone” has been a dream for decades. Because VPN has suffered from “The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year’s model” (famous quote from Andy Tanenbaum), the whole VPN scene is now a big mess and you can find several topics on this forum from people asking for the implementation of yet another VPN protocol.
Actually, that shouldn’t happen. The router only replies to arp requests for addresses it knows aren’t local, but the requesters obviously don’t (or they wouldn’t ARP for them). It should not reply to requests for local addresses, unless it’s explicity told to (with something like ‘ip local-proxy-arp’ in Cisco-speak).
Unfortunately it does not work that way. I replies to all ARP requests for which it knows a route (including local) and what happens then is depending on timing and behavior of the clients.
E.g. when the server is quicker to reply than the router, the client may overwrite its arp table entry with the reply from the router.
There is a separate local-proxy-arp setting but it does the inverse of what you want it to do in this case.
It would be nice when there was a setting for ARP that says “reply only to ARP requests with an IP inside the local subnet for which you have a more specific route than the LAN route” but unfortunately it does not exist.
Oi. That’s not according to standard. RFC925 (‘Multi-LAN Address Resolution’, which describes what is, in effect, proxy ARP, even if it isn’t called that) says:
'When an ARP query is broadcast by any host the BOX reads it (as do
all the hosts on that LAN). In addition to checking whether it is
the host sought (and replying if it is), the BOX checks its cache of
IA:HA address mappings in the cache that it keeps for each LAN it is
attached to.
Case 1: If the mapping for the host is found in the cache for the
LAN that the query came from, the BOX does not respond (letting
the sought host respond for itself).’
(Italics mine). That’s how Cisco IOS does it (the only platform I’ve ever needed to use it). RouterOS simply always responds, as if ‘ip local-proxy-arp’ were configured? That’s a) bad, and b) not how I I read https://wiki.mikrotik.com/wiki/Manual:IP/ARP#Proxy_ARP. But if that’s how it works…
The wiki page describes a scenario (with two networks) that works with proxy arp, but it does not explicitly tell you that this same ARP reply is sent for requests INSIDE the network.
The Linux documentation does tell you that the setting proxy arp will cause the router to reply to ALL ARP requests.
The local-proxy-arp option does the same but only for ARP requests with a destination address inside the same subnet. But still it replies to ALL such ARP requests, also for systems that can reply for themselves.
The maintainers are probably reluctant to change the proxy arp behaviour because that would misteriously break many setups with VPN users inside the subnet (similar to what the topic starter has), even when it would be more standards-compliant.
But it would be really useful to have a local-proxy-arp option that replies only when required in such cases, i.e. when the router knows how to forward traffic to that IP address without using the directly connected route for the subnet (for which it can be assumed that other systems have it as well).
Note that local-proxy-arp was not intended for this, it was intended for cases when the local network does not support broadcast so the clients cannot hear eachother’s ARP requests.
(e.g. in access networks where the maintainers want to save IP addresses)
Note that it is possible in RouterOS to control the ARP handling in more detail by using bridge filters.