clarification on SNAT and automap

First, drop all the pretense of S=Secure, and think of SNAT as Source NAT. i.e. NAT'ing the source address of the connection. That should probably make it a lot easier to remember what's happening.

 

 

Second, you can either use SNAT Automap, which will use a floating selfIP address as the src address for SNAT'ed connections, OR create a specific SNAT pool, which you put a list of IP addresses into it, and have the connections use one of those IP addresses as the src IP.

 

 

Lastly... What do you mean you want to preserve the server IP? IIUC what you're wanting, that's never going to work, because the client knows the 'server' address as your VS address. Having packets return with a different IP address won't match the connection table in the client, and would thus be dropped. There's no way to fake it...

 

 

There are a couple of (Possibly) ugly options if you TOOTB...

 

 

1. Assuming the traffic is HTTP, Use the LB as a pure redirection service. Client comes in and gets redirected via a 302 to a specific server. You might need to put some logic in there to track sessions (Unless you don't care about it) so clients keep the same backend, but that may not be necessary (YMMV).

 

 

2. Again assuming the traffic is HTTP, you could insert a header to track the IP address of the server. HOWEVER if you're doing that, you could also use session cookies to track it. The client can then decode the cookie to see what IP & Port they're being load balanced to.

 

 

Hamish.

 

I think I got it!

 

 

F5 is going to splice the connection and so the client will never see the server IP.

 

 

I think I am now clear on automap.

 

 

Thanks for the help.

Yep. You got it.

 

 

When enabling SNAT, the F5 acts just like a real proxy... You can think of it as a connection to the F5, and then a second connection from the F5 to the server.

 

 

H

Great explanation, H, spot on.

 

Thanks!

 

 

/deb

Maybe related question, maybe not:

 

 

"Second, you can either use SNAT Automap, which will use a floating selfIP address as the src address for SNAT'ed connections, OR create a specific SNAT pool, which you put a list of IP addresses into it, and have the connections use one of those IP addresses as the src IP."

 

 

Does this mean, that if I know the (limited number of) source IPs and create a SNAT pool with those: the source IPs will no longer be hidden from the application (replaced by the Biggy with the floating IP)?!

 

Are you wanting to take the client IP and use that to SNAT the connections to the pool? If so, this would not be SNAT'ing--it's basically disabling using the client IP to source the connections to the pool members. If I've misunderstood the scenario, can you elaborate on what you're considering?

 

 

Thanks,

 

Aaron

Hi Aaron,

 

 

Scenario is: Inet -> Cisco ASA (NAT) -> BigIP -> DMZ web servers (Physical + VMs) -> Switch -> MPLS Router.

 

 

The def. gw for the app servers (those who are pool members) is not the BigIP as we do not want to mess around with routing: we send them towards the Core switch (internal access) and ultimately towards the MPLS router.

 

 

All VSs for the DMZ servers have SNAT enabled but for some applications we`d need to have visible source IPs not the floating IP. Currently, if SNAT automap is disabled: the app servers can not be reached from outside.

 

 

I might need to check on that scenario up there, but 90% sure now. My understanding was: if I create a SNAT pool with the source IPs: the BigIP will perform SNAT but will keep the `real` IPs for the application visible? Am I totally wrong there?

 

 

Cheers:

 

 

Andy

once you snat the real IP is gone from layer 3. However, you can pass the 'real' IP in the X-Forwarded-For header by enabling that option in the http profile.

Hi there,

 

 

Thank you! From a separate source I`ve also got this confirmed: SOL4816. I`ll try to implement it on our test environment (in our case it is IIS) and let you know guys.

 

 

Cheers,

 

Andy

FYI...IIS can do nothing natively with the x-forwarded-for header. However, Joe recently released an update to his ISAPI filter that will do the heavy lifting for you. Check out his blog for details: Click here