Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am having trouble with forwarding on a system which hosts a few headless VirtualBox VMs. I have not changed anything but the configuration has stopped working. The VMs have IP addresses on their own subnet which I have to route to myself. So the host has it's IP and gateway, and an alias which is used as a gateway by the VMs.

The host configuration:

root@greece:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 0c:c4:7a:02:5d:36
          inet addr:192.99.46.35  Bcast:192.99.46.255  Mask:255.255.255.0
          inet6 addr: 2607:5300:60:5123::/64 Scope:Global
          inet6 addr: fe80::ec4:7aff:fe02:5d36/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31246 errors:0 dropped:35 overruns:0 frame:0
          TX packets:5818 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:30002593 (28.6 MiB)  TX bytes:3268821 (3.1 MiB)
          Memory:fb920000-fb940000

eth0:0    Link encap:Ethernet  HWaddr 0c:c4:7a:02:5d:36  
          inet addr:198.50.241.112  Bcast:198.50.241.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Memory:fb920000-fb940000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2191 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2191 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2781224 (2.6 MiB)  TX bytes:2781224 (2.6 MiB)

root@greece:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.99.46.254   0.0.0.0         UG    0      0        0 eth0
192.99.46.0     *               255.255.255.0   U     0      0        0 eth0
198.50.241.0    *               255.255.255.0   U     0      0        0 eth0

root@greece:~# iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1088  987K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    1    84 ACCEPT     all  --  *      *       198.50.241.0/24      0.0.0.0/0           
    1    60 ACCEPT     all  --  *      *       0.0.0.0/0            198.50.241.0/24     
    1    72 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 ctstate NEW
   40 13120 UDP        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW
    0     0 TCP        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 ctstate NEW
   40 13120 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-proto-unreachable

Chain FORWARD (policy ACCEPT 109 packets, 7776 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 854 packets, 1879K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain TCP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain UDP (1 references)
 pkts bytes target     prot opt in     out     source               destination
root@greece:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

This configuration should work. I can reach the host's main IP (192.99.46.35) from the VMs. I get an interesting response when I try to ping the hosts gateway (192.99.46.254).

root@minecraft:~# ping -c 2 192.99.46.254
PING 192.99.46.254 (192.99.46.254) 56(84) bytes of data.
From 198.50.241.112: icmp_seq=1 Redirect Host(New nexthop: 192.99.46.254)
64 bytes from 192.99.46.254: icmp_req=1 ttl=254 time=47.1 ms

--- 192.99.46.254 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1002ms
rtt min/avg/max/mdev = 47.134/47.134/47.134/0.000 ms
root@minecraft:~# ping -c 2 192.99.46.254
PING 192.99.46.254 (192.99.46.254) 56(84) bytes of data.
From 198.50.241.115 icmp_seq=1 Destination Host Unreachable
From 198.50.241.115 icmp_seq=2 Destination Host Unreachable

--- 192.99.46.254 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1011ms
pipe 2

It responds to redirect the host and then after than the host in unreachable. It should work as far as I know. The configuration has not changed. The guest VM has a very simple configuration...

root@minecraft:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:8e:9b:2b  
          inet addr:198.50.241.115  Bcast:198.50.241.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe8e:9b2b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:750 errors:0 dropped:0 overruns:0 frame:0
          TX packets:336 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:79663 (77.7 KiB)  TX bytes:30405 (29.6 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:48 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4405 (4.3 KiB)  TX bytes:4405 (4.3 KiB)

root@minecraft:~# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         198.50.241.112  0.0.0.0         UG    0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 eth0

Note: flushing the IP tables and setting the input policy to accept does not change anything. This is not a NAT configuration, the guests have proper internet addresses.

share|improve this question
    
What does iptables -t nat -vnL on greece return? –  Creek Apr 26 at 2:35
    
All chains return empty, the system isn't configured to do NAT. The guest VMs have real internet addresses. –  John Tate Apr 26 at 2:38
    
Here's a solid explanation of ICMP Redirects. What kind of device is 192.99.46.254? I'm thinking it's routing table might need some cleaning up. –  Creek Apr 26 at 2:44
    
That belongs to my hosting company. I'll ask them what is going on. –  John Tate Apr 26 at 2:52

1 Answer 1

Fixing the problem was a simple as disabling ICMP redirects from my host. I am not sure why it started sending them after running for a long time without issue. However the problem could be averted with some simple changes with sysctl.

root@greece:~# sysctl -w net/ipv4/conf/eth0/accept_redirects=0
net.ipv4.conf.eth0.accept_redirects = 0
root@greece:~# sysctl -w net/ipv4/conf/eth0/send_redirects=0
net.ipv4.conf.eth0.send_redirects = 0

These changes can then be reflected in /etc/sysctl.conf and it prevents this from happening.

share|improve this answer

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.