How do I set the source address on a multi-homed host?

[Alin-Adrian Anton]

Daniela wrote:
> On Saturday 12 February 2005 16:06, Volker Kindermann wrote:
> 
>>Hi Daniela,
>>
>>
>>>Yes, this happens when I connect from my machine (which functions as a
>>>router with NAT to allow the other LAN machines connect to the internet)
>>>to another LAN machine. When the router establishes a connection to
>>>another point in the intranet, the source address used is my official IP,
>>>and not 10.0.0.1, which is the intranet IP of the router.
>>
>>please post the output of the following commands:
>>
>>ifconfig -a
> 
> 
> [Showing only relevant entries. My official IP is replaced with x.x.x.x]
> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet6 fe80::202:44ff:fe66:bf4%rl0 prefixlen 64 scopeid 0x1 
>         inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.255
>         ether 00:02:44:66:0b:f4
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet6 fe80::20a:cdff:fe00:c076%rl1 prefixlen 64 scopeid 0x2 
>         inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255
>         ether 00:0a:cd:00:c0:76
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> 
> 

I really don't see why you use A-class netmask. It's very probable that 
a C-class netmask would suffice:

rl1 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255

Also, the routes for rl1 which is the internal interface don't look normal.

You should have only one rl1 entry, like this:

10.0.0.0          link#2             UC          0        0   rl1

And not:
> 10                 link#2             UC          2        0    rl1
> 10.0.0.3           00:0d:61:17:fc:30  UHLW        1      444    rl1    903
> 10.255.255.255     ff:ff:ff:ff:ff:ff  UHLWb       0     2453    rl1

See? Why special route for 10.0.0.3?

Besides that, I hope your nat and firewall configs are not mangled too. 
Try these changes first, and see if things get normal.

PS: there is *no way* for the behaviour you explained to happen under 
normal circumstances, unless you *explicitly*, intentionally or by 
mistake have configured the gateway to do so.


Regards,
-- 
Alin-Adrian Anton
GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785  2F7C 5823 ABA0 1830 87BA)
gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA

"It is dangerous to be right when the government is wrong." - Voltaire