Tunnel Interface with two Sonicwalls and three subnets.
-
I'm trying to accomplish a non standard config so I can do some work at my shop in advance of on-site installation.
Here's the scope: I want to setup a new server for a customer while the server is still at my office. Customer site LAN is 192.168.1.0 My Office Lan is 192.168.2.0
I want to set up the new server (physically in my office) with a 192.168.1.x IP and use a Tunnel Interface to give it full access to the customer LAN.
I set up Tunnel interfaces all the time between two firewalls (almost always Sonicwalls) with no problem. In fact we have dozens of tunnel interface VPNs running all the time.
With a basic routed tunnel between my office and the customer office, the two lans 192.168.1.0 and 192.168.2.0 talk just fine. What I can't visualize in my head is how I set up the VPN (preferably without VLAN) so I can have 192.168.1.0 on EACH side and have them talk to each other.
My first thought was to just remove the routes and let the tunnel be a bridge. Would this work? and then I would set my gateway of the new server (on my side) of the tunnel to be the gateway at the other end? And internet access would be through the customer's ISP rather than mine?
If this is right, then it's true, I am simply over thinking this!
-
@JasGOt said in Tunnel Interface with two Sonicwalls and three subnets.:
I'm trying to accomplish a non standard config so I can do some work at my shop in advance of on-site installation.
Here's the scope: I want to setup a new server for a customer while the server is still at my office. Customer site LAN is 192.168.1.0 My Office Lan is 192.168.2.0
I want to set up the new server (physically in my office) with a 192.168.1.x IP and use a Tunnel Interface to give it full access to the customer LAN.
I set up Tunnel interfaces all the time between two firewalls (almost always Sonicwalls) with no problem. In fact we have dozens of tunnel interface VPNs running all the time.
With a basic routed tunnel between my office and the customer office, the two lans 192.168.1.0 and 192.168.2.0 talk just fine. What I can't visualize in my head is how I set up the VPN (preferably without VLAN) so I can have 192.168.1.0 on EACH side and have them talk to each other.
You generally don't. That is not how basic IPSEC works.
My first thought was to just remove the routes and let the tunnel be a bridge. Would this work? and then I would set my gateway of the new server (on my side) of the tunnel to be the gateway at the other end? And internet access would be through the customer's ISP rather than mine?
Then how would traffic know to go over the tunnel?
Anyway.. What you are trying is called an L2 Bridge. It is not basic.
Here is an example from Ubiquiti
https://help.ubnt.com/hc/en-us/articles/204961754-EdgeRouter-EoGRE-Layer-2-Tunnel -
You shouldn't do that, what you can do is a translation but then that defeats the purpose.
https://www.sonicwall.com/en-us/support/knowledge-base/170515155805172
-
@dbeato said in Tunnel Interface with two Sonicwalls and three subnets.:
You shouldn't do that, what you can do is a translation but then that defeats the purpose.
https://www.sonicwall.com/en-us/support/knowledge-base/170515155805172
Does it if the translation is purely in the firewalls?
-
@Dashrender said in Tunnel Interface with two Sonicwalls and three subnets.:
@dbeato said in Tunnel Interface with two Sonicwalls and three subnets.:
You shouldn't do that, what you can do is a translation but then that defeats the purpose.
https://www.sonicwall.com/en-us/support/knowledge-base/170515155805172
Does it if the translation is purely in the firewalls?
Yes, because it is NAT and not a LAN.
-
@JaredBusch said in Tunnel Interface with two Sonicwalls and three subnets.:
@Dashrender said in Tunnel Interface with two Sonicwalls and three subnets.:
@dbeato said in Tunnel Interface with two Sonicwalls and three subnets.:
You shouldn't do that, what you can do is a translation but then that defeats the purpose.
https://www.sonicwall.com/en-us/support/knowledge-base/170515155805172
Does it if the translation is purely in the firewalls?
Yes, because it is NAT and not a LAN.
Yeah, OK - plus it still wouldn't work to allow same subnet access, as already asked - it would never send over the VPN to the other side.
-
What we do:
Plug the server into a small 5-Port or 8-Port Gigabit switch.
We have a dedicated bench SonicWALL that is used to isolate the bench network then each LAN port on the unit is configured with its own subnet/gateway with a DENY between all.
The above switch is plugged in to one port on the SW. A Site-to-Site (S2S) tunnel is created to the client's site.
The VMs are stood up leaving the host in workgroup mode pulling a DHCP address that can be set to DHCP Reserved if need-be for longer bench duration.
All Roles and Features are set up and LoBs are installed and configured.
When it comes time to deliver we delete the S2S on both client and bench SWs.
Deliver the host. We always have a RMM/iDRAC Enterprise installed with DHCP enabled. That way we virtually never run into a problem on-site. Worse gets to worst a monitor and keyboard are available.
Once the host is configured on the production network we flip the IP on the DC VM and IPConfig /RegisterDNS then verify AD, DNS, ETC.
From there it's migrate ...
-
@PhlipElder said in Tunnel Interface with two Sonicwalls and three subnets.:
What we do:
Plug the server into a small 5-Port or 8-Port Gigabit switch.
We have a dedicated bench SonicWALL that is used to isolate the bench network then each LAN port on the unit is configured with its own subnet/gateway with a DENY between all.
The above switch is plugged in to one port on the SW. A Site-to-Site (S2S) tunnel is created to the client's site.
The VMs are stood up leaving the host in workgroup mode pulling a DHCP address that can be set to DHCP Reserved if need-be for longer bench duration.
All Roles and Features are set up and LoBs are installed and configured.
When it comes time to deliver we delete the S2S on both client and bench SWs.
Deliver the host. We always have a RMM/iDRAC Enterprise installed with DHCP enabled. That way we virtually never run into a problem on-site. Worse gets to worst a monitor and keyboard are available.
Once the host is configured on the production network we flip the IP on the DC VM and IPConfig /RegisterDNS then verify AD, DNS, ETC.
From there it's migrate ...
Okay. You do exactly what we do. Almost. Your outline above is describing what I am trying to streamline so it can be done over and over with different client sites with little to no effort. The one difference is that we use Robocopy to migrate all the data (over the tunnel) ahead of time (last week we pulled over 200TB of data over a tunnel in advance, it was sweet!), and then when we arrive on site (since it's all the same subnet), we run our script one last time to catch any new/modified files that showed up in the hours before final migration; this takes minutes.....
We even setup the new domain (when needed; I hate .local domains) with DHCP turned off, in our office before hand. It works a treat.
I spent time last night reading about EoIP with Mikrotik. It is exactly what I want, but I couldn't find any docs on setting it up with both Microtiks behind NAT devices. I'm still looking.
-
@JasGOt said in Tunnel Interface with two Sonicwalls and three subnets.:
@PhlipElder said in Tunnel Interface with two Sonicwalls and three subnets.:
What we do:
Plug the server into a small 5-Port or 8-Port Gigabit switch.
We have a dedicated bench SonicWALL that is used to isolate the bench network then each LAN port on the unit is configured with its own subnet/gateway with a DENY between all.
The above switch is plugged in to one port on the SW. A Site-to-Site (S2S) tunnel is created to the client's site.
The VMs are stood up leaving the host in workgroup mode pulling a DHCP address that can be set to DHCP Reserved if need-be for longer bench duration.
All Roles and Features are set up and LoBs are installed and configured.
When it comes time to deliver we delete the S2S on both client and bench SWs.
Deliver the host. We always have a RMM/iDRAC Enterprise installed with DHCP enabled. That way we virtually never run into a problem on-site. Worse gets to worst a monitor and keyboard are available.
Once the host is configured on the production network we flip the IP on the DC VM and IPConfig /RegisterDNS then verify AD, DNS, ETC.
From there it's migrate ...
Okay. You do exactly what we do. Almost. Your outline above is describing what I am trying to streamline so it can be done over and over with different client sites with little to no effort. The one difference is that we use Robocopy to migrate all the data (over the tunnel) ahead of time (last week we pulled over 200TB of data over a tunnel in advance, it was sweet!), and then when we arrive on site (since it's all the same subnet), we run our script one last time to catch any new/modified files that showed up in the hours before final migration; this takes minutes.....
We even setup the new domain (when needed; I hate .local domains) with DHCP turned off, in our office before hand. It works a treat.
I spent time last night reading about EoIP with Mikrotik. It is exactly what I want, but I couldn't find any docs on setting it up with both Microtiks behind NAT devices. I'm still looking.
We do a .VHDX restore of their backup to the newly stood up VM what hosts their files and folders. That way there's no permissions issues. Final sync is done using BeyondCompare.
