IP addresses used for CSC-MA

BWC

Hi,

when deploying a Firewall appliance with ZeroTouch and CSC Management enabled, there will be a VPN tunnel created for transferring the information to the SGMS. I couldn't find any further documentation about this.

Therefore a local address will be generated for the GMSFlow Client (Firewall) on Zone LAN and a GMSServer (CSC-MA) on Zone VPN.

I was wondering how theses addresses got determined, in my case it was 192.168.0.x/32 for LAN and 10.84.140.x/32 for VPN.

Is there a list of address blocks available used for that matter, probably per Colo site? I think this is somewhat important information to avoid address collisions when deploying new appliances with CSC-MA enabled, because RFC1918 address blocks are heavily used and conflicts are likely.

Thanks in advance.

--Michael@BWC

[Deleted User]

Hi @BWC ,

Let me connect with some of our product experts and see what we can find out.

BWC

Hi @Chris,

did you got any information from your experts on that matter?

Cheers.

--Michael@BWC

[Deleted User]

Apologies for the delay @BWC . Following up now, will keep you posted the instant I hear something.

[Deleted User]

Quick update @BWC . This is with some of our engineers now, and they are looking further into it.

KaranM

Hi @BWC ,

I hope you are doing good!

Please find the response for your queries below:

• If there is a list of address blocks available that we are using here?

We use a complete RFC-1918 address space for this purpose.

• How or What procedure is being used to choose these addresses?

It is a random process.

• While assigning these addresses, how we make sure that this does not conflict with the user’s network?

This will not conflict with any address assigned to any interface since this random IP is used in a specially created address object which is used solely for this purpose of flow tunnel. SonicWall can differentiate between the specially created address object and other networks thus preventing the conflict.

Thank You

[Deleted User]

Thank you @KaranM for the information.

BWC

Hi @KaranM and @Chris,

thanks for looking into this.

I'am not 100% sure where this will take me, but it looks a bit unpredictable to me and I'am feeling not comfortable to tell my customers to wait how the numbers are falling before we figure out if we have an IP address conflict or not. It's not just the local interfaces, it's VPN destinations etc. as well.

I believe a random process isn't a wise choice and clear definitions are key here.

--Michael@BWC

Poorni_5

@BWC ,

We use 192.168.X.X for the LAN subnet and for the VPN it is 10.X series because the agents are on that IP range. I am trying to get a list of addresses and make a KB out of it. Will write one once I have enough data.

Thanks & Regards,

Poornima. T.R

Poorni_5

@BWC , I am in the process of collecting the needed info, stay tuned!!

Thanks & Regards,

Poornima.T.R

RedNet

@BWC Just to add to this from what I have seen, though I agree some concrete information would be nice.

The VPN built to CSC generates the random net on both the source and destination networks on the tunnel. The tunnel is policy based so is preferred over any routes in your routing table. So the IPfix messages are sourced on your Sonicwall from a new random but unused net.

As the source net is also a new random net on your SonicWALL, generated when the SonicWALL is provisioned by CSC, the SonicWALL will pick currently unused nets it seems (reading config/address objects possibly?).

As the traffic only matching the encryption domains, both source and destination, will be placed into the tunnel it would be impossible at the time of deploying the CSC for you to have an overlap. In the future you would be able to make sure your source/local network does not match the source/local the CSC VPN used and even if it did overlap, the destination would also have to overlap for it to be placed in the CSC VPN tunnel.... and you have NAT options.

Hopefully you get that concrete info, but the above is what I have figured they have done. There could be more to it also in the OS to get around any issues.

By the way, have you figured out a list of the WAN Peers they could use to build the tunnel. I like to only allow IKE traffic inbound from known ranges for security but cannot get a list of the IP's CSC might use on their side as their Peer IP for the tunnel.

Cheers

BWC

Hi @RedNet

I did not received any further information about WAN peers etc., seems to be somewhere in the Amazon EC2 spheres.

In my case, having 10.0.0.0/8 routed to the bavarian governmental intranet spice things up and will question if a deployment of CSC would even be an option.

--Michael@BWC

Vikas

Hi @BWC ,

You can refer below KB article for checking the WAN peer information, depending upon specific COLO sever,

https://www.sonicwall.com/support/knowledge-base/sonicwall-csc-fqdn-and-ip-list/190820182345867/

Regards,

Vikas Dhawan

BWC

Hi @Vikas

thanks for the update, my TZ 400 is connecting to 35.156.63.64, which does not seem to be in your list.

--Michael@BWC