@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.
https://en.wikipedia.org/wiki/Syncthing looks like an interesting option. Not sure how it compares for performance.
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?
@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
@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
@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
@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.
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?
Are you using Citrix's profile management? I'm not the citrix guy in our shop but I've had to muck around in their profile management stuff for one of our Windows RDP servers... Your note about local profiles makes me wonder about the local profile options in Profile Management...
DPI / zoom settings? IIRC some high-res displays will default to 125% zoom which could be messing with the element sizing
I'm thinking that something involving IFTTT and smart bulbs shouldn't be too difficult to set up
@hobbit666 said in What Are You Doing Right Now:
Creating a network diagram of our MPLS/Firewall/Internet/DR Site etc
Arts and crafts 
@Dashrender said in System Image Disappearing/Reappearing:
@G-I-Jones said in System Image Disappearing/Reappearing:
The only thing I can think of, which is most likely not correct, is that Windows reads the WindowsImageBackup folder alphabetically. That is to say since LABS comes before LENOVOLAP alphabetically, it hits the Windows 10 image in LENOVOLAP and then says "nope, everything else after this is null" and then doesn't even get to STAFF? I dunno man, it's weird.
Yeah, it's a super basic tool, it's probably not expecting more than a single backup in the directory.
^^ This sounds like what's happening.
If you're tied down to using an external drive and $0 tools, maybe consider using clonezilla or the Veeam's free windows agent. If you've got an afternoon and space for a linux VM (or even just a decommissioned desktop / server for a Proof of Concept test) take a look at FOG (https://fogproject.org/).
Dead simple to do for your outgoing traffic, but as others have indicated, your problem is going to be to get external services to fail over to the other incoming link.
Really quickly, something kinda hacky that could work is your domain name on a dynamic service with the updater client installed directly on the server(s) in question. Have a short refresh interval, so that whenever the outgoing connection flips, the updater client sees reports the new IP address and traffic will eventually be pointed to the backup line.
Definitely not something that I'd want to put into a critical setup, but it could work for non-essential services.
We used to do with with an iPrism / edgewave / St Bernard appliance.
@DustinB3403 said in XenServer Supplemental Packs:
@notverypunny said in XenServer Supplemental Packs:
@DustinB3403 Going through the 7.1 version of the same thing right now. Not much is making it through this sinus headache / migraine though.... Maybe another coffee will help. From what I see on the XCP-ng forum they're trying to move away from the notion of supplemental packs in favor of standard rpms.
Yup, because SPs are essentially private, where as the entire XCP-ng project is FOSS. It makes it way easier to just run
yum install <something>and keep it all updated with theyum upgrade
Makes perfect sense for the XCP-ng project, but playing with yum and adding repos would put our hosts in an unsupported state with Citrix. Other way I might be able to do this is some sort of query over SSH from a linux machine to the bare-metal (Dell idrac) and / or the XenServer install. FusionInventory does wonders with SNMP for network devices and printers but I haven't seen anything that applies to my setup.
@DustinB3403 Going through the 7.1 version of the same thing right now. Not much is making it through this sinus headache / migraine though.... Maybe another coffee will help. From what I see on the XCP-ng forum they're trying to move away from the notion of supplemental packs in favor of standard rpms.
@DustinB3403 Yep but they're also a Citrix Partner and XO is certified "Citrix Ready" so I figured if anyone would be in the know it would be him. If I manage to figure it out I should probably make a how-to or tutorial as it would be a cleaner way to install 3rd party stuff and I think would apply to XCP-ng the same as XS.
Nope, it's the regular old Citrix XenServer. I'm not against using XCP-ng, but we're licensed and supported as part of our VDI environment so we're staying there until further notice.
For the moment it would be one of those "nice to have" items so I don't know how much time / effort I'm going to put into it. Like everyone else we've got some major projects that have to get done and never enough time to do them 
Before I jump down the rabbit hole on my own, has anyone on here tried / had any success building xenserver supplemental packs? (@olivier maybe?) I'd like to be able to take the fusioninventory agent rpms here as well as any dependencies and build a supplemental pack that I can deploy on our xenserver hosts.
Does this see feasible? Citrix seems to have some info on creating supplemental packs that's mostly aimed at driver support but it looks like features / extensions are possible too.
Alternatively, if someone has already built such a thing and is willing to share.....