Host descriptions can be found down below.
If I start an upload job from Host 2 to a public ftp server or to an
ftp/sftp/rsync server on private subnet 10.10.10.0/24 I am not able to keep
this connection established. It´s changing it´s state from 10 kbyte/s to
stalled and back, and so on.
I´m using a 1 Mbit/s SDSL connection so I should have a minimum of 60-70
kbyte.
Strange to me is, that if I start a download job everything works well.
The other way around from vis-á-vis. If I start an upload job from
ftp/rsync/sftp client on private subnet 10.10.10.0/24 everything works well
and if I try to download from private subnet 10.0.0.0/24 I get the same
troubles as mentioned before.
In this case I´m not able to test from the public internet, because of only
my private subnet traffic will be routed through host 1 and further to
proxyarp client host 2. Requests from public web won´t go that way.
At last I should tell you that uploads and downloads between host 1 and host
2 works very well. This is not through a tunnel but from host 2 eth 1 to
host 1 eth 0 by sftp. Of course host 1 is able to upload and download from
the internet or to the internet very well, too. Host 1 isn´t able to talk to
my tunnel (private subnel 10.10.10.0 and 10.0.0.0). It doesn´t know anything
about it because of host 2 is the tunnel terminator.
So the problem should be based in upload connections from host 2 to hosts
after host 1.
The next host after host 1 is my providers cisco box. There is nothing
special on it to find.
==========================================================================Host
1: Firewall connected to SDSL modem/public internet
Shorewall Version 2.4.1 (status2.txt while trying to upload)
>ip route show<
82.100.235.14 dev eth2 scope link
172.16.10.252/30 dev eth1 proto kernel scope link src 172.16.10.254
82.100.235.0/28 dev eth0 proto kernel scope link src 82.100.235.11
10.0.0.0/24 via 172.16.10.253 dev eth1
127.0.0.0/8 dev lo scope link
default via 82.100.235.1 dev eth0
>ip addr show<
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:06:5b:50:a6:c2 brd ff:ff:ff:ff:ff:ff
inet 82.100.235.11/28 brd 82.100.235.15 scope global eth0:1
inet 82.100.235.5/28 brd 82.100.235.15 scope global secondary eth0:2
inet 82.100.235.13/28 brd 82.255.255.255 scope global secondary eth0:0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:11:95:25:4e:14 brd ff:ff:ff:ff:ff:ff
inet 172.16.10.254/30 brd 172.16.255.255 scope global eth1
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:13:46:39:de:a4 brd ff:ff:ff:ff:ff:ff
inet 10.254.254.254/32 brd 10.255.255.255 scope global eth2
/etc/shorewall/proxyarp
82.100.235.14 eth2 eth0 No
====================================================================================================================================================Host
2: Firewall and VPN Gateway in the proxyarp DMZ zone from Host 1´s eth2
Shorewall Version 2.4.2 (status.txt while trying to upload)
>ip route show<
82.100.235.0/28 dev eth1 proto kernel scope link src 82.100.235.14
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.175
10.10.10.0/24 via 82.100.235.1 dev eth1
127.0.0.0/8 dev lo scope link
default via 82.100.235.1 dev eth1
>ip addr show<
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:b0:d0:f4:98:db brd ff:ff:ff:ff:ff:ff
inet 10.0.0.175/24 brd 10.255.255.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:13:46:31:b0:14 brd ff:ff:ff:ff:ff:ff
inet 82.100.235.14/28 brd 82.255.255.255 scope global eth1
==========================================================================
I am around with this problem for 2 or more weeks. I would really appreciate
it, if someone could be possible to provide a solution.
At last I would like to underline that I have tested with other kernels,
cables, nics, shorewall and iptables versions, even completely other routing
hardware - still the same problem.
Thanks for any help.
Cheers
Mike