Router in front of SonicWall
Hello,
I have been working on a project using a SonicWall TZ400 (6.5.4.11-97n). Every thing is working fine with SSL VPN going through port X0 to a 192.168.0.0/24 network. Nothing to see here!
Now I have to add a router in between the SonicWall and our LAN. I have been learning to speak "SonicWall" for a week and I may need a little guidance. Here is a photo of the setup to install:
Here are my thoughts for changing the current setup to allow for this new router:
Create a network Access Object :
- Name: Current_LAN_Subnet
- Zone Assignment: LAN
- Type: Network
- Network: 192.168.0.0
- Netmask/Prefix length: 255.255.255.0
Create a Route from X0 to the LAN:
- Source : Any
- Destination: Current_LAN_Subnet
- Service : SSL VPN
- Interface: X0
- Gateway : 0.0.0.0
Create a NAT policy:
- Original Source : Any
- Translated Source: Original
- Original Destination: Current_LAN_Subnet
- Translated Destination: X0 IP (192.168.100.2/30)
- Original Service : SSL VPN
- Translated Service: Original
Create Access Rules:
- From : LAN
- To: LAN
- Source Port: Any
- Service : SSLVPN
- Source : Any
- Destination: Current_LAN_Subnet
Client Settings: Default Device Profile
- SSLVPN Range (192.168.0.231-192.168.0.240) (original assignment from original setup)
Client Route:
- X0 Subnet
There are already access rules in place that were created automatically and it looks like I can just modify those to achieve my tasks, however the subnets attached to X0 have changed and I need to reach the Current_LAN_Subnet. Am I on the right track here? Any suggestions would be greatly appreciated as I am still learning SonicWall speak. I am preparing this configuration in advance so I can setup and test, possibly need the packet monitor to see where an issue may occur (I know how to use the packet monitor).
Best Answer
-
CORRECT ANSWER
MustafaA
SonicWall Employee
Create an Address Object for the SSLVPN IP Pool with Zone Assignment as SSLVPN. For instance;
1
Answers
@Eddie I'am a bit confused, this looks like a standard scenario when LAN is behind a Core Switch etc., which is a router at the end of the day.
You just need a Route for 192.168.0.0/24 pointing to Gateway 192.168.100.1. Your router needs a default route to 192.168.100.2.
That's IMHO it, don't see any reason for more configuration if your existing Access Rules and SSL VPN configuration already cover 192.168.0.0/24. That's the reason why I never use the built-in objects like "X0 Subnet", just create your own object like above and use it.
--Michael@BWC
Hi @Eddie , here are my inputs for this config.
Thank for your suggestions, I will apply them here soon and let you know.
The current setup allows Internet access and has been tested, it is ONLY the SSLVPN that is not seeing the local LAN. We are using 192.168.0.231 - ...0.240 as our upper IP range currently and have that blocked off by our DHCP server so there is no overlap.
I was also concerned about the Gateway set to 0.0.0.0, but 192.168.100.1 does sound more direct and appropriate. I will follow up here soon once I can implement this strategy and test!
@Eddie , even if you have the SSLVPN IP Range blocked off by your DHCP server, still as best practice use a completely different subnet/IP Range.
Which is of an interesting topic. By the instructions of SonicWall SSLVPN setup, I must use an IP range directly related to my LAN to access my LAN resources at 192.168.0.0/24? Is this not the case? I would love to be able to assign a different IP address to the Client.
As mentioned before, I inherited this and currently the SSLVPN is working perfectly without the insertion of the router. Please advise on how I may assign a Client IP address different from my local LAN..
Wonderful! I will try this along with the above implementation. I am guessing that when you introduce the Client Routes, that is the option that gives clients access to those exact resources.
The Client Routes is required to push the defined subnets as route policies to the remote host. You can check this on the remote host with the "route print" command, before and after SSLVPN connection.
The subnets defined for the user under the "VPN Access" tab, is related to giving access permission(s).
Ok, testing now and the SonicWall is receiving my packets, my NetExtender is sending packets, but it appears the packets are not making it to the X5 Interface: no Egress
Here is my current config:
Access Object :
Static Route from X5 to the LAN:
Client Route:
User VPN Access:
The Access Rules are automatically created:
If I use X5 Subnet, all packets are dropped. When I use the AUS_Lan_Subnet, packets are received, but do not seem to make it out the X5 port.
I see on my Interfaces page, that X5 is the only port that does not have the "checkmark" to show enabled, yet I have Internet access.
Any ideas would be greatly appreciated. Moved away from the X0 port for testing purposes and I do not mess up our current config and access. This should not be an issue.
Update:. When I set my Client Route and User/VPN Access both to "X5 Subnet", my packets get dropped by a policy, but I am not sure how to determine the policy in question:
@Eddie , your Static Route is configured only for SSLVPN Service (assuming the service object has only the SSLVPN port), and the traffic that you have on the Packet Monitor is for DNS traffic.
Yes and X5 should be sending out the DNS or any traffic as my user has logged into the SSL VPN service, I should see something sent to the X5 egress port. I am thinking that I deselect the SSLVPN service (set to ANY) in my static route to allow ALL traffic....still testing.
Ok, some more testing and now it looks like I have traffic forwarded, still not received. Here is my current config and results:
Client Route - AUS_LAN_SUBNET (192.168.0.0/24)
X5 Subnet (192.168.100.0/30)
User VPN Access - AUS_LAN_SUBNET
X5 Subnet
Route -
Source: SSLVPN Range
Destination: AUS_LAN_SUBNET (192.168.0.0/24)
Service: ANY
Interface: X5
Gateway: Router_Gateway (192.168.100.1)
Rules/Access Rules : Auto-Generated
Here is my current packet capture:
I am not forwarding out the egress port X5 now, towards the router. I have yet to see a "Received" on my packet captures so I am guessing this is "working". I still can not ping the above destination addresses of 192.168.0.40 , x.x.x.45, x.x.x.46, etc. Anything you see with the above configuration that would note any network discomfort for a SonicWall? I went ahead an used both networks for VPN Access and Client Routes, did not seem to hurt, but I do need to be sure that my destination is the AUS_LAN_SUBNET (192.168.0.0/24). I have tried to just use the "X5 Subnet", packets do not get forwarded out the X5 egress port.
@Eddie , what is your SSLVPN IP Pool? What is the source IP 192.168.0.221?
The source IP is the SSLVPN Range. As the VPN is a virtual appliance from within the SonicWall, all SSLVPN users are assigned an address range of 192.168.0.221-192.168.0.240. This is how it is working now. I tried to use 10.10.10.0/24 as suggested, but external users could not access the local LAN.
SSLVPN IP Pool is 10.10.10.0/24. This was your previous suggestion to use a different IP range, local test worked, but my users could not connect to the local LAN, I had to change it back. This can be tested further later as this is not important right now.
SSLVPN Range is 192.168.0.221 - 192.168.0.240. This is what is working now. So I am sticking with this scheme until I can get my users to the local LAN. Currently they are logging into the SonicWall, get an IP address of SSLVPN Range, then accessing the local LAN directly connected to X0. I am using X5 as my test port with a router in front. Are you thinking that my Source IP is not correct? I did finally get packets to be "forwarded" to X5 and I am checking my router now (Ubiquiti EdgeRouter) to completely open its firewall rules. The Internet works fine using this router, just not the SSLVPN Service.
Update: I have set my router to routing only as below:
LocalPCLAN = 192.168.0.5
Router = Eth1 (192.168.0.1) router gateway
Router = Eth0 (192.168.100.1) router to firewall
Firewall Port X5 = (192.168.100.2) firewall
===================================================
The firewall is only allowing traffic from the 192.168.100.0/30 network (X5 IP = 192.168.100.2/30). I need to allow 192.168.0.0/24 network through. So having a little bit of an issue determining the Access Rule necessary, here is my current config:
AUS_LAN_SUBNET = 192.168.0.0/24
I want to allow any traffic from the LAN destined for the X5 IP of 192.168.100.2. I have a default route at my router of 0.0.0.0/0 -> 192.168.100.2 (gateway) so all traffic is routed to the firewall X5 interface. Right now, I can not ping the X5 IP (192.168.100.2) from my localLAN.
I would think that the Interface Trust rule that automatically installed would work,
But packets are not allow on X5 from 192.168.0.0/24
Here is another trace, the SonicWall is dropping my ICMP and DNS packets at X5, which is all I am really sending at the moment:
Anyone available today? I think I have the final key, just need to know how to let the traffic pass/accept from the AUS_LAN_SUBNET (192.168.0.0/24) network through X5.
So when I enable my NAT on the router, of course the IP address is changed to the same X5 subnet (192.168.100.0/30), traffic passes just fine. But when I disable NAT, traffic is dropped because I have no Access Rule, but I have been trying to make an Access Rule to allow this traffic to pass, but to no avail. Anyone have an idea? It may be a Route as well since if there is no route, a packet can be dropped as well.
Resolved. I was going in circles due to the need to "RESTART" the SonicWall after making certain changes. Access Rules and such were remaining and often I would lose Internet access. I reloaded the original configuration and started over from Step 1, after making some configuration changes, restarting the SonicWall at each set of changes. This apparently was the key and why I could not get a stable working environment.
I did however needed to make 1 particular change. As I added a router between my LAN and the SonicWall, this KB was initially helpful:
The key change was setting my SSLVPN IP addresses to the following: (they were previously work fine as long as my LAN was directly connected)
Now we have SSLVPN working again along with Internet access. All is good now.
Glad to read that the issue is resolved, @Eddie .