1.2.3.4 needs to be substituted by the actual WAN IP of the router. By default, Windows clients refuse to connect to servers that indicate a different IP address than the one to which the client connects, i.e. those behind a NAT at server side. So the IPsec responder and L2TP server must listen at the public address, but at the same time we need that the incoming traffic was pushed through the tunnel, so we have to dst-nat it twice - to an auxiliary address (10.0.15.254 in the example) and then back to the original one(1.2.3.4 in the example). (NB - during those four years I have learned that the same effect can be accomplished another way, but it does not simplify the overall concept, at least not enough to be worth modifying the example).
In the example, a range from 10.0.0.1 to 10.0.15.253 is used to provide a unique address for each client, and 10.0.15.254 is used for another internal purpose. This must be a range that is not used anywhere inside your network; if the only subnet you use is 192.168.88.0/24, you can stick with 10.0.0.1-10.0.15.254. If 10.0.0.0/20 or a part of it was used in your network, you would have to use any other non-conflicting range of private addresses instead. The script row in particular ensures a rollover from the highest address in that range back to the lowest one (with each new connection attempt, the address is incremented by one, so after 4091 connection attempts it reaches the end of the range and needs to start from the first one again).
I didn’t know I was starting a thread, I was thinking I was posting an article 