Remote Access L2TP with internal DHCP-Server does not work

Hi, aktronic, and welcome to the User BB!

It won't work like that.  You should not use the same subnet for a VPN pool as the internal LAN subnet.  Put the standard "VPN Pool (L2TP)" definition back in and use that in the L2TP over IPsec definition. 

You also must complete the 'Advanced' tab in Remote Access to set the DNS servers. 

Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

But I dont want to use that IP-Pool. I want to use the DHCP-Server function, so that the VPN-Client also gets all internal routes. 
The feature of using that DHCP-Server selection is broken, as long as it's using the IP-Pool feature too.

Hi aktronic,

You can use the DHCP Server function if you wish, what you can't do is use an IP subnet curently on another interface of the UTM. The limitation comes from how clients on a network talk with each other, and is part of the design of the IP protocol.

On a typical routed network there are local and remote subnets. A local subnet (for this discussion) is the subnet which a client device has an IP address on. A remote subnet is any other subnet reachable through a router (whether the default gateway or not).

When a device wants to send a packet it looks up it's routing table to see where to send a packet. For a remote subnet it sees which router to forward to and sends it along. If the IP is not in the routing table, it forwards it to the default gateway.

What happens on the local subnet is of interest to us. When a client device sees that the packet is bound for the local subnet, it literally just dumps the packet out the interface (network card) expecting that the destination device will see the packet and deal with it. The packet then bounces through one or more switches getting dumped at the interface (network card) where the IP address was last seen.

The problem with VPN clients using the same IP's comes in at this point. Any traffic originated by the VPN clients appears to come onto the network from the UTM's interface so switches route the packets back. Because the UTM's IP does not match the IP address of the VPN client, the UTM ignores the packet as "Not for It."

Long and short, you have to use a separate subnet for your VPN clients. If your network is built in such a fashion that the UTM is not the default gateway and the internal clients can't be 'trained' to know where to send packets for the VPN subnet, you can Masquerade (or NAT) the VPN clients so they appear to be coming from the UTM itself (which has an IP on the local subnet).

This is actually the very use case that I started my first production Astaro ASG router in. We used it as a VPN solution, then expanded to Email Filtering, now the dang things are everywhere. [:)]

yes, if I use a seperate subnet with ip pool it works. but this does not explain why the utm is using default gateway and DNS Server configured by ip pool instead of delivering those set by dhcp.

Hi Aktronic,

I'm not quite sure what you mean. Are you saying that when you use an external DHCP server for the pool, the UTM overrides the default gateway and DNS settings coming from the DHCP server with it's own?

Aktronic, have you filled in the information on 'Remote Access >> Advanced'?

Cheers - Bob

yes, I did. If I set the dns/wins on "Advanced" These values are used but the default gateway is set by the default ip pool networks 1st ip address (.1) although the ip address provided by dhcp is on a completely diffent network. It just does not use the values for dns and default gateway provided by dhcp, so it does not make any sense to use this dhcp setting at all.

As TheDrew explained so well, if you use the same DHCP for Internal and L2TP or just the same subnet, you'll never get this to work.  It can work with a different DHCP server that assigns a different subnet.

Cheers - Bob

Hi there,
the only solution that kann use internal DHCP Range for VPN clients is, TMG using internal DHCP. But TMG is dead. I think SSL VPN is the best solution to replace this scenario. With SSL VPN you can define which routes are delivered to the Client. Just add the internal subnets in the ssl vpn Profile.

regards
mod