Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I am using Ubuntu 12.04 as the platform for a VirtualMin installation which will host multiple websites for the same organization. For this, I need to bind multiple IP addresses in the same subnet to the server and I am having problems doing so.

I can bind the extra addresses either by using additional virtual nics (it is a vm) or by using virtual interfaces of one nic. In both cases the additional addresses ping just fine from any host on the local network, but only the primary nic can be pinged from any remote network. The behavior is just like what would happen if you configured a single nic with no gateway so I imagine this is an issue with the routing table, but I just can't produce a working config. Can anyone please take a look at my config and possibly point me in the right direction?

/etc/network/interfaces

# The loopback network interface
auto lo eth0 eth0:0
iface lo inet loopback


# The primary network interface
iface eth0 inet static
        address 10.192.3.104
        netmask 255.255.224.0
        gateway 10.192.0.1
        broadcast 10.192.31.255
        network 10.192.0.0
        dns-nameservers 10.192.0.210 10.192.0.198 127.0.0.1


iface eth0:0 inet static
        address 10.192.30.52
        netmask 255.255.224.0

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.192.0.1      0.0.0.0         UG    100    0        0 eth0
10.192.0.0      0.0.0.0         255.255.224.0   U     0      0        0 eth0
share|improve this question
    
Does the remote network have a routing entry for the 10.192.0/27 subnet (and not just the 10.192.3.104 host)? Can the 0.1 gateway ping the 30.52? Have you checked with tcpdump if any pings from outside make it to 30.52 (i.e. do they get dropped on the way in or out)? –  zwets Mar 12 '13 at 21:29
    
I think some router between your local and remote networks has a wrong netmask for the 10.192.0.0 network as mentioned by @zwets. Change eth0:0 from 10.192.30.52 to 10.192.29.52, 10.192.28.52, 10.192.27.52... and you'll find an IP that works. –  Eric Carvalho Mar 12 '13 at 22:18
    
@EricCarvalho This turned out to be a red herring; the tcpdump output provided (@James, please move that to the question) shows the packets arriving at the machine. No replies coming out of it though. What remains odd is that this only happens for remote subnets. @James No firewall running on it? What does iptables -L give? –  zwets Mar 13 '13 at 11:12
    
I'm also curious what the output of the following commands is ip route get to 10.1.0.200 from 10.192.3.104, ip route get to 10.1.0.200 from 10.192.30.52 and ip route get to 10.192.30.52 from 10.192.3.104. –  zwets Mar 13 '13 at 21:18
add comment

2 Answers

Maybe a bit of a long shot, but have you tried enabling ipv4 forwarding? I don't know the details of IP chains, but it could be that the reply to a ping on the eth0:0 interface needs a 'forward' via the eth0, in particular when it needs routing.

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

Or

# sudo sysctl -w net.ipv4.ip_forward=1

And if it works, put it in /etc/sysctl.conf.

share|improve this answer
add comment

A couple of things lead me to focus on the server side and not the network side.

First of all, a Windows server in the same network can have a secondary address added and immediately communicate in exactly the same way the Ubuntu server can't.

Also, no secondary address can be pinged. To use your example, I could change the final octet of the secondary address to be one higher than the primary with the same problem. For example 10.192.10.138 / 139 still has the same issue.

I have run tcpdump and observe that the primary shows both the incoming icmp request and outgoing reply. Pings to the ip address of the secondary only show the incoming. The outgoing appears to be dropped. For example

16:10:08.149550  In 00:1f:27:40:04:00 ethertype IPv4 (0x0800), length 100: 10.1.0.200 > 10.192.10.138: ICMP echo request, id 64546, seq 6, length 64
16:10:08.149571 Out 00:50:56:be:0a:89 ethertype IPv4 (0x0800), length 100: 10.192.10.138 > 10.1.0.200: ICMP echo reply, id 64546, seq 6, length 64
16:10:09.145736  In 00:1f:27:40:04:00 ethertype IPv4 (0x0800), length 100: 10.1.0.200 > 10.192.10.138: ICMP echo request, id 64546, seq 7, length 64
16:10:09.145759 Out 00:50:56:be:0a:89 ethertype IPv4 (0x0800), length 100: 10.192.10.138 > 10.1.0.200: ICMP echo reply, id 64546, seq 7, length 64
16:10:38.055885  In 00:1f:27:40:04:00 ethertype IPv4 (0x0800), length 100: 10.1.0.200 > 10.192.10.185: ICMP echo request, id 12835, seq 1, length 64
16:10:39.055943  In 00:1f:27:40:04:00 ethertype IPv4 (0x0800), length 100: 10.1.0.200 > 10.192.10.185: ICMP echo request, id 12835, seq 2, length 64
16:10:40.056085  In 00:1f:27:40:04:00 ethertype IPv4 (0x0800), length 100: 10.1.0.200 > 10.192.10.185: ICMP echo request, id 12835, seq 3, length 64

But where does this lead me to investigate next?

share|improve this answer
1  
This is not an answer. In fact, it is a question ;-). Please move this information to the question. It indeed seems to be a server side issue, given the tcpdump output. The pings seem to get dropped 'inside' the server. Hmmm. –  zwets Mar 13 '13 at 10:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.