Re: [uml-user] Networking issues

[Christopher M. <chr...@ya...>]

--- ghannemann <ger...@pr...> wrote:

> Hi everybody - my first post!
> 
> I have been running UML successfully  close to 18 months.
> I general run a Debian Sarge host, using 2.6.8 kernel and the UML's still
> run a 2.4.27 kernel.
> The host hardware is an Intel based system with 2G of memory and the
> production server as an IBM x346
> 
> All seems to run well until I tried to bond two 1G Ethernet ports.
> I use ifenslave to create a virtual network interface on the host called
> bond0 using the round robin mode.  I start the UML's in the usual manner
> using uml_switch etc.  So the UML is assigned tap0.
> 
> All server (host and UMLs) are on the same subnet as the client PC accessing
> the servers.
> 
> The problem is as follows, (all test use ping):
> I cannot access the UML from any PC.
> I cannot access the network from the UML.
> I can access the host from networked PC's
> I can accss the UML from the host. 
> I can access the host from the UML.
> 
> As part of the UML boot, it made changes to the host
> /proc/sys/net/ipv4/if_forward, setting it to '1'
> Also it made some changes using ARP (do not really understand this bit yet)
> 
> I then added the following:
> iptables -t nat -A POSTROUTING -o bond0 -j MASQUERADE (I hope remembered
> this correctly)

This has nothing to do with bonding and everything to do with masquerading.

UML guest = the UML kernel you are running
UML host = the host kernel the UML guest is running under

It makes sense that the UML guest can make TCP connections outwards to the network but hosts on
the network can't make TCP connections inwards toward the UML guest because of how masquerading
works.

When a UML guest tries to make a TCP connection to the network in your scenario, the iptables
driver in the UML host intercepts the TCP SYN packet, and replaces the source IP address with the
IP address assigned to the interface bond0, and it makes a note of which source port the SYN
packet is using in a translation table so it can do the reverse mapping to packets sent in reply
to that port.  When a reply comes back to that same port on bond0, the iptables driver replaces
the destination address with the address of the tap0 interface.

Now look what happens when a host on the network tries to initiate a TCP connection with the UML
guest.  The SYN packet comes in on bond0 and the iptables driver has no entry for it in its
translation table because only packets going out on bond0 (the -o bond0 option on iptables) can
establish entries in the translation table.

What you need to do to establish two-way communication between the uml guest and other hosts on
another network connected to the UML host is give the other hosts on the network a route to the
UML's address with the UML host as the gateway.

Suppose the real network (the one bond0 is attached to) is 10.0.1.0 with a netmask of
255.255.255.0, bond0 has address 10.1.0.1 assigned, and the tap0 network is 10.0.2.0 with a
netmask of 255.255.255.0, with tap0 having the 10.0.2.1 address and the UML guests's eth0 (the
other end of the tap0 interface) having the 10.0.2.2 interface.

You need to add a route like this on the UML guest:
   route add default gw 10.0.2.1

And you need to add a route like this to any hosts on the real network that want to communicate
with the UML guest:
   route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.1.1

At that point a host on the 10.0.1.0/24 network should be able to ping the UML guest and the UML
guest should be able to ping it back.

Chris Marshall

> 
> After this:
> I can access the network from the UML
> I still cannot access the UML from the network.
> I unsuccessfully fiddled a little with the routing tables.
> 
> Has anybody have any ideas how I can correct this problem.  I suspect I need
> to add another iptables rule to allow network access to the UML.
> 
> Thanks you all in advance
> Buggy
>