MASQUERADE works only for first 1-3 TCP packets

If I understand right, then use wand to use coLinux as router for the windows host? LAN0 you have connected only with an ADSL-Modem, and LAN1 is your internal network.

Check, that LAN1 does not have an IP address on Window side.
Check, that Windows host must use the IP address of coLinux eth1 as default gateway.

Have you enabled ip forward?
Simple NAT works with these commands:
iptables -A POSTROUTING -j MASQUERADE -t nat
echo "1" > /proc/sys/net/ipv4/ip_forward
It's very simple and natting in both directions.

Please lets see your firewall rules for the NAT, you can get it with iptables-restore.
The traffic way for TCP packets you can check with "watch iptables -L -v".

Thanks for your answer!

You understand right - coLinux is intended to act as router.

You're suggesting me to have other configuration than I want.

In fact both LAN0 and LAN1 in Windows have IP addresses.
LAN0 gets IP from ISP's DHCP srv (there is no ADSL modem in my network - I have ethernet LAN with private IP).
LAN1 gets IP from coLinux.
coLinux on LAN0 can establish PPPoE connection to provide Internet to itself and Windows.
Windows uses LAN1 coLinux's IP as main gateway.

Currently I have absolutely the same configuration with VirtualBOX (because I didn't manage to get coLinux work propertly) - and it works.

I did really sniffed my LAN interfaces with Wireshark. coLinux had an access to internet. Windows has managed to PING internet machines through coLinux (so masquerading partially worked). Windows even managed to open telnet connections!!! But no more - every subsequent packet after successfully opened (ACKnowledged TCP connection) has gone out of coLinux with LOCAL source IP address. It was not replaced by PPPoE's WAN IP.

The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards.

Why you used bridge for eth1 - LAN1? Do you really wand to provide your coLinux as Router for other machines on LAN1?

If you use coLinux router only for the host self, then a TAP would better work for eth1.

The other problem I would see with the IP address on LAN0. If the network stack will find any way without masquerading, then the packets will send directly. So the best way would be, that Windows does not have an ip address in the network of eth0. Give LAN0 no network address, Under Windows you should disable all network protocols for LAN0.

Hm... I think I've involved the problem.

CoLinux eth1 <-bridge-> Windows LAN1 - connects home LAN
CoLinux eth0 <-bridge-> Windows LAN0 - connects to ISP's LAN (and provides internet access for home LAN).

Windows LAN0 has all protocols disabled. Windows LAN0 has no IP at all.
LAN1, LAN0 - are both gigabit ethernet cards.

CoLinux has a DHCP server for eth1. So Windows gets its IP for LAN1 from eth1.
CoLinux eth0 receives IP address (like 192.168.x.x) from ISP. CoLinux connects PPPoE through eth0 to get real IP address.

>> Do you really wand to provide your
coLinux as Router for other machines on LAN1?
YES

>>The connection eth1 - LAN1 can made problems, if your network adapter have
hardware checksum. This typically a problem on Gigabit cards.
Currently I cannot understand this problem because I can sniff that packets with Wireshark in windows and with tcpdump in coLinux.
And my sniffer shows the following:
the packet that goes from Windows ETH1 reaches eth1 and then goes to eth0. But its source address is not changed. But, again, this apllies to 2nd or 3rd packet of TCP connection. This means that 1st packet goes off eth0 into internet with modified source IP address. And coLinux receives the response from internet hosts. Each other packet in established TCP connection goes with unmodified, local source ip address (192.168.x.x) that's why remote side cannot correctly reply.

Thank you very much for your kind help!

I hope, eth0 and eth1 have a different number for the first "x" in "192.168.x.x"? And the hardware cables on LAN0 and LAN1 are not connected - so packets from ISP can not find any way directly to network on LAN1.

Additional you needs to remember, that LAN0 and LAN1 runs in promiscuous mode so Windows gets all packets from both networks. In this case your Wireshark on LAN0 and LAN1 can confuse you. You can not difference between packets coLinxu has injected and packets Windows has injected. You should trace the packets only under Linux on eth1 and the home network on an additional PC, to see what is truly o the wire. And you should not enable IP forwarding under Windows (a registry hack). Check the Source-MAC of packet you means it is wrong. It is truly from coLinux? - And last: I hope, you have configured different MAC for coLinux devices, and they are unique all 4 network adapters (LAN0, LAN1, eth0, eth1)?