[coLinux-devel] [ colinux-Bugs-2965587 ] MASQUERADE works only for first 1-3 TCP packets

[SourceForge.net <no...@so...>]

Bugs item #2965587, was opened at 2010-03-08 19:23
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MASQUERADE works only for first 1-3 TCP packets

Initial Comment:
having the following config:

eth0 - bridged with windows LAN0
eth1 - bridged with windows LAN1

PPPoE connection established from coLinux through eth0.
pings/HTTP and etc work perfectly from coLinux.

trying to get Internet from Windows (iptables configured POSTROUTING/MASQUERADE thru ppp0):

pings from windows work OK;
but TCP - does not.
According to Wireshark only couple packets in the begging of TCP session are masqueraded. Others go unchanged with local IPs in source field. So TCP connection can be established from windows, but w/o further communication.

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2010-03-31 01:41

Message:
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.

----------------------------------------------------------------------

Comment By: Gowa (kamyshnikov)
Date: 2010-03-14 18:13

Message:
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.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2010-03-08 23:21

Message:
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".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788