SonicWALL to Cisco ASA mixed NAT encrypted domains in a single VPN policy

Hi WiReDWolf,

Without using NAT in the policy the Cisco side is able to ping 192.168.0.1 (remote gateway).  The SonicWALL side is able to ping 172.16.0.17 (remote gateway of subnet 1) but cannot ping 10.0.0.254 (remote gateway of subnet 2) because the SonicWALL is also managing the same subnet locally.

To overcome this you need to configure NAT over VPN, which means you are going to have to create Translated Networks, thereby translating Site A's shared subnet from 10.100.0.0/24 to a virtual subnet, e.g. 10.200.0.0/24 and then translate Site B's shared subnet from 10.100.0.0/24 to virtual subnet, e.g. 10.200.0.0/24. Here's how:

So here is how it would look.
On your SonicWALL you would create the following Address Objects:

Then on the SonicWALL VPN you'd need to create an Object Group to include the Site B Translated Subnet or possible use X0 subnets (if is included in that depending on your architecture), or Firewalled subnets (depending on your requirements) and select that for the Remote Network under the Network tab of the VPN policy.

Under the Advanced tab click on Apply NAT Policies, then select Site A Translated Subnet for the Translated Local Network and Original for the Translated Remote Network.

Then you'd do the same on the ASA except the ASA's local network will be 10.100.0.0/24 and so on.

Let me know how it goes!

Hello Blue Street Tech,

I mentioned that I knew I would have to NAT the overlapping subnet, but the question is when I turn on NAT in the SonicWALL Policy, can I mix a NAT and non-NAT subnet group?

SonicWALL (Local )      Local (Translated)        VPN Tunnel        Remote (Translated)        Cisco (Remote)
192.168.0.0/24              n/a                                                       n/a                                     n/a
10.0.0.0/24                      10.100.0.0/24            NAT                 10.200.0.0/22                     10.0.0.0/22
n/a                                      n/a                                                        n/a                                     172.16.0.16/29

Perhaps I should clarify

In the VPN Policy in the NETWORK tab

Local Network is set to X0 Subnet
Remote Network is set to REMOTE SITE VPN [a group with two subnets (172.168.0.16/29 & 10.200.0.0/22)]

In the VPN Policy in the ADVANCED tab
CHECK - Apply NAT Policies
  Translated Local Network -  Local Translated [10.100.0.0/24]
  Translated Remote Network - REMOTE SITE VPN [a group with two subnets (172.168.0.16/29 & 10.200.0.0/22)]

I have no need to NAT either 192.168.0.0/24 or 172.16.0.16/29, but with NAT enabled for the VPN Policy it seems 192.168.0.0/24 cannot ping 172.16.0.16/29.

As soon as I turn off Apply NAT Policies, 192.168.0.0/24 can ping 172.16.0.16/29.  But now I have the 10.0.0.0 subnet conflict again.

I suspect if we have one subnet with NAT, we have to NAT all of them.  Except I'm not sure what you would NAT with such dissimilar networks.

SonicWALL (Local )      Local (Translated)       VPN Tunnel        Remote (Translated)        Cisco (Remote)
192.168.0.0/24             10.150.0.0/24             NAT                      ?                                          ?
10.0.0.0/24                    10.100.0.0/24             NAT                     10.200.0.0/22                    10.0.0.0/22
?                                      ?                                    NAT                     10.180.0.0/29                    172.16.0.16/29

That or set up multiple tunnels, but I've never tried that and I'm not even sure the SonicWALL would allow two different tunnels to the same endpoint.

I see. I missed that portion as I was going into a meeting. In this case, you need to do this in the NAT Policies outside of the VPN Policy. Have you done the same NAT over VPN for the ASA side?

I don't have any control over the Cisco side.  Different tech in a different time zone.  He's gone home already.  He hasn't set up the NAT on his side yet.  I know he knows to do this for the overlapping subnet (he suggested Second NAT when I pointed out the problem).

I'm still thinking that the issue is with NAT on we resolve the overlapping subnet but lose the connectivity with the other two subnets, and with NAT off we lose connectivity with the overlapping subnets.  We need all the subnets to talk to one another.  

The question is can you mix the VPN NAT policy with non-NAT subnets.

Ok I think I may have solved this myself.

I realized when I was looking in the VPN Policy --> Advanced
Translated Local Network was set to ONLY the Local Translated object (subnet 10.100.0.0/24) -  which excluded the X0 Subnet.  

Even though in the VPN Policy --> Network the Choose Local Network from List is set to X0 Subnet, the Advanced tab with the Translated Local Network must override that setting.

SonicWALL - Network - Address Objects
- Create new group "LOCAL VPN"
- add "Local Translated"
- add "X0 Subnet"

Open SonicWALL VPN Policy
Network - Choose Local Network from list - LEAVE as X0 Subnet (192.168.0.0/24)
Network - Choose Destination network from list - REMOTE SITE VPN (10.200.0.0/22; 172.16.0.16/29)
Advanced - CHECK Apply NAT Policies
   Translated Local Network:  LOCAL VPN (10.100.0.0/24; 192.168.0.0/24)
   Translated Remote Network:  REMOTE SITE VPN (10.200.0.0/22; 172.16.0.16/29)

The tech on the other end hasn't updated his end yet, but it seems you can mix the NAT and non-NAT destinations provided you remember to include the non-NAT destination in the same group as the NAT destination.

Will validate tomorrow when the other tech does his end.

Ok, it makes sense that you would create your NAT policies outside of VPN Policy.  I'm still having trouble envisioning the flow of traffic though.

Let's say my PC is 192.168.0.52 and I want to hit a printer over the VPN at 10.0.0.75.  If I send ANYTHING to 10.0.0.X it's going to end up on my local phone network unless I put in a NAT rule that says anything sent from 192.168.0.0/24 is to be translated to 10.100.0.0/22, sent over the VPN to 10.200.0.0/22 then translated to 10.0.0.0/22.

How would I ever connect to my phone system?  Any NAT rule outside of the VPN Policy would disrupt my ability to communicate with my VOICE LAN.

The rules you provided would work except my data network is not 10.0.0.0/24, it's 192.168.0.0/24.

So the rules would look like this:

Inbound
Original Source: Remote Translated (10.200.0.0/22)
Translated Source: Original
Original Destination: Local Translated (10.100.0.0/24)
Translated Destination: LAN Subnet 1 (192.168.0.0/24)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Outbound
Original Source: LAN Subnet 1 (192.168.0.0/24)
Translated Source: Local Translated (10.100.0.0/24)
Original Destination: Remote Translated (10.200.0.0/22)
Translated Destination: Original
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

The phone system network on my side only causes a problem because it overlaps with the other side of the VPN data network.  I am not interested in having any data sent from the remote site to my phone system, I want it directed back to my data network.

Two things occur to me at this point:

1. The difference in size between the two 10.0.0.0 subnets will cause a problem (22-bit vs 24-bit) with NAT

[list=2]I don't really need to do any NAT on my side at all[/list]

On the Cisco ASA side they would need to set up their rules:

Outbound 192.168.0.0/24 --> NAT 10.0.0.0/22 to 10.200.0.0/22
Inbound 192.168.0.0/24 --> NAT 10.200.0.0/22 to 10.0.0.0/22

On the SonicWALL:  Encrypted domains become 172.16.0.16/29 and 10.200.0.0/22
On the CIsco: Encrypted domain becomes 192.168.0.0/24

They set up their NAT policies as above to perform the translations outside of the VPN.  

Am I wrong?

Blue Street Tech,

I had the tech at the remote site set up their NAT policies as I've indicated above and it worked exactly how I'd hoped.  Your input to set up the NAT Policies outside of the VPN policy helped me determine that I was overthinking the process and that I really didn't need to NAT anything on my side.

In the end the Cisco ASA side created NAT policies that directed 192.168.0.0/24 <----> 10.200.0.0/22 [10.0.0.0/22]

The printer on the 192.168.0.0/24 side is now available to the Terminal Server on the 10.0.0.0/22 side.

Awesome! Glad I could help and thanks for the points!