[f-nsp] Yet Another Nat Question

Timothy Arnold tim at uksolutions.co.uk
Thu Dec 9 08:30:16 EST 2004


Hi,

On Thu, 2004-12-09 at 13:28 +0100, Gerlof.Dijk wrote:
> Why not admin your systemen on the private addresses? A bit more secure
> because you don't expose you systems to the outside world:-)
> 

That is an idea. Another example is that I might want to run services
that should not be load balanced but sit behind the Serveriron. 

I am unsure how this will turn out with your email client but here goes:


	client - 158.152.1.43 - a host on the internet
		|
		|
		|
		|	
	Firewall - 195.1.1.1/24
		|
		|
		|
		|
		|  195.1.1.2/24
	|---------------|
	| Serveriron	|
	|---------------|
	    |	    |
Vlan17	    | 	    | vlan18
10.0.17.0/24|	    | 10.0.18.0/24
	    |	    |
	    | 	    |
	Server1	  Server2

At present I don't use VE interfaces, just source-ip with subnet's for
each VLAN.

Having a VIP IP address from the 195.1.1.0/24 range, I can successfully
load balance between the two servers. But what happens if I want to use
'server1' for a custom application without having to load balance but
still use a VIP address from the range?

Currently, when I use ip nat inside static, when the server initiates
outbound requests - to the Internet, it uses the correct real IP address
but when I try to SSH back to that IP address it doesn't work. Ping
however does but the Serveriron does the reply and the ICMP packets are
not being seen by Server1.

Inside server1 to external site

server1 IP -> Public IP -> outside client

10.0.17.10 -> 195.1.1.10 -> 158.152.1.43

But when outside client wants to talk to server1 directly without load
balancing

158.152.1.43 -> 195.1.1.10 -> 10.0.17.10 

However it doesn't appear to get to the server1
		
Any ideas?

> But it is possible to bind SSH to a VIP. It is even possible to admin all
> your systemen with 1 vip address and different tcp ports (and using port
> translations) witch has the benefit that you secure this single VIP with a
> ACL.

That is a very very nice idea... I am going to recommend it
> 
> And you can use your static nat solution. But again, static nat is
> bidirectional (makes no diffecrence if you use "static nat inside" or
> "static nat outside"). When you use static Nat to do source nat it is also
> possible to connect to the NAT address (directly connecting to your internal
> server) . Thats why Nat pools are more secure.
> 

If it is bidirectional then the above should work?

Thanks!




More information about the foundry-nsp mailing list