marc
Junior Member
Posts: 10
|
Post by marc on May 25, 2018 1:07:57 GMT
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.
Thanks in advance, Marcus
|
|
|
Post by Lee Sharp on May 25, 2018 3:58:20 GMT
Yes. One place I have it working well is a client with Active Directory so we manually put the AD servers in there anyway. Just something to try...
|
|
marc
Junior Member
Posts: 10
|
Post by marc on May 25, 2018 19:49:20 GMT
Lee,
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!
Any ideas? Marc
|
|
|
Post by Lee Sharp on May 25, 2018 20:33:47 GMT
Is 192.168.2.24 the client or the gateway? Where are you located? It might be easiest to use TeamViewer to look at this... It can be hard to translate settings.
|
|
marc
Junior Member
Posts: 10
|
Post by marc on May 25, 2018 20:52:52 GMT
Lee,
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:
Destination network: 192.168.2.0/24 (my L2TP subnet) Gateway: 192.168.2.1 (my L2TP specified server address)
I have Enabled Bypass firewall rules for traffic on same interface checked too.
I still can connect via L2TP with these settings, but same results, It's blocking port 80, 53, etc. I can't get to internet or SmallWall.
<Since adding the Static Route didn't change anything, I removed it and am back to the default of no static routes configured>
Worth a try though, again.
|
|
marc
Junior Member
Posts: 10
|
Post by marc on May 25, 2018 22:23:40 GMT
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.
Progress nonetheless.
|
|
marc
Junior Member
Posts: 10
|
Post by marc on May 25, 2018 23:15:37 GMT
Hopefully last update for you today. I'm thinking there's a bug in all this or some type of misconfig somewhere. I experimented w/ the client-side L2TP setting I mentioned above " Use default gateway on remote network". Given: I have a raspberry Pi server on the LAN at 192.168.1.159 (L2TP Subnet is still 192.168.2.0) that runs a web server and allows SSH When connected via L2TP with "Use default gateway on remote network" Unchecked: Internet access = YesSmallWall GUI (192.168.1.1) = NO Pi Server port 80 = NO Pi Server port 22 = NOWhen connected via L2TP with "Use default gateway on remote network" Checked: Internet access = NOSmallWall GUI (192.168.1.1) = NO Pi Server port 80 = NO Pi Server port 22 = Yes
I'm hoping this might make sense to you since you know the internal workings
|
|
|
Post by Lee Sharp on May 25, 2018 23:27:25 GMT
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.
|
|
marc
Junior Member
Posts: 10
|
Post by marc on May 30, 2018 17:06:01 GMT
Well, that bums me out 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? Thanks for you help, Marc
|
|
|
Post by Lee Sharp on May 30, 2018 18:55:18 GMT
If your e-mail address is correct, you have an e-mail from me. Let's see what we can do.
|
|