Jump to content


Photo

Routing Issue with Client impersonation

routing client impersonation default route

  • Please log in to reply
5 replies to this topic

#1 mtaylor

mtaylor
  • Members
  • 13 posts

Posted 25 January 2016 - 07:17 PM

We have a routing issue. We have a LB ADC 340. We are trying to set up client impersonation. We want to Real IP of the client to be snet to the server, so the IIS/X-FORWARDED-FOR option won't for us in this scenario.

 

I have 1 service on the Load Balancer with an IP address of 10.10.12.240, on the GE-1-1 interface. The service is called Test, it has 1 Real server called TestServer1 which has its default gateway the 10.10.12.240. On the Network>Routes page, 1 have 1 configured route, which is the default route, 0.0.0.0, 0.0.0.0, 10.10.12.1 and it is configured on the GE-1-1 interface. This of course excludes the routes you see when you go to Advanced>Troubleshooting and click the routes button at the bottom.

My MGMT interface has an IP address of 10.10.1.15, with a default gateway of 10.10.1.4.

 

 

When I run a tracert from the TestServer1 to anything, like 8.8.8.8 for example, which is Windows Server 2012R2, it hops to 10.10.12.240 first like expected, but it then hops to 10.10.1.15, which is the gateway of the MGMT interface.

 

This is incorrect to me unless I am missing something, and goes against what the default route is suppose to do. If I add a static route that says for 8.8.8.8 go to 10.10.12.1, then the 2nd hop of the tracert changes to 10.10.12.1, which is correct. This is unnecessary though since 8.8.8.8 is covered by 0.0.0.0.

 

 

 

 

Anyone else have this issue? Any tips I could try. I have been trying to get Techsupport to help but I am not explaining it right or something because I don't think they are grasping that this is a big issue like I think it is.

 

 

 

I cannot run trace routes from the Load Balancer because everything I try ends up with blank results, and by blank I mean the results page is literally blank.



#2 Uppalapati Chakravarthy

Uppalapati Chakravarthy
  • Barracuda Team Members
  • 7 posts

Posted 25 January 2016 - 08:02 PM

Taylor, the default route under GE-1-1 Interface is used to send response for the traffic coming to GE-1-1 Interface i.e if a user from the Internet accessing a service under Ge-1-1 Interface, ADC 340 uses the default route under GE-1-1 to send respond to the user.

 

In your scenario, traffic initiated from the real server to the Internet is coming to Ge-1-1 Interface and leaving via MGMT default gateway, which is expected because system default route takes priortiy over Interface route for the system generated traffic or to route real server traffic to the Internet, unless there is a host specific route is created under Ge-1-1. If the objective is send real server traffic to the Internet via GE-1-1 default gateway, I would suggest you to create a NAT rule on the ADC like this

 

Pre-SNat source: Srv2012 IP

Pre-SNAT Mask: 255.255.255.255

Protocol: ANY ( Depends on requirement)

Post NAT IP: 10.10.12.240

Outgoing Interface: GE-1-1

 

 

Regards

Chakravarthy



#3 mtaylor

mtaylor
  • Members
  • 13 posts

Posted 25 January 2016 - 11:39 PM

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:

NOTE:

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?



#4 mtaylor

mtaylor
  • Members
  • 13 posts

Posted 28 January 2016 - 05:48 PM

For the record, I have to make the following 2 configs to equal the config you suggested and get it to apply correctly:

Pre-SNat source: Srv2012 IP

Pre-SNAT Mask: 255.255.255.255

Protocol: TCP 1-65535

Post NAT IP: 10.10.12.240

Outgoing Interface: GE-1-1

 

Pre-SNat source: Srv2012 IP

Pre-SNAT Mask: 255.255.255.255

Protocol: UDP 1-65535

Post NAT IP: 10.10.12.240

Outgoing Interface: GE-1-1

 

 

 

This ends up creating other issues, including but not limited to the following 2 issues:

-Now I cannot tell which application server is contacting the database, since they are all NAT'ed

-Now I would have to create more routes in my firewall to allow traffic from this new NAT'ed



#5 mtaylor

mtaylor
  • Members
  • 13 posts

Posted 12 February 2016 - 09:09 PM

Still not solved. Had a tech suggest using a Policy Based Route that routes any traffic coming from the Real server through the GE-1-1 interface. We though it work, for about 30 minutes until suddenly the Load Balancer decided it would finally listen to the settings we entered in and it broke the connection. We tested again, only this time Reloaded the settings from the Administration menu, this broke the connection immediately.

 

 

Still trying to turn on Client impersonation yet have all DMZ traffic flow over GE-1-1 interface and have only management traffic flow over the MGMT interface. Not sure what is so difficult to comprehend here. Can someone, even another one of Barracuda's customers let me know if there is something I am missing here? Or have a concrete way to configure what I want?



#6 mtaylor

mtaylor
  • Members
  • 13 posts

Posted 23 February 2016 - 04:22 PM

Solved. Barracuda techs found that in a rare case, in our case, that a route was not being added correctly on the backend. This is not a route supposedly that I can see from anywhere in the interface.

 

 

Regardless it works with one caveat, I cannot navigate directly to the real server over port 80 if Client Impersonation is on. For that I will create another post and see if I can get it resolved.

 

 

Summary/Example of my working settings:

Service IP is 172.16.15.240 and is on the GE-1-1 interface

Real Server IP addresses are:

App1- 172.16.15.241

App2- 172.16.15.242

App3- 172.16.15.243

 

The Default Gateway on the Real Servers are pointing to 172.16.15.240 

I have the default route configured on the GE-1-1 interface point to the Gateway of 172.16.15.1.

To ensure traffic originating from the real servers only goes where it is allowed, I have a policy-based-route for each of the Real Servers.

The Policy Based Route says anything from 172.16.15.x going to 0.0.0.0 then route it over the GE-1-1 interface to 172.16.15.1, meaning no traffic other than management goes over the MGMT interface.