might be a stupid remark, but if you want machines to talk to each other inside the same network, you have to put them in the same network so, if you configure: 192.168.0.1/32 and 192.168.0.2/32, then these 2 machines are on a different network, so outgoing traffic will go via it's network with the default route, which is your 192.168.1.x/24 network. So... i suggest you configure the interface on lo on at least 192.168.0.30 (or maybe more clear: 24) and go with that.... What's the reason you put /32 on those lo interfaces? what will you use them for? kr, Rik Bobbaers -- http://harry.enzoverder.be linux/unix/system/network/security/hardware admin infrastructure architect > I just confirmed that using dummy interfaces with a real netmask does > actually make things work the way I want. I notice the lo /32 interface > still gets created with the same IP. Are there any drawbacks in doing it > this way? > > Gordan > > Gordan Bobic wrote: >> Adrian Reyer wrote: >>> Hi Gordon, >>> >>> On Thu, Oct 14, 2010 at 10:22:15PM +0100, Gordan Bobic wrote: >>>> Is there a way to add a static route to a VM on loopback? >>> >>> You don't need to. As the guest has no network, it doens't need to >>> route, either. The kernel has the network and does the routing. >>> Do you experience any problems with this setup? >> >> Yes I am seeing a problem with this setup. >> >> Host A: >> lo:192.168.0.1/32 >> eth0: 192.168.1.1/24 >> >> Host B: >> lo:192.168.0.2/32 >> eth0: 192.168.1.2/24 >> >> When host A connects to 192.168.0.2, the connection looks like it came >> from 192.168.1.1, rather than 192.168.0.1. I don't want my app on host B >> binding on listening on 192.168.1.0/24 interface. I want the connection >> to be going via the internal loopback only. I also want to keep the >> iptables rules relatively sane and intuitive. >> >> Normally, this would be implicit by the network scope, but since lo is >> different and setting 192.168.0.1/24 on it would make the local host >> respond on the entire range, I need an alternative solution that would >> work more sensibly. Would using a dummy network device work for this? Or >> is there a better way? >> >> Gordan > >