It doesn't look even that easy. I tried adding the NAT but received an error stating the ports were wrong, I tried a couple times after realizing I entered the IP address incorrectly and got the same result. I read the help file and found the following:
There must already be a virtual interface configured on this system with the IP address (and range, if applicable) specified in Post SNAT Source. If not, the NAT rule will not be added and you will get an error message.
This makes me think the reason for the error is not really the ports but the fact that I do not have a virtual interface setup. If this is the case you all need to make the error match.
I was told all I needed to do to get the Real Client IP to the Real Server was make the gateway of the Real Server the IP address of the Barracuda, no mention of a virtual interface, in addition to turning on client impersonation. Whilst is does work as far as basic connections go, the routing is unsafe
I'm not sure why you even have a MGMT port at all if you don't seem to care to keep the MGMT traffic separate from the WAN traffic. Heck why not move the MGMT port from the back and put it next to the WAN ports if they are going to share traffic. If you are going to abandon the reason for having completely separate NICs/Ports then you probably need to go ahead and change your text in help files and such to say the default route is only for traffic incoming to a Real Server, not outgoing from a Real Server. For example the Routes>Add Static Routes help file specifically states you can add a route to help guide traffic to a "remote" destination, and even goes on to indirectly show you how to create a default route implying the default route would actually work to be a default route for that interface, again no mention of one specific direction.
For example, with this wierd routing flaw, the traffic from a real server takes additional hops it doesn't need to and also creates a security flaw that allows me to contact my internal network in way we have denied in our firewall.....our DMZ is dead end off of our firewall, logically speaking. For example, the real server TestServer1 is on the 10.10.12.0 network owned by a router which houses the gateway 12.1. That router does not allow traffic to our internal network, other than a select few things, because that is sort of the point of a DMZ & router, but your choice not to make a MGMT port strictly a MGMT port, I now have full access to my internal network from my public facing DMZ server. So if I add a static route on GE-1-1 for the network which an internal FTP server resides on stating it should go to 12.1 gateway, then it is blocked again. I cannot however keep covering up the Load Balancer's inefficiencies with little fixes here and there, it is getting way to convoluted.
I don't want public/DMZ traffic going over the MGMT port or being able to access my internal network. Yes for anyone who is curious I do have IP restrictions on the FTP server, but that is besides the point, traffic should never be able to get it, 1 layer of security is not good enough.
Luckily right now client impersonation is turned off and traffic is correctly and safely running through the firewall. AKA the gateway of the Real Server is 10.10.12.1 again so i know it isn't touching my internal network.
We really need to have the Real Client IP address sent to the Real Server. Does anyone have a concrete way of doing this they can share. More specifically a safe way, as I think I mentioned above I can get communication flowing, but not safely or not in a way that is manageable.
Also can you state why you do not want to isolate MGMT traffic and WAN traffic? What is the downside to separating these out?