Subnet Migration problems
-
Looking for any input or wisdom from the masses after spending the morning fighting with my network.
Situation: Trying to move our DMZ2 Zone / subnet from our EOL sonicwall to our nice shiny fortigate. Here's the layout with everything working:
So this morning I moved the physical connection from DMZ2 to the fortigate, reassigned the gateway IP and reconfigured the routing. Looked like this:
The Server, VDI and other subnets that are connected to the HP switch were all able to access the resources in DMZ2, and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2, regardless of pointing the route on the SonicWall at the Core Switch or the Fortigate.
Has anyone out there run into this or something similar?
-
@notverypunny said in Subnet Migration problems:
Looking for any input or wisdom from the masses after spending the morning fighting with my network.
Situation: Trying to move our DMZ2 Zone / subnet from our EOL sonicwall to our nice shiny fortigate. Here's the layout with everything working:
So this morning I moved the physical connection from DMZ2 to the fortigate, reassigned the gateway IP and reconfigured the routing. Looked like this:
The Server, VDI and other subnets that are connected to the HP switch were all able to access the resources in DMZ2, and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2, regardless of pointing the route on the SonicWall at the Core Switch or the Fortigate.
Has anyone out there run into this or something similar?
Check the routes on the HP switch and make sure that it's not still pointing to the Sonicwall for DMZ2?
Edit: Also check the Sonicwall and make sure it has no rules related to DMZ2?
-
First thought: Why do you need two DMZ subnets?
More to the point of the question: Does traffic flow from DMZ1 to IT subnet? If so, perhaps compare how it flows to however its flowing and failing from DMZ1 to DMZ2.
Something that seems a bit odd to me:
and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2
How did you determine this to be true?
-
@notverypunny said in Subnet Migration problems:
The Server, VDI and other subnets that are connected to the HP switch were all able to access the resources in DMZ2, and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2, regardless of pointing the route on the SonicWall at the Core Switch or the Fortigate.
how do you know that DMZ2 can get to DMZ1, if the traffic can't make it back from DMZ2 to 1, then it would look like no traffic was passing at all, but if say, pings are flowing from DMZ1 to DMZ2, and responses are flowing back... then it would look like a rule issue preventing the starting of traffic from DMZ1 to DMZ2. And I'm drawing a blank on what it's called.
-
@dafyre said in Subnet Migration problems:
@notverypunny said in Subnet Migration problems:
Looking for any input or wisdom from the masses after spending the morning fighting with my network.
Situation: Trying to move our DMZ2 Zone / subnet from our EOL sonicwall to our nice shiny fortigate. Here's the layout with everything working:
So this morning I moved the physical connection from DMZ2 to the fortigate, reassigned the gateway IP and reconfigured the routing. Looked like this:
The Server, VDI and other subnets that are connected to the HP switch were all able to access the resources in DMZ2, and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2, regardless of pointing the route on the SonicWall at the Core Switch or the Fortigate.
Has anyone out there run into this or something similar?
Check the routes on the HP switch and make sure that it's not still pointing to the Sonicwall for DMZ2?
Did that, if this had been the issue, none of the "other" subnets that are routed by the HP would have been getting to DMZ2, but still I checked it a couple of times.
Edit: Also check the Sonicwall and make sure it has no rules related to DMZ2?
There were some rules in place, but I changed the network range associated to the DMZ2 zone on the sonicwall as the 192.168.29.0/24 subnet was then technically part of the LAN zone on the sonicwall since it was being routed out the X0 interface to the HP Switch. As a troubleshooting measure we tried adding some allow all any any rules to the sonicwall to see if we could even get the traffic to the FG and it didn't seem to do any good.
-
@EddieJennings said in Subnet Migration problems:
First thought: Why do you need two DMZ subnets?
DMZ1 holds WAN accessible resources, DMZ2 is a bubble for stuff that DMZ1 and LAN both need to access... at least that's my understanding. It's something that was setup before my arrival, I think it was a BP with the initial deployment of Lync or Citrix VDI
More to the point of the question: Does traffic flow from DMZ1 to IT subnet?
Don't know, we don't allow any ingress to IT as it's where our management stations live.
If so, perhaps compare how it flows to however its flowing and failing from DMZ1 to DMZ2.
Something that seems a bit odd to me:
and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2
How did you determine this to be true?
log onto a server in DMZ2 and ping (and traceroute) successfully to server in DMZ1, try the reverse and the ping (and traceroute) fails
-
@notverypunny said in Subnet Migration problems:
log onto a server in DMZ2 and ping (and traceroute) successfully to server in DMZ1, try the reverse and the ping (and traceroute) fails
So you're allowing established connections from DMZ1 to DMZ2, but not new from 2 to 1. Look at your routing rules on the Fortigate relating to what is allowed new into DMZ2, since the rest work, it seems like DMZ1 is just missing from the allowed list.
-
@Dashrender said in Subnet Migration problems:
@notverypunny said in Subnet Migration problems:
The Server, VDI and other subnets that are connected to the HP switch were all able to access the resources in DMZ2, and servers in DMZ2 could get to DMZ1, but DMZ1 couldn't get to DMZ2, regardless of pointing the route on the SonicWall at the Core Switch or the Fortigate.
how do you know that DMZ2 can get to DMZ1, if the traffic can't make it back from DMZ2 to 1, then it would look like no traffic was passing at all, but if say, pings are flowing from DMZ1 to DMZ2, and responses are flowing back... then it would look like a rule issue preventing the starting of traffic from DMZ1 to DMZ2. And I'm drawing a blank on what it's called.
It's messed up, we ended up reverting things and I'm testing between stuff in the management subnet and DMZ1. If I can't figure it out it means that we'll have to do DMZ1 and DMZ2 at the same time, hoping that things just work
-
@Dashrender said in Subnet Migration problems:
@notverypunny said in Subnet Migration problems:
log onto a server in DMZ2 and ping (and traceroute) successfully to server in DMZ1, try the reverse and the ping (and traceroute) fails
So you're allowing established connections from DMZ1 to DMZ2, but not new from 2 to 1. Look at your routing rules on the Fortigate relating to what is allowed new into DMZ2, since the rest work, it seems like DMZ1 is just missing from the allowed list.
Yeah, tried an allow all for the whole 192.168.0.0/16, still no joy. Seems to be anything on the "other side" of the FG, trying against a couple of non-critical servers in the management subnet
-
Been digging around the interwebs on this, does anyone think that it could be the FG thinking that it's an asymmetric routing issue?
We're running more recent than 5.4 but from what I've seen this type of stuff is pretty much the same under the hood from one version to another.
Tried pointing the routes directly from the sonicwall to the FG and vice-versa to ensure that asymmetric routing wasn't an issue, but if (for whatever reason, and I understand the documentation correctly) the sonicwall isn't sending the syn request as the FG is expecting it then it could be seeing it as asymmetrical and dropping the whole thing.
-- Or am I completely out to lunch on this one? -
What makes this new subnet on the FG different from the IT one?
You said IT doesn't allow anything in, so I assume DMZ1 can't talk to IT vlan either, correct?
-
@Dashrender
Yeah, further troubleshooting shows that DMZ1 can't initiate communication to anything that's on the other side of the FG. Will be testing against stuff in the management subnet tomorrow. Also going to try enabling asymmetric routing as a short-term test. Otherwise it's going to have to be an all-at-once move, which we were hoping to avoid.Thanks to all for the suggestions and just for a place to get this out of my head and somewhat organised.
