I’ve a simple roadwarrior (ipsec over l2tp) configuration on one of my customers MikroTiks and the customer want’s to assign the vpn-clients addresses through his windows dhcp server which is responisble for that in the whole network. (Of course it’s working on lan, wifi connected networks)
To be honest - in every other situation we distribute the adresses directly through MikroTik.
I’m wondering how to get this working?
everything is working fine with this “static” configuration but as we all know → The customer is always right
You can remove the local address / remote address part afaik.
If it’s a bridge, then no need for IPCP - just make it a bridge tunnel and nothing more. A pure bridge will forward dhcp requests just like any other broadcast (arp, netbios discovery, etc). Of course the client software will need to be able to use dhcp to get its IP address for the bridged interface… a Mikrotik can do this on the client side, but a soft vpn client may not…
If this is just because they want to avoid dhcp conflicts, then they just need to suck it up and reserve a small range of addresses for VPN endpoints and have done. There’s no need to be tying swallows to coconuts just so you can use European swallows to carry them around.
thanks for the hint. Tried it this way (to assign the ppp-profile to the “LAN” bridge) but then i get following message in the routeros log
19:17:45 l2tp,ppp,info <l2tp-admin.test>: terminating... - could not determine local IP address
Any other ideas?
My very first idea was also - as you told - to except a little range on the windows dhcp server for the vpn clients. But the customer thinks that everything has to be done by the windows dhcp.
BTW: recognized another problem - can ping the gw through the established vpn but no other resources… (same when i switch of the firewall - so couldn’t be that )
I’m trying to do something similar. We have a client with a multi-building campus. Using EoIP between the main routers for each building, we have set up one particular subnet that spans all three buildings, for use with applications that require a single broadcast domain.
Our client wants to add remote access to this network, to include offsite devices in this broadcast domain. So, we need some kind of tunnel that can join an existing bridge dynamically like EoIP, that doesn’t depend on ROS or additional software on the client side.
Found a solution. The tunnel isn’t truly bridged, which means you don’t get DHCP, and have to do a bit of a workaround:
Assign the bridge to the PPP profile
Carve out a section of the DHCP pool into a separate pool reserved for tunnel connections
Set the local address of the profile/secret to the router’s address on the bridge interface
Set the remote address of the profile/secret to the tunnel address pool.
On the bridge interface, set arp=proxy-arp.
Steps 2-4 mimic DHCP; Step 5 mimics a transparent bridge via the Layer 2 equivalent of a masquerade.
It’s too bad that assigning a bridge to a PPP profile doesn’t just create a dynamic port, like WDS. Or maybe the problem is that Windows and other systems don’t support the required protocols to make that possible, and ROS has to make the best of it. Either way, it’s a less than obvious solution to what must be a common problem.
What you just described is the way this kind of connection is normally setup (well normal for me and everyone I’ve met so far). the problem though is that client wants to pool to exist on the windows DHCP server it think.
To be honest I think the OP should go to the client and rather request a slice of the pool (get them reserved on the server) and do what you have just done but putting those addresses into the pool on the ROS for those outside connections.
