Sonicwall Pro3060 and Cisco VPN Firewall / NAT rules

Hello again fireguy1125,
 
I would add the 172.20.0.0 /24 network to the destination network config in the SA at each remote office. Depending on the model and Standard/Ehanced OS you may have to make an Address Object Group with the LAN subnet and this new network, or just define it in the tunnel config at bottom of the General tab as an additional Destination Network. Also add that 172.20.0.0 /24 network as a source network on the tunnels at the Pro 3060 for each remote office tunnel... an Address Object Groups will have to be made as well here. That way each remote site now has a route to the 172.20.0.0 /24 network back to the Pro 3060 as well as the HQ subnet.
 
Then for the tunnel to the Cisco, create an Address Object Group that includes all of your remote office networks and the network of HQ. Set that in the tunnel config on the Network tab (Local Network) , then go to the Advanced tab and NAT it so that Remote Network is Original and Local Network is the HQ (X0 I assume) subnet.

Let me know if that makes sense... :)

Also, this is based on the time clocks at the remote sites initiating the traffic, I'm assuming the time clock server at the Cisco does not need to initiate traffic to the remote office networks.

Thanks crouthamela, great start for me.  I'll work on this tomorrow and I'm sure I'll have additional questions.  

However, I believe the time clock server will need to initiate traffic at the remote office networks (query to send hand punches)  I will provide more information re: required firewall rules by the company tomorrow.

If the time clock server needs to initiate then ont heir side, they will have to add the networks for each remote office of yours to the SA for the tunnel, and you can skip the NAT portion for that then.

Just to add to the confusion.  The time clocks at each remote site has an IP address corresponding to that sites original subnet ex. Site subnet 10.1.1.x / 24 has time clock IP of 10.1.1.50.  How am I to provide connectivity through the new tunneled subnet 172.20.0.x with this clock IP?  I know easiest way is to change the IP address of the clock, but we're unable to do so at this time until server connecitivity is tested over the new VPN links.

The method with NAT I mentioned will work for that, but only for initiated traffic from Remote Office -> Time Clock Server. If the testing has to include the Time Clock Server initiating traffic like you mentioned, they have to add your subnets to the tunnel on their side, there's no way getting around that really.

I added all the tunnels and see they are up with the 170.0.0.X for all the remote sites. I need some help with the NATing now.
I created an Address Group called "VPN TUNNELS Group".  It has the 192.168.x.x/16 and the X4 Subnet (172.20.X.X / 24) I'm assuming that the one entry for the 172.20.x.x/24 network assigned to the DMZ is the same as each individual remote network, since they all have the tunnel up?  Or do I require to create a group with the original subnets for all 17 locations 10.1.x.x/etc?

I've created a new NAT policy on the pro3060 at HQ, with the following, but still unable to ping the X4 on Soniwall or the Cisco INT0/1 from the remote office sonicwalls:

Original Source: VPN TUNNELS Group (192.168.x.x/16 and 172.20.x.x/24 subnets)
Translated Source: Original
Original Destination: X4 Subnet (X4 Interface on sonicwall is configured as 172.20.0.1)
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interfaec: X2 (Assigned to VPNs)
Outbound Interface: X4 (DMZ interface assigned 172.20.0.1 connected to INT on Cisco 172.20.0.2)

Just to confirm, the tunnels on the HQ side to all the remote sites have 192.168.0.0 /16 and 172.20.0.0 /24 in a group and have that group configured as the Local Network?

I think I'm confused as to the connectivity between the Sonicwall and the Cisco. Is it actually going to be a VPN tunnel over the internet between the sites? Or does that X4 interface on the Sonicwall connect to a leased line directly to the Cisco at the other site? Could you clarify the reasoning for the X4 connection and explain a little more the physical setup over there? Is the X4 literally connected directly to the INT/LAN on the Cisco?

If this were a normal VPN tunnel out the X1/X2/default internet interface, the VPN TUNNELS Group would need the original subnets for all remote networks (10.1.x.x) plus the HQ subnet, and take out the X4 subnet. The X4 subnet would also be removed completely.

The NAT would then be:
Original Source: VPN TUNNELS Group
Translated Source: X0 Subnet
Original Destination: (an Address Object that has the network of 172.20.0.0 /24, but not the X4 subnet object)
Translated Destination: Original
Inbound Interface: X2
Outbound Interface X1/X2 (whichever is your default internet port)

BUT... If this ends up being a directly connected setup or leased line, etc, we don't even need a tunnel from HQ -> Cisco. As it is now, we're going to have routing problems due to that X4 because the tunnel will overlap with the directly connected interface.

All Tunnels between HQ and Remote Sites have connection to 192.168.0.0 /16 and 172.20.0.0 /24.  I created an Address Group called "VPN TUNNELS Group" with 2 entries:  The first entry is called LAN Subnets which is also a pre-existing group and that is the 192.168.0.0/16.  The other entry is called X4 Subnet, with Address Details of 172.20.0.0 /24, this is assigned to the DMZ zone.  All Currently Active VPN Tunnels are showing both networks for each site.

The connectivity between SonicWall and Cisco is direct connection Ethernet Crossover.  Cisco GE0/1 directly to Sonicwall X4.  Both devices are next to each other (sorry for not specifying this earlier).  See attached diagram (sorry should have done this earlier too).

clockdiag.jpg

The company providing the managed VPN router sent it pre-configured accoring to settings settings that I specified for the interfaces.  This was done with help of a previous question here: https://www.experts-exchange.com/questions/26257804/Add-VPN-Router-Hardware-to-VPN-Firewall-Sonicwall-Hardware.html

The connection to the Internet from HQ is through a Cable Modem w/5 Static IPs.  One IP is assigned to the Sonicwall WAN interface X1 (not picutured), the other IP is assigned to X2, and the third is assigned to X3 for the managed VPN router.

Ok that makes a lot more sense. So basically the "Managed VPN Router" is the full endpoint for VPN termination. So on the Sonicwall we can forget about the HQ -> Cisco VPN, it's going to be just a route (which is already there thanks to the X4 being directly connected) and a NAT statement. So delete any VPN config you have on the Sonicwall for HQ -> Cisco.

Edit the VPN TUNNELS Group and put in all of the original subnets for all remote  networks (10.1.x.x etc) plus the HQ subnet, and take out the X4 subnet.

Go to Network -> NAT Policies and make the following:

Original Source: VPN TUNNELS Group
Translated Source: X4 IP
Original Destination: X4 Subnet
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: X2
Outbound Interface: X4

You'll also want to make sure in your Firewall -> Access Rules, that you allow the zone X2 is in to DMZ.

And as like before, if they need to initiate traffic to your remote offices... they will have to add the remote office networks to the VPN tunnel to them from their Managed VPN Router and you would delete the NAT on the Sonicwall.

So we don't need the 172.20 subnet at all at any of the remote sites?  Those will stay the 10.1.x addresses and we can remove the 172.20 tunnel to all remote sites? And what we are essentially doing is NATing them only at the HQ sonicwall INT X4?  Currently the X2 zone (assigned to only VPN traffic through a seperate static modem is actually assigned a WAN zone)

We still want the 172.20.0.0 /24 network on all the tunnels to the remote offices from your Sonicwall. We're only deleting any VPN setup you have on the Sonicwall for the Cisco. Having the 172.20.0.0 /24 network in the tunnels to the remote offices serves as our route from the remote office back to HQ for that network. Then from HQ the Sonicwall sends traffic destined for 172.20.0.0 /24 out X4, and we are then NATing any traffic that does that to the X4 interface IP of 172.20.0.1 since that is the only network the Cisco and consequent VPN knows about right now. Otherwise you're going to have 10.0.x.x traffic headed to the Cisco and it won't know what to do with it since it doesn't have those network configured yet.

Ok looks like were making some progress.  I was able to ping cisco int 172.20.0.2 from the remote site.  However I can't ping sonicwal int 172.20.0.1.  is there a reason for this?

I also can't ping from HQ network to cisco int 172.20.0.2.  I double checked and the HQ network 192.168.0.0 is in the group along with the remote sites in the nat policy we created above.

Ok, regarding my previous 2nd question, I figured it out.  Created another NAT policy as follows:

Original Source: LAN Subnet
Translated Source: X4 IP
Original Destination: X4 Subnet
Translated Destination: Original
Original Service: Ping
Translated Service: Original
Inbound Interface: X0 (This is the interface that is assigned to the HQ LAN)
Outbound Interface: X4

For the first part, do you have ping disabled on X4?

As for HQ... try creating an additional NAT specifically for the HQ traffic. I think it doesn't like that we specified X2 as the Inbound Interface in the last NAT:

Original Source: X0 Subnet
Translated Source: X4 IP
Original  Destination: X4 Subnet
Translated Destination: Original
Original  Service: Any
Translated Service: Original
Inbound Interface: X0
Outbound  Interface: X4

Haha you beat me to it by only seconds. :)

:)

For the ping to 172.20.0.1, checking the Firewall Rules from LAN > DMZ shows everything Full Allow. Also checked VPN > DMZ rules, and has for ANY service to be allowed from each of the tunnels.

I meant if you edit the actual X4 interface under Network -> Interfaces -> X4 Configure, is the Ping checkbox checked off?

No it was not...that was easy...sort of.  Now I can ping the interface from remote office, but not from within the HQ network

Do you need it? :)

Is this up and working correctly now for your time clocks?

Sorry for the delay, was on vacation last week.  Okay, where we are now is I'm able to ping the G/E 0/1 interface (172.20.0.2) on the Cisco from all remote office sonicwalls. I'm able to ping the 172.20.0.2 from the HQ network (192.168.x.x) however, when I assign a PC a 172.20.0.x address I'm unable to ping the GE 0/1 interface.

Also, as part of the test to the hosted clock server, I'm required to ping a supplied address and should be getting response times...at this point I am not.

The remaining part of the instructions provided are as follows:

The Firewall "may" need the following ports open:

Source Address                      DST Address                Protocol Name                      Type/Port
Host 170.x.x.x                       Our external WAN               IPSEC                       IP PROTOCOL 50 <--->
Host 170.x.x.x                       Our external WAN                 IKE                           UDP 500 <--->
Host 170.x.x.x                       Our external WAN                 TCP                          <-- SSH 23 from Host

Application Connectivity:

HP Clocks                              206.x.x.x                             TCP                  TCP 3001 Client ---> Clock Server

Should I have to add these firewall entries to the sonicwall?


Routing Changes:

Add required static route for IP address range 206.x.x.x /24 routed to IP address assigned to GE0/1 (172.20.0.2) of the router at your facility.
I configured this as:
Source: Any
Destination: 206.x.x.x/24
Service: Any
Gateway: 1720.20.0.2
Interface: X4

1. What's the reason for assigning a PC a 172.20.0.x IP? They should remain on their normal network IP range such as 192.168.0.0 or 10.1.x.x. The 172.20.0.x network is only there to connect the Managed VPN Router to our SonicWALL, so there should only be the two interfaces with IPs on that.
2. So the HP Clocks are using a public 206.x.x.x address that needs to go over the VPN? Are you able to ping that from HQ with the new route you added? From the looks of your route you created, HQ should ping.
3. As for the remote sites, they are going to need that 206.x.x.x network added to their Address Group for the tunnels to HQ as well. Else that traffic is just going to head out to the internet from those locations and not route back to HQ and over to the Managed VPN Router.
4. The Firewall rules only apply to that Managed VPN Router. Since your SonicWALL doesn't have any VPN configured on it for the HP timeclock site, you don't need to open 50/500 and such, those are only to allow VPN.
   

Gotcha, I am still unable to ping the 172.20.0.1 IP, which is the Sonicwall interface from the 192.168.x.x network.  but I can ping the 172.20.0.2, the Cisco Ge0/1 which I'm OK with

The HP clocks are currently assigned local ip addreses corresponding to the location they're at.  HQ clocks use 192.168.x.x and remote sites use the 10.1.x.x   They will be required to communicate with the 206.91.x.x server through the Cisco Ge0/1 interface.  When I put in the static route at the HQ sonicwall, and do a ping, I get nothing (I should be getting replies).  When i put in static route at the remote sites that are routing the 206.91.x.x./16 network through the 172.20.0.2 gateway, i can't ping.

I have to create a 3rd address group now for the 206.x.x.x network now for all VPN tunnels, can't I just create a static route for the 206.x.x.x to go to the 172.20.0.2 gateway?

Thanks, I'll check it out once I know the IP is working correctly, at this point the host is still having problems...which of course we can't test until we know for sure that the IP of the host will actually be up and generating replies...i'll keep you posted with how I make out

Sorry it's been so long, just got word that pings will time out, but we should be able to perfrom a tracert to the 206.91.x.x address and should go to the inside interface of the Cisco router (172.20.0.2)  However, when I do a tracert, it doesn't show a hop on the sonicwall.

Go into your Firewall -> Advanced section and select Decrement IP TTL for forwarded traffic. That will enable the SonicWALL to be "seen" in the trace route output.

I enabled it, however the tracert is still showing *

Also, the Decrement IP TTL for forwarded traffic is not an option for most of our remote firewalls, since they are only using Standard OS.

I'm wondering if going this route is over-complicating things, and should we go a different approach.

I was thinking to have the company reconfigure the router interface to that of our existing HQ network of 192.168.x.x/16, and eliminating the whole 172.20.0.0 concept.  Have them update to allow source traffic from all of our pre-existing networks.  Since we are unble to test this current setup with ping, and the tracerts, it would also allow us to i'm assuming,  ignore the whole NATing mess, and keep our clocks with their existing IPs, maintaining connectivity to our network, while they can test connecitivity to their server without any down time.

I know we both have spent much time on this, and it seems as though we are so close, but wondering if going back and simplifying it will make it easier in the long run...thoughts?

Also, did a packet capture on X4 when doing a trace rt.  Attached image is the result.
tracert-packet-drop.jpg

Thanks for your persistence in this issue, I actually ended up not using the 172.20.x.x network and deal with any routing.  Instead I connected the Cisco GE0/1 interface directly to my network LAN at the PRO3060, avoiding the need for the X4 (172.20) interfacea nd all the extra tunnels.  This avoids all the NAT complications and instead I just have the 206.91.x.x network tunnel added to all the remote SAs with just the static route on the pro3060 configured.