[SOLVED] Tricky internet sharing problem.

Chris_no · 06-01-2009, 05:03 AM

Hi!

Im trying to share my internet connection from one computer to another.

Internet comes in through wireless to my main computer (Ubuntu Hardy 8.04)
on card wlan0.
It is then supposed to be forwarded to computer two (Ubuntu Jaunty server 9.04) over a hub on card eth0.

The computers see eachother on ping, ssh, tcpdump, nmap etc.

The problem is that my main computer refuses to route traffic from
eth0 to wlan0.

I already have a thread open on ubuntuforums and most of the nessesary
details are listed there.

http://ubuntuforums.org/showthread.php?t=1174278

I also have a thread on a norwegian linuxforum.

http://linux1.no/forum/viewtopic.php?f=226&t=221663

If you need any extra info I'll post it.

nidsche · 06-01-2009, 06:54 AM

Quote:

Originally Posted by Chris_no

Hi!

Im trying to share my internet connection from one computer to another.

Internet comes in through wireless to my main computer (Ubuntu Hardy 8.04)
on card wlan0.
It is then supposed to be forwarded to computer two (Ubuntu Jaunty server 9.04) over a hub on card eth0.

The computers see eachother on ping, ssh, tcpdump, nmap etc.

Hi,

I assume, that you want to use NAT on this?

Therefore you should setup iptables and do additionally the following command

echo 1 > /proc/sys/net/ipv4/ip_forward

beside this you need to add a default route to the machine with Wlan

regards Norbert

JulianTosh · 06-01-2009, 07:10 AM

Quote:

Originally Posted by Chris_no

The problem is that my main computer refuses to route traffic from
eth0 to wlan0.

It might be that it's routing just fine... but the computers past your wan0 interface have no idea how to get back to the 192.168.1.0/24 network on eth0.

To fix this, you'd need some kind of MASQUERADE/NAT statement to change the source of the exiting 192.168.1.0/24 packets to the IP of your wan interface.

something as simple as:
iptables -t nat -A POSTROUTING -o wan0 -s 192.168.1.0/24 -j MASQUERADE

might fix your problem. BTW, you can figure out exactly where packets are being dropped or routed incorrectly by specifically tcpdumping each interface as you ping through it.

Chris_no · 06-01-2009, 10:21 AM

Unfortunatly I have already edited sysctl.conf to make that 1 nidsche.
So that doesn't help me.

I have exhausted all the guides I could find.

As Stated on ubuntuforum.

netstat -nr

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
*.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.*.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
***.***.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         *.0.0.*      0.0.0.0         UG        0 0          0 wlan0

iptables -L

Code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  192.168.*.0/24       anywhere            state NEW 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Should this somehow be different?

If you need more info just tell or look at this link.

http://ubuntuforums.org/showthread.php?t=1174278

The packages captured in tcpdump reads like this.

Error was host unreachable.

Client_computer eth0(the one pinging *.0.0.** and who has no internet)

Code:

16:57:32.461627 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 17.163.*.*.in-addr.arpa. (44)
16:57:32.577582 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? ***.0.0.***.in-addr.arpa. (42)
16:57:33.461504 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 17.163.***.**.in-addr.arpa. (44)
16:57:33.577474 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 251.0.0.*.in-addr.arpa. (42)
16:57:35.465292 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 17.163.***.**.in-addr.arpa. (44)
16:57:35.581251 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? ***.0.0.***.in-addr.arpa. (42)
16:57:37.590973 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? *.*.168.192.in-addr.arpa. (42)
16:57:37.591394 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? *.*.168.192.in-addr.arpa. (42)
16:57:37.591513 IP *.local.mdns > *.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
16:57:37.696849 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? *.*.168.192.in-addr.arpa. (42)
16:57:37.697134 IP *.local.mdns > *.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
16:57:39.580834 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 251.0.0.*.in-addr.arpa. (42)
16:57:39.653616 IP *.local.netbios-dgm > *.168.*.255.netbios-dgm: NBT UDP PACKET(138)
16:57:39.653676 IP *.local.netbios-dgm > *.168.*.255.netbios-dgm: NBT UDP PACKET(138)
16:57:39.755030 IP *.local.mdns > *.0.0.251.mdns: 0 PTR (QM)? 255.*.168.192.in-addr.arpa. (44)

Host_computer eth0(The card wired to client)

Code:

16:57:24.530495 IP *.local.mdns > ***.0.0.251.mdns: 0 PTR (QM)? 17.163.**.***.in-addr.arpa. (44)
16:57:24.646460 IP *.local.mdns > ***.0.0.***.mdns: 0 PTR (QM)? ***.0.0.***.in-addr.arpa. (42)

Host_computer wlan0(The card with internet)

Code:

16:57:24.410635 IP **.***.163.17.www > *.lan.37336: F 1083056335:1083056335(0) ack 2376483907 win 157 <nop,nop,timestamp 3426191420 6601723>
16:57:24.411537 IP *.lan.35633 > *.lan.domain: 45673+ PTR? *.0.0.*.in-addr.arpa. (40)
16:57:24.414071 IP *.lan.domain > *.lan.35633: 45673* 1/0/0 PTR[|domain]
16:57:24.414155 IP *.lan.52442 > *.lan.domain: 9900+ PTR? 17.163.***.**.in-addr.arpa. (44)
16:57:24.429468 IP *.lan.domain > *.lan.52442: 9900 NXDomain 0/1/0 (104)
16:57:24.450387 IP *.lan.37336 > *.***.163.17.www: . ack 1 win 159 <nop,nop,timestamp 6609222 3426191420>

Now I don't speak tcp very well so anybody?

Chris_no · 06-01-2009, 10:48 AM

From looking at the tcp data I get the impression that the wlan0 got the message but didn't manage to answer back.

This must then be eighter bacause it is not allowed or doesn't know how???

It seems silly to me that a network card doesn't know how because I assume that the message contains some kind of return to sender.

Chris_no · 06-01-2009, 01:59 PM

HORRAY PROBLEM SOLVED!!!

As always it was something stupid.

Me being CERTAIN that the problem was at the host
forgot all about the fact that my poor little client
needed a default gateway.

No wonder I didn't find anything. But could ping in and out.

Quote:

route add default gw 192.168.*.*

solved everything.

Hope I can be an example for others to learn from...