Page 1 of 1
Do NOT NAT via the physical interface
Posted: Fri Feb 16, 2018 9:44 am
by gardner
Hi there SoftEther Forum.
I'd like some help please. I've gone through the docs and the server manager software several times and haven't been able to make this work.
Our setup is that we want attribution to which client does what on the LAN when connected via the SE VPN software. As such, we do NOT want to NAT all traffic from the client IP addresses assigned via each Virtual Hub when they access recourses on the LAN.
Take for Example DNS logs. We want to see the query logged against the CLIENT IP address and NOT to see all queries coming from the SE Server to be logged as the IP address of the physical NIC.
I'm VERY impressed with the technical capabilities of the software, thanks!! I'm sure this is possible and I've just not found it yet.
Something that MUST also be enforced at the same time is that traffic CANNOT route between Virtual Hubs. Our intention is to hand out a Virtual Hub to each user group that will be accessing the VPN. We CANNOT allow traffic between these groups. Clients from any Virtual Hub should be able to access any resources on the LAN however, that have been allowed through a local FW on that network.
Thanks in advance for your help!!
Re: Do NOT NAT via the physical interface
Posted: Fri Feb 16, 2018 10:11 am
by cedar
Please use access list.
Re: Do NOT NAT via the physical interface
Posted: Tue Feb 27, 2018 8:13 pm
by gardner
I'd just like to post an update to this as I managed to get it working and I figure if someone else is looking... here's the answer.
In order to achieve what I was looking for you need a Virtual Hub for each "group" of users that will connect to the VPN and receive IP addressing with a given range. You need a "LAN" Virtual Hub, which will effectively just communicate in and out of the SoftEther stack, with your LAN or whatever else you have on the "back" of your SoftEther server (the internet?). Lastly, you need a L3 Switch that sits between them.
The Virtual Hub/s facing the user group/s connecting in will use the SecureNAT function for issuing DHCP addresses. you'll also need to modify the default route pushed by this SecureNAT to the clients, or it will be VERY VERY slow!! Setup the Virtual Hub as you'd expect. Setup the DHCP within the SecureNAT section and either accept the IP address allocated on the top left, or modify it to another within your network. I used .1. Then where it has the button to view/modify the routes pushed to clients, edit this route or all traffic sent back to the Hub, you want it to go to the L3 Switch, where it will be routed to your LAN (or whatever is behind your VPN server). We'll create this interface last, it's on the L3 Switch.
Next, create the Virtual Hub for your "LAN" or "back" side of your VPN. You don't need SecureNAT on at all for this.
You will need 2 x Bridges. One of these will use a New TAP device and the other will be to a Physical Interface on your Server, the one that "faces" the LAN, or "out the back". If you have more than one "group" you want to assign unique DHCP ranges to, you'll need multiple TAP bridges, one for each group.
Next, a L3 switch. Give this an interface on the Virtual Hub facing your client group/s and one on the interface facing your LAN. I used the .2 IP address for each just to keep things simple. For the Virtual Hub facing your client/s you need to use the same iP here that you modified the default route to be in your Virtual Hub SecureNAT setting. Don't forget to start the switch.
That's pretty much it really. When a client connects, it's pushed the default route (or any specific routes you've created) of the .2 or L3 switch interface. This is naturally through the tunnel given the way it's setup so the client sends it's traffic for the LAN to this interface. The L3 switch then routes the traffic out the back because it has a "directly connected" network on that subnet. It ROUTES it though - it doesn't NAT it. This means that on your LAN you can now create FW rules between zones and filter using the CLIENT IP address ranges that you hand out on the Virtual Hubs using DHCP!! #granularity #control :)
The only other thing you need to do is on your local Network router or servers if you don't have a big network and that is to add a route (or routes) to the client subnets, via the L3 Interface IP address that's "facing" your LAN. In my case, I'm talking about the .2 interface on the LAN side. This is so traffic is routed correctly BACK to the client that sent it in. To keep things simple, you can assign all /24 networks to your Virtual Hubs for your various groups connecting in that you want to have different access in your back-end. Then, if you've used 10.0.0.1/24 and 10.0.0.2/24 you can easily pick all of these client groups up with a single 10.0.0.0/8 route on your Router or Servers (for smaller networks) and send that to the .2 interface on the LAN side of the L3 virtual switch.
If you have trouble because I missed something, or I've been too vague, reply here and I'll do my best to steer/help you.
Done!!
## I have a question now ##
One question I do have, for anyone reading this that has the answers... (someone from SoftEther team?) Why does the SecureNAT change from using a SUBNET to using NET30 when configured like this??! I have the DHCP range on SecureNAT set to 10.0.1.10 - 10.0.1.200 which is all part of the /24. When I connect my client though, I see the setting pushed is a "Net30" and the IP addressing is exactly that - I get an IP of 10.0.1.13/30 with the SoftEther server being the .14 of that /30. If I connect another user from the same group, they get an IP of 10.0.1.17/30 with the SoftEther server being the .18 of that /30. This is HUGELY inefficient as it consumes 4 IP addresses each time a new client connects from that group. One for the network, one for the client, one for the server and a broadcast for that /30. Rather than just assigning a new IP address from the DHCP range specified and the Server IP being the Virtual Hub interface (.1 in my case). I want to use a SUBNET if possible, not NET30. I'd REALLY REALLY appreciate a way of doing that!
Thanks in advance!
Re: Do NOT NAT via the physical interface
Posted: Wed Feb 28, 2018 9:24 am
by cedar
PPP based protocols like L2TP, SSTP are not compatible with general IP subnet.
SoftEther VPN solves this problem by placing a virtual router in front of the client.
This router acquires two addresses from the DHCP to separate the IP address presented to the virtual HUB side and the IP address presented to the client.
(I would be happy if someone writes a PPP handler that can handle the broadcast smarter.)