Connecting multiple LAN's through a single HP-UX system

[John Urchek]

I am new to managing network configurations and have been presented with a problem that I have been unable to solve.

We have 9 HP-UX workstations at one site that are on a private local LAN that is actually connected to a WAN for another organization through a T1 line.

We recently installed another HP-UX system at another facility and connected it to the primary LAN. We want this system to be able to see the data on all of the other 9 systems.

We installed a second LAN card in one of the 9 systems and set it up on the primary LAN. We have established communications on a one-to-one basis between the two systems connected to the primary LAN.

I thought that the solution to get the one system to see the 8 other systems was with the route command, but I could not make it work.

Important Note: The vendor for these systems which run complex custom software, went out of business a while back so they are still running 10.20.

Any help would be greatly appreciated.

John

[Steven E. Protter]

Shalom John,

Depending on the physical wiring arrangements you may try adding a virtual ip address to the other 8 stations on the same LAN as the second card that connects outside properly.

The primary lan in /etc/rc.config.d/netconf is [0] set up a secondary as [1]

If that does not work, you are likely to need 8 LAN cards and physical connectivity to make this work.

SEP

[Matti_Kurkela]

Let's see if I understood this correctly.

There seems to be two network segments:
- the private local LAN of 9 workstations
- the primary LAN, where the single new system is installed

Right?

What kind of IP addresses do these segments have? The important ones to know would be the network addresses, netmasks and maybe default gateway addresses on these segments.

If there's a NAT involved and the network segments have overlapping addresses, there will be additional problems.

Essentially, you're trying to make one of the 9 workstations into a bridge or a router (depending on how the IP addresses of those two network segments are arranged).

I'm not exactly sure whether HP-UX can be used as a bridge or not, but I don't think so. Routing should not be a problem.

Let's say that the network address of the private LAN of the 9 workstations is and the respective netmask is . The workstation with two LAN cards should have two IP addresses: on the private LAN side and on the primary LAN side. I'll call it "the router" for short.

The primary LAN with the single new HPUX at the other facility has the network address and netmask . The IP address of this machine is .

The router workstation should have IP forwarding enabled. To check it on HP-UX 10.20, run "nettune ip_forwarding". It might be enabled by default; if it is not, run "nettune -s ip_forwarding 1" to enable it. You'll have to add this to the boot scripts to make the setting permanent, if it is not the default setting.

The router workstation will automatically have local routes to both network segments because it has a configured NIC in each segment, so it does not need anything more.

On the other 8 old workstations, you'll need to add an extra (non-default) route to indicate how the new host can be reached.

The required route command would be like this:

route add host 1

This is saying: "to reach newhostIP, go to router-ipA: it knows the way further".

To make this permanent, you'd have to edit /etc/rc.config.d/netconf. Normally there should be only one group of ROUTE_* keywords, usually something like:
ROUTE_DESTINATION[0]="default"
ROUTE_MASK[0]=""
ROUTE_GATEWAY[0]=""
ROUTE_COUNT[0]=""
ROUTE_ARGS[0]=""

Find all the ROUTE_* keyword groups and check their numbers. Pick the next unused number (I'll call it X here) for your new route entry:

ROUTE_DESTINATION[X]="host "
ROUTE_MASK[X]=""
ROUTE_GATEWAY[X]=""
ROUTE_COUNT[X]="1"
ROUTE_ARGS[X]=""

The new system on the primary LAN will be able to reach the router workstation, but it needs an extra route entry to know how to reach the other 8:

route add net netmask 1

This means: "to reach any host on /, go to ; it knows the way further".

To make this permanent, add to /etc/rc.config.d/netconf this:

ROUTE_DESTINATION[X]="net "
ROUTE_MASK[X]=""
ROUTE_GATEWAY[X]=""
ROUTE_COUNT[X]="1"
ROUTE_ARGS[X]=""

MK

[John Urchek]

Matti,

Your understanding is correct. I have included the IP information below along with the netstat -rn output (sorry if the formatting is messy).

I am excited to try your suggestions, your information was thorough and sounds like an excellent solution.

The IP's for the remaining 8 systems are 10.5.0.50 - 10.5.0.58

The IP's for the system that has two network interfaces are:
10.5.0.50 and 172.16.112.253 The IP address for the router on the primary network is 172.16.112.253.

The remote system on the primary network has an IP address of 10.147.10.158 and the router address at this location is 10.147.10.3

Below is the current settings, before I implement your suggestions.

# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface Pmtu PmtuTime
10.5.0.50 127.0.0.1 UH 6 756715 lo0 4608
127.0.0.1 127.0.0.1 UH 0 785 lo0 4608
172.16.112.253 127.0.0.1 UH 0 17502 lo0 4608
default 10.5.0.1 UG 1 25681 lan0 1500
10.5 10.5.0.50 U 9 7666890 lan0 1500
10.147.10.0 172.16.112.3 UG 0 669 lan1 1500
172.16.112.0 172.16.112.253 U 0 0 lan1 1500

[John Urchek]

Matti,

The 9 systems on the private local lan are set to use IP's 10.5.0.50-58 and the router that they are connected to is 10.5.0.1.

The review system at this site that has the two network cards is 10.5.0.50. The other card on the primary network is 172.16.112.253 and it is connected to a router set to 172.16.112.3

The review system at the other site has an IP address of 10.147.10.158, and is connected to a the router with an IP of 10.147.10.3.

I verified that IP Forwarding was enabled on the system with two network cards.

I ran the route command that would enable the 8 remote systems to reach the new host on the primary LAN. specifically:
route add host 10.147.10.158 10.5.0.50 1

This command was successful, but I immediately tried to ping the off-site review system and it failed.

I then tried to set the other system to see the 8 systems using:
route add net 10.5.0 netmask 255.255.255.0 172.16.112.253 1

This command failed, stating:
add net 10.5.0: gateway 172.16.112.253: Network is unreachable

I should point out that pinging the 172.16.112.253 address works just fine.

I have heard a term unroutable IP addresses, could this be my problem?

Could there be a setting on one of the routers that is interfering with the route command being successful?

I would appreciate any guidance that you can share.

[Matti_Kurkela]

>The review system at this site that has the two network cards is 10.5.0.50. The other card on the primary network is 172.16.112.253 and it is connected to a router set to 172.16.112.3

> The review system at the other site has an IP address of 10.147.10.158, and is connected to a the router with an IP of 10.147.10.3.

So your network is even more complex than was apparent from your original description. The review system at the other site is not connected to the same network segment as the review system at "this" site, as I originally assumed from your use of the term "primary network".

Your network at the other site is using a completely different network segment. One is not even a sub-net of the other. This suggests there may be even more complexity. Based on your latest information, the route between your two review systems looks like this:

Review system 10.5.0.50 / 172.16.112.253
<-> segment 172.16.112.0/255.255.255.0

<-> router 172.16.112.3

<-> (??? zero or more steps here???)

<-> router 10.147.10.3

<-> segment 10.147.10.* (netmask unknown)

<-> review system 10.147.10.158


In theory, the router IP addresses 172.16.112.3 and 10.147.10.3 might refer to the same router device which just has interfaces to both network segments. If so, it would be necessary to add some extra routing table entries to that router to make this work... but I'm afraid the situation is not likely to be that easy in practice.

You should contact your network administrator(s) and present the problem to them. Based on what you've told, it may be impossible to solve this problem without involving them in some way.

This problem is not likely to be solved without a _complete_ picture of the network and access to the configuration of all routers between the systems. You might even have to consider some sort of a VPN solution.

> route add net 10.5.0 netmask 255.255.255.0 172.16.112.253 1

> This command failed, stating:
add net 10.5.0: gateway 172.16.112.253: Network is unreachable

This is because the system 10.147.10.158 is not directly connected to the segment 172.16.112.*. Your system would have to somehow advice the router 10.147.10.3 (or any routers after that) to direct the package towards 172.16.112.253 although the destination address is 10.5.0.*.

This would be called "source routing", and in current routers it's made impossible, with a good reason: it was way too easy to use it for network attacks in the past. Trying to send any messages with source routing IP options is also likely to trigger big red flags in any IDS that happens to see the traffic.

If system 10.147.10.158 is connected only to that segment, the only way for it to reach other network segments is to send the messages to the router 10.147.10.3 and let it decide what happens next.

The term "unroutable addresses" usually refers to network segments 10.*.*.*, 172.16-31.*.* and 192.168.*.*. There are some other unroutable addresses, but these are the most widely known. These network segments are available for "internal use only" for anybody, so they are definitely not unique world-wide.

This just means they cannot be used in the public Internet traffic. But if your organization takes care to keep these addresses unique inside your organization, you can use them in your internal systems... and your organization is obviously using them.

MK