Hi,

On Tue, Dec 17, 2002 at 12:12:51PM -0500, Jan Harkes wrote:
> Typically this is caused by a bad firewall setup or incorrect routing.
> I don't know how your setup is, but 192.168.0.2 is an address in a
> private range, so it is typically not routable across the internet.
> 
> Perhaps you have a firewall that is passing packets through, but doesn't
> do any ip header rewriting (NAT/masquerading), and as a result the
> server cannot send any responses back to the client, it simply doesn't
> know the right address to get back to the client.

Well, here is the network layout:


+--------+
Š client | 192.168.0.2 eth0
+--------+     \
                \
	    192.168.0.1 eth0
	         +---------+    eth2			 (ppp0)
		 | server -+-192.168.2.1===ADSL modem-- public IP addr
		 +---------+
		192.168.1.1 eth1
		     |
		     .

The SVM is running at the 192.168.2.1 interface, the public IP addr is
available on ppp0 (pppoe). I'm running nearly all server processes on
192.168.2.1 since the other interfaces normally (note: normally, not
while testing this) run ipsec an most servers don't like to bind to an
ipsec interface.

All subnets are declared /24, here is the routing table:

217.5.98.41 dev ppp0  proto kernel  scope link  src 217.226.148.10 
192.168.2.0/24 dev eth2  proto kernel  scope link  src 192.168.2.1 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1 
default via 217.5.98.41 dev ppp0 

I've attached a "tcpdump -i eth0" output from the server... sadly, I
haven't located the .deb package on your site which contains the
rpc2portmap tool.

regards
-- jochen