Lee, do you mean set the DNS to the LAN IP (in my case 192.168.1.1) on the Client side (i.e. overwrite the server's DNS via Network Settings in Windows)? Otherwise I couldn't find a way to manually specify a DNS server to hand out via the L2TP server - SmallWall just handed me the default L2TP server address IIRC as the DNS server.
I'm not sure but it seems like I'm making progress. By moving the L2TP server and range off of the LAN subnet (ex. LAN = 192.168.1.x/24 and L2TP now 192.168.2.x/24), I'm now seeing firewall activity where the 192.168.1.x network is being blocked going to an L2TP client on 192.168.2.x, EVEN THOUGH I have tried varied and numerous Firewall rules on both the LAN and L2TP interfaces.
Here's a log example of blocking DNS and a blocks the L2TP from getting to smallwall port 80 (tons of these btw):
If Source Destination Proto L2TP 192.168.1.1, port 53 192.168.2.24, port 58169 UDP L2TP 192.168.1.1, port 80 192.168.2.24, port 56101 TCP
I have ONLY the following 3 firewall rules in L2TP VPN:
Proto Source Port Destination Port Description
* 192.168.1.0/24 * 192.168.2.0/24 *
* 192.168.2.0/24 * 192.168.1.0/24 *
* * * * * Default L2TP --> Any
And the following TOP rules in LAN: Proto Source Port Destination Port Description * 192.168.1.0/24 * 192.168.2.0/24 * * 192.168.2.0/24 * 192.168.1.0/24 *
I would think that should cover any aspect of LAN needing to get to L2TP and vice-versa.
I'm really hoping we can get this to work or at least discover a fixable bug in the process!
Yes, the connected client got the IP: 192.168.2.24 L2TP Server: 192.168.2.1 Remote Range: 192.168.2.24/30 (4 addresses)
I'm on the west coast. We can try team viewer if you'd like.
BTW, I was reading back through ky41083's reply. I have his steps here modified based on his last response:
- Connect via L2TP/IPsec - Assign interfaces, add new interface bound to network port l2tp1 (or l2tp#) - Add permit all firewall rule for new interface - Enable new optional interface, bridge with LAN - must enable advanced -> Bypass firewall rules for traffic on the same interface, also, for this to work - Reboot - Add static route for new interface, destination network same as L2TP subnet, gateway same as L2TP server address, done.
This *should* be done automatically for every new dynamic L2TP interface (user) created, inheriting the rules from the main L2TP interface. It isn't. Something for the devs to do ;-)
Completely fixes L2TP/IPsec access to the firewall itself.
I believe he means he's doing this all through SmallWall. The only thing I don't understand is how he's adding a new interface? I see he said to first connect via L2TP, which I can, but I cannot get back to SmallWall to check if there's a new interface. Does connecting to SmallWall via L2TP spin up a new "virtual interface" and thus, that's how he's "adding a new interface" and bridging it? I'm lost on how that's even possible.
BTW, I did try adding a static route on the LAN interface as:
Update. I am now able to get to the internet once connected to SmallWall via L2TP in Windows 7.
Interestingly enough, here's what allowed connecting to the internet:
1. Windows -> Control Panel\Network and Internet\Network Connections, Right-Click the L2TP VPN connection you created -> Properties 2. Networking Tab -> Highlight Internet Protocol Version 4 (TCP/IPv4) -> Properties 3. Click the Advanced button on the "General" tab 4. Uncheck the "Use default gateway on remote network" 5. Reconnect and try to get to some webpage. I was successful with just that setting as the only change and I can repeat it by re-checking it again = no internet connectivity.
Also note, the Windows LT2P connection has the default "Obtain an IP address automatically" and "Obtain DNS server address automatically" enabled. I.e. I have no client-side DNS servers specified, both are coming from SmallWall.
Keep in mind, this differs from my working PPTP connection. PPTP works with the default setting of "Use default gateway on remote network" checked. So, there is a discrepancy between PPTP and L2TP client settings there.
I am still unable to reach the SmallWall interface (192.168.1.1) on port 80.
I'm thinking there's a bug in all this or some type of misconfig somewhere.
I am SURE there is! But finding it...
When you uncheck "Use default gateway on remote network" you are telling your Windows box to use the local network at home for anything no 192.168.2.x so you get to the Internet, but not the other subnets.
I am not sure why he felt a need to add static routes, as they should be built dynamically. You can see it in status.php on your firewall.
Lets see if we can get together. Alternatively, if you want to give me credentials to your firewall I can look remotely.
Okay, well let me know when a good time for you is and we can try TeamViewer. I can't help but think part of the key to this not working is because smallwall is blocking some traffic (ex. port 53, 80) coming from the LAN interface (source) 192.168.1.1/24 to the L2TP subnet 192.168.2.0/24 (destination) over the L2TP interface - even though I have explicit rules (going both ways) on the LAN and L2TP interfaces. Even though this is the case, I can still ssh (port 22) to an internal LAN host but not connect to that same host via port 80. All this just appears to be some type of firewall bug when an L2TP connection is active. Also, when I put the L2TP subnet within the LAN like you mention in the docs in hopes to stop the firewall blocking behavior; I see nothing in the firewall logs, but behavior is the same.
Did you want me to send you my configs or status.php output or anything else I can so you can see if anything is obviously wrong?