telnet client with source IP option

[Bjarne Dein_2]

Does anyone know where to get a telnet client for for HPUX, with which you can telnet from a virtual host and force the client to use a given IP/interface, when telnet'ing to another host?

The issue is, that I have a cluster with many interfaces and even more IP addresses, from which I need to connect to a given host (in this case a switch for management) and the host only accepts one specific IP.

Thank in advance!

Cheers

Bjarne Dein

[Mark Greene_1]

"and the host only accepts one specific IP. "

Most systems only have one IP address. This is how connectivity to most systems works. Or, is the issue that your HP box has 2 NICs and you want to route traffic to a specific host through a specific one?

If so, put the name & IP of the host in question in the /etc/host file on the HP box. Then check the man page for route, and add a route to the second host via whichever Interface you want.

HTH
mark

[Bjarne Dein_2]

Hi Mark,

Well there is more to it, than just this.

We have a cluster on which we run a virtual package, from which operators controls and manage all our network equepment (some tusinds!), and they have be set up ONLY to accept ONE ip source address, which is the package.

So I "just" need this telnet client (like in Free BSD) on which I can put an option "-s "

Cheers,

Bjarne

[Mark Greene_1]

I'm still not seeing it. Typically this sort of thing is transparent to applications, and is managed through firewalling and routing. Static routes aren't the prefered method, but it really sounds like that is what you are asking for.

Is it the telnet out of the HP that you want to speficially direct, or is it really the telnet connection on the sencond host (which sounds like routers and switches from your second posting) that you want to limit as accepting connections from only the HP?

mark

[Gary L. Paveza, Jr.]

Maybe this will clear it up. I see the same issue when using MC/ServiceGuard. Say I have two hosts, one is 1.2.3.4 and the other is 1.2.3.5. I have packageA which runs as part of the cluster, and it has an IP address of 1.2.3.6. Now, that package can be on either system, and the users connect to 1.2.3.6. However, when telneting while logged into that package (1.2.3.6), the IP address listed as the source will be either 1.2.3.4 or 1.2.3.5 depending on which system is playing host to packageA (1.2.3.6).

[Mark Greene_1]

Gary,

When you move from one system to the other, do you, as part of the fail-over, change anything in DNS/NIS/host file or change anything in the routing tables to reflect the physical IP change?

mark

[Gary L. Paveza, Jr.]

No. The whole idea is that the user should never know you moved. The users only know the IP address (and name) of the package. The IP addresses of the servers themselves never change. The package IP address gets mapped on top of one of the existing LAN cards. In effect, both the server IP address and the package address can be used to connect to the same server. /etc/hosts on both systems have correct entries for the package as does the DNS server. From what I can determine, there is no way to get the server to identify you using the package address - which would be very useful for firewalls, etc.

[Bjarne Dein_2]

All the equipment will only permitted administration from this ONE single IP.

And since they (routers/switches etc.) traces the "wrong" source IP, when telnet'ing from the Operation machine, no one can admin. the equip. anymore.

[Mark Greene_1]

Gary,

Ok, that makes entire good sense. So do you see how this translate into Bjarne's telnet question? Paritcularly if everything can be accessed by host name.

mark

[Bjarne Dein_2]

I've just talked to HP about it, and they say, that as far as they know, the lowerst IP will act as the source IP...

So if this is true, and the packed "owns" the lowerst IP in that range, it will automatic become the source IP, if it gates through this network/lancard - not bad maybe, I'll try it tomorrow!

Bjarne:-)

[Gary L. Paveza, Jr.]

I was merely trying to make his question a bit clearer by providing another example. No points were required :) Anyway, the comment about the lowest IP address figures - of course my systems are exacty backwards to that. Wish they had mentioned that little detail when HP was helping us configure our Superdome/MCServiceGuard setup.

[Mark Greene_1]

Bjarne,

Do this:

"And since they (routers/switches etc.) traces the "wrong" source IP, when telnet'ing from the Operation machine, no one can admin. the equip. anymore. "

mean that they are setup for the virtual IP and no the IP of the NIC on any of the HP's in the cluster?

[Jim Keeble]

The source address by default of the outbound telnet packets is the "primary" ip address of the interface, ie., the one assigned to lanX:0. Not sure if that's what you meant by the "lowest" IP address, but it has nothing to do with the numerical value of the IP.

The way this is changed programatically would be for the local telnet code to bind() the desired local IP address to it's socket before calling connect(). Your freeBSD client supports this with the -s switch, HP's telnet client (nor ftp, rlogin, etc., for that matter) have support for this. Since the local address isn't bound, these clients' packets acquire the local IP of the interface they leave the HP from. Since the route to your remote systems uses your primary IP, that's the IP that is used.

So you would need to acquire and compile code for a telnet client that has an option like the freeBSD's telnet client to change the local binding.

There is an unsupported workaround that _might_ work for you. First, the router that leads to your remote systems MUST support a function called "proxy arp". If not, you need the alternate telnet .

Second, you need to add a route to the remote network using a metric of 0. You can make this a customer defined command part of your package. Let's say your package IP is 192.168.1.10 and the telnet servers are on remote network 192.168.2.0 . The command to add the route is :

route add net 192.168.2.0 192.168.1.10 0

This route will cause all traffic destined for the remote network to leave through the package IP's interface since the gateway is the package IP. The proxy arp function is REQUIRED because the 0 metric fools HP-UX into thinking the remote network is on the same physical network with no router in between. The router answers the arp requests for IP's on the remote network with it's own MAC address.

When the package stops, it should remove the route:

route delete net 192.168.2.0 192.168.1.10 0

Too much trouble ? Convince the firewall/server admins to allow both of the primary IP's of the Serviceguard nodes through. Much simpler for everyone.

Good luck!

[W. Delamore]

We did have the same problem with a Java application which did not bind to its logical IP
on HP-UX 11i.

We did have a workaround for this when we were running on linux. There we created a route:

# route add gw

On hp-ux we also created a route.

# route add 0

But instead of using arp proxy we simply created following arp entry on the application host.

# arp -s

This works for us !