We have a customer that has a HQ location with a Mikrotik. There are two remote locations that also have MT routers that connect back to the HQ location with persistent site-to-site VPNs. This has been in place and working for sometime.
On the HQ router there are two PPTP Server Bindings, one for each site. They each have their own secrets and profiles with nothing specifically unique about them. We will call these VPN-A and VPN-B. We will call their respective profiles VPN-A-Profile and VPN-B-Profile.
Also, on the HQ router there are multiple physical ports in a LAN Bridge and the gateway IP is assigned to the LAN Bridge.
We are trying to setup user VPNs that use RADIUS. The ultimate goal is for users to VPN to the network and their PCs act as thought hey are physically on the same LAN. They have some software that rely’s on layer 2 so standard layer 3 routing likely won’t be sufficient.
We will call this VPN-User. So what we did was create a new custom profile (VPN-User-Profile). The local address is the HQ LAN gateway (10.0.0.1) and the remote address is a pool on the same LAN. (10.0.0.245-10.0.0.254). It is set to require encryption and to allow multiple connections. DNS is the HQ DNS server. On the PPP Profile we also added the profile to the LAN Bridge. Then on PPP > Interface > PPTP Server we set the default profile to the VPN-User profile.
What we have found is that when VPN-A is connecting in it is actually adding the VPN-A server interface to the bridge for some reason. It is strange because VPN-A is using the IP addresses defined in VPN-A-Profile. VPN-A-Profile does not tell the VPN-A server to use the LAN bridge. So for some reason VPN-A is using some settings from the VPN-A-Profile and the bridge settings from VPN-User-Profile. Even stranger, VPN-B is not adding it’s interface to the bridge.
This was causing some odd behavior on the network so we had to roll back. The way I see it I have a couple options…
A. Figure out why VPN-A is adding itself to the bridge and resolve it so user’s can VPN in and be added to the bridge. Maybe this is not the correct way for this to be done? Any advice on this would be appreciated.
B. I have read that Proxy-ARP is another way for VPN clients to act as thought hey are on the same LAN as the HQ. We had an instance where proxy-arp was not setup properly and it caused issues so I tend to avoid it but I am open to this option. My question to this would be Should we enable proxy-arp on the LAN Bridge or on each physical interface within the LAN bridge, or both?
What is the best way to address this and do you have any thoughts on the described issue?
Thank you in advance!
I’ve created a common layer 2 network only by placing a MikroTik in front of each remote user. I leverage L2TP and IPSec the connect and establish well known IP addressing. I them build an EoIP tunnel to stretch layer 2 via a WLAN and the local LAN ports. The end-user has to plug the WAN port physically into an Internet connection. I have a LAN port setup to NAT as well and that be used to connect to most hotel WiFi portals.
It’s not pretty but it works. In theory GRE supports broadcast and multicast. I believe IKEv2 supports multicast. Those are avenues you could pursue. MikroTik doesn’t have a layer 2 protocol like Cisco has to support broadcast over multiple GRE tunnels (NHRP for DMVPN).
With hap lites costing roughly 20 USD and us not having a ton of users that needed this it was a solid solution that just works.
Either way Proxy ARP isn’t your ticket. That feature tells the router to reply to an ARP request for any IP within it’s routing table on that interface. If your traffic is broadcast it’s not going to ARP and therefore not care whether Proxy ARP is on or off.
I would love to give each user a tik to take with them but unfortunately, I think that would be too much. If proxy-arp is not the answer then why do so many guides advise to use it with road-warrior VPN’s?
It enables layer 3 connectivity to work when you use overlapping address space. Think about the process.
Architecture:
Your LAN Network: 192.168.88.0/24
Your PC VPN IP: 192.168.88.21/32
Your MikroTik VPN IP: 192.168.88.22/32
A local server on the LAN: 192.168.88.31/24
Problem: You want to access the local server on port 80 from the PC connected via VPN and the MikroTik is set to perform proxy ARP.
The route table on the MikroTik would look something like this:
A connected route for 192.168.88.0/24
A connected route for 192.168.88.21/32 and .22/32
Step by step of a port 80 request from the PC on the VPN:
The PC on the VPN routes the request directly to MikroTik VPN on it’s server interface. This is because the request to 192.168.88.31 matches only the default route. The route directly from the VPN connection is a /32.
The MikroTik receives traffic sourced from 192.168.88.21 to 192.168.88.31 and routes it out LAN accordingly.
The server receives the request and prepares the reply. As it starts to reply it thinks it needs to ARP for the MAC address of the 192.168.88.21 host because they are on the same network, 192.168.88.0/24 (from it’s interface configuration).
The MikroTik replies to the ARP request on behalf of the VPN client because of Proxy ARP because it has an entry in it’s routing table that matches the IP requested.
The MikroTik then receives the IP packet because it’s MAC address was given out during the Proxy ARP process and it forwards it using the more specific /32 route in it’s routing table.
You’ll see this works for unicast traffic. Their is no way it helps broadcast or multicast traffic.
Also, I do not recommend using overlapping address space for your remote worker VPN connections. I strongly encourage folks to use non-overlapping address space as this does not require Proxy ARP to work. By adding Proxy ARP to your network you can mask other problems with it’s “magic.” Also, it is viewed as a bad security technology as it can be used to determine what networks are connected to a router. This is because it will reply to an ARP request for anything that matches it’s routing table.
A last ditch effort, there is an EoIP implementation on Linux. If your VPN clients run Linux you could use a regular L2TP/IPSec road warrior VPN and build EoIP tunnels for each user on the Linux box instead of a dedicated MikroTik.
An additional very last ditch effort, local virtualization on each client that runs a CHR or Linux VM to perform the EoIP tunnel. Make sure you use virtual networks appropriately and you could make it so your PC gets an IP on the “LAN” side of the MikroTik via EoIP. You’d definitely want to move your VPN into a different IP scheme and disable Proxy ARP in this scenario.
That makes since. They are all Windows clients connecting on the VPN.
When you talk about non-overlapping IP blocks do you mean use an IP block for the VPN users that are in a different subnet? What we typically do is exclude a part of the LAN block for the VPN and set the local address to the same as the router. Then we create a source NAT loopback rule. For example:
Local LAN: 10.0.0.0/24
Local IP of tik: 10.0.0.1
DHCP servers out: 10.0.0.100-10.0.0.200
VPN gets: Local address on tik is 10.0.0.1 and remote users get 10.0.0.240-10.0.0.250
Source NAT that is something like: If source address is 10.0.0.0/24 and destination is 10.0.0.0/24 then source NAT to 10.0.0.1
This generally allows our road-warriors to connect to the VPN and communicate as though they are on the same LAN.
Are there downsides to doing it this way?
Also, as I mentioned in my original post, on the VPN I setup for the users I set the profile to add the VPN interface to the bridge. Is this a bad idea? And when I did so it ended up adding the wrong VPN to the bridge. It was very strange. It was using the bridge settings from the profile for VPN-Users but the IP addressing from the site to site VPN profile. Any thoughts on why it would of pulled the wrong VPN server interface into the bridge?
I’ve never tried adding the VPN interface to the bridge so I can’t say. Yes my preferred setup is to place VPN users on a different network say 172.16.254.0/24 in your case. This removes the need for Proxy ARP to talk to the 10.0.0.0/24 hosts. It would not be fun to have the server side interface added to the bridge though if different addressing is in use.
Ahh seems its possible with BCP within PPP. Not sure if the built-in Windows client supports BCP but that’d be your ticket.
Not sure why it’s not adding the correct interface though.
Neat. Is PPTP supported in Windows 10? Might want to look at L2TP/IPSec from the start as well.
Yes, PPTP is supported. Thank you!
Cool, it is at least theoretically exploitable if that matters. L2TP supports BCP as well it would seem at least on the MikroTik side.
Yes, I understand the risk, and we use L2TP often. For this particular setup we are replacing an existing PPTP are avoiding reconfiguring each user’s setup. Previously they passed the VPN to a Windows RRAS server that passed to a NPS server, both of which are getting decommissioned. Do I am doing what a network person does… Moving the VPN to the router:)