Menu

Join the Conversation

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

Sign In Register

Help running side by side with another solution

JamieJamie Newbie ✭
in Mid Range Firewalls

Hi,


We are migrating over to SonicWall but are still using our old firewall/gateway solution as well.

The old system has a virtual interface for a VLAN and all machines on that VLAN are using that as their gateway.

On the new SonicWall system I have added a new virtual interface on the same VLAN with a different IP. PCs on the new system can ping machines still using the old gateway, but they cannot share folders etc.


Is there some sort of routing/access rule that needs putting in place? Or is this just not possible?


Thanks

Category: Mid Range Firewalls
Reply

Answers

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @Jamie do the PCs need to access a share in the same subnet (which does not involve the SNWL) or in a different subnet, which would involve routing.

    Just drop in some IP addresses to provide a bigger picture.

    --Michael@BWC

  • JamieJamie Newbie ✭

    The users PCs are in a 172.16.0.0 and access the servers on a 192.168.90.0

    On the old solution the virtual interface for the VLAN is 192.168.90.1 and the machines on that subnet have 90.1 as the gateway.


    On the SonicWall system i have added the virtual interface for the VLAN as 192.168.90.11 and machines using the sonicwall as the gateway can ping devices using the 90.1, but cannot access shares etc on them

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @Jamie I assume you have both solutions running at the moment? Is the 172.16.0.0 connected directly with the SNWL or just with the other solution?

    If you have both solutions running in parallel I'am somewhat certain that DPI/SPI will break things, because the SNWL can see only half of the traffic and drops the rest.

    E.g.: PC opens TCP connection with the SYN through the SNWL, the Server answers with a SYN/ACK over the other solution, the PC sends an ACK via the SNWL, but the SNWL will drop the packet because of the never seen SYN/ACK.

    Just make sure that the whole traffic you need is routed through the SNWL and you should be good.

    You might trick the SNWL with some internal settings, but I highly advise against it.

    --Michael@BWC

  • JamieJamie Newbie ✭

    172.16.0.0 is on both and they are on the same network.

    172.16.0.1 gateway on old solution and 172.16.0.100 on new solution.

    LAN subnet and VLANS also are on both solutions with different IP's. Devices using each as their gateways can see each other and ping each other, but just cant share files or RDP etc.

    Would there be any routing rules or anything that could enable this? Just so the SonicWall could be phased in a few departments at a time rather than switching everything over to SonicWall. Hope I am explaining this well enough.

    Thanks for your replies

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @Jamie the problem will persist.

    Let's say 172.16.0.55 is routing via 172.16.0.100 to 192.168.90.5 and 192.168.90.5 is replying via your old solution, then you'll stick in the same situation.

    The only option I can see is that you NAT the traffic from 172.16.0.100 behind the IP of the Interface for the 172.16.0.0 subnet. This is a quick and dirty solution for the hopefully short period while migrating.

    --Michael@BWC

  • JamieJamie Newbie ✭

    So add a NAT rule in Sonicwall to NAT 172.16.0.0 to the old solution 172.16.0.1?

    And for other VLANs etc do the same?

    Thanks again for your help it really is appreciated

  • BWCBWC Cybersecurity Overlord ✭✭✭

    After giving it a 2nd thought, the NAT will probably not work if 192.168.90.0 endpoints using new and solution as gateway as well. Even having the 172.16.0.0 traffic translated to 172.16.0.100 the reply packets from 192.168.90.0 will be dropped when routed via the old solution.

    I don't know about how much endpoints we're talking, but IMHO it's easier to schedule a downtime and migrate all at once using the old gateway addresses.

    --Michael@BWC

Sign In or Register to comment.