Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 11960 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote Access L2TP with internal DHCP-Server does not work

aktronic
I switched on L2TP over IPsec and set "assign IP addresses by DHCP-Server" and entered the DHCP-Server which is on the same network as the internal interface of the UTM.

The VPN Client is getting an IP address out of the LAN subnet from our DHCP-Server but it gets the first IP of the default IP address pool as the default gateway  and the DNS Servers configured on the Remote Access/Advanced tab - not default gateway and DNS Servers configured in DHCP. [:S]

If I delete the VPN (L2TP) default IP address pool, I cannot set the IP address assignment to DHCP Server!
Error: The L2TP over IPsec connection object may not have an empty local address attribute.

This is ridiculous, why do I need a pool when I am using DHCP? And why does it use the wrong default gateway and DNS Servers when set to DHCP?

Firmware is  9.109-1 on ASG425.

Can anybody verify this?


This thread was automatically locked due to age.
Parents
  • 0
    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. [:)]
Reply
  • 0
    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. [:)]
Children
No Data
Unfiltered HTML