I dont need L2 transparency.
If so, let's stop thinking in VLANs and start thinking in subnets (although you likely follow the best practice, and use a dedicated VLAN for each subnet).
So you can create any kind of L3 tunnel, set up routes at Site 2 via that tunnel to all subnets at Site 1 that the clients at Site 2 need to reach, and set up routes via that tunnel at Site 1 to all subnets at Site 2 from which clients may connect to servers at Site 1. An exception is bare IPsec where you use traffic selectors rather than routes, but that's not for beginners anyway - in my opinion, L2TP/IPsec is the best way to start with VPNs. Plus you should not start with VPNs until you master the firewall.
In case of L2TP, you can add a list of destination prefixes, to which routes via the tunnel should be dynamically added once a client connects, to the
routes parameter of the
/ppp secret row representing the client. If you create your own
/ppp profile row (or more), you can specify an
interface list to which the virtual interface representing the client tunnel should be added, and an
address-list to which the address assignet to the client should be added, and use them in firewall rules to control which clients can connect to which servers at Site 1. On client side, the L2TP interface is static, so you don't need these tools and you can refer to the interface name directly, but you may want to add the address to an address-list if you use a pool for client addresses at the server side.
L2TP/IPsec will handle the issue that only Site 1 has a fixed address and can accept incoming connections (Site 1 must be the server). A drawback of LT2P/IPsec is that if multiple clients get NATed to the same public IP address and use the same port (like the Windows embedded VPN client does), only one of such clients will work at a time. But that should not bother you.