Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

IP addresses used for CSC-MA

BWCBWC Cybersecurity Overlord ✭✭✭

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

Category: Capture Security Center
Reply

Answers

  • [Deleted User][Deleted User] Cybersecurity Overlord ✭✭✭

    Hi @BWC ,

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

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @Chris,

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

    Cheers.

    --Michael@BWC

  • [Deleted User][Deleted User] Cybersecurity Overlord ✭✭✭

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

  • [Deleted User][Deleted User] Cybersecurity Overlord ✭✭✭

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

  • KaranMKaranM Administrator

    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

    Knowledge Management Senior Analyst at SonicWall.

  • [Deleted User][Deleted User] Cybersecurity Overlord ✭✭✭

    Thank you @KaranM for the information.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    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_5Poorni_5 SonicWall Employee

    @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_5Poorni_5 SonicWall Employee

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


    Thanks & Regards,

    Poornima.T.R

  • RedNetRedNet Enthusiast ✭✭
    edited June 2020

    @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

  • BWCBWC Cybersecurity Overlord ✭✭✭

    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

  • VikasVikas SonicWall Employee

    Hi @BWC ,

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

    Regards,

    Vikas Dhawan

  • BWCBWC Cybersecurity Overlord ✭✭✭

    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

Sign In or Register to comment.