[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables, virtualbox and port forwarding



Le 29.05.2014 06:56, Igor Cicimov a écrit :
Maybe something like this?

- Kernel config

# sysctl -p
net.ipv4.conf.default.rp_filter = 1
net.ipv4.ip_forward = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.log_martians = 1
 net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.send_redirects = 0
 net.ipv4.conf.all.accept_source_route = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

- Network interfaces config

# This is the host interface
 auto eth0
allow hot-plug eth0
iface eth0 inet static
  address 172.20.14.121
  netmask 255.255.255.0
  network 172.20.14.0
  broadcast 192.168.0.255
  gateway 172.20.14.1
  dns-nameservers 172.20.14.1 8.8.8.8
   search virtual.local

auto virbr1
iface virbr1 inet static
  address 192.168.100.1
  netmask 255.255.255.0
  bridge_ports eth0
  bridge_fd 0
  bridge_stp off
  bridge_maxwait 0

- Firewall simple config

# Set Default Policy to DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Allow loopback and localhost access
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
 iptables -A INPUT -s 127.0.0.1/32 [6] -j ACCEPT

# Defense for SYN flood attacks
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT

# Set Default Connection States - accept all already established
connections
 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Open DHCP and DNS for virbr1
iptables -A INPUT -p udp -m multiport --dports 67:68 -i virbr1 -m
state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 67:68 -i virbr1 -m
state --state NEW -j ACCEPT
 iptables -A INPUT -p udp --dport 53 -i virbr1 -m state --state NEW
-j ACCEPT
iptables -A INPUT -p tcp --dport 53 -i virbr1 -m state --state NEW -j
ACCEPT

# Masquerade
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.100.0/24 [7] ! -d
192.168.100.0/24 [8] -j MASQUERADE

# Forward chain
iptables -A FORWARD -i eth0 -o virbr1 -d 192.168.100.0/24 [9] -m
state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i virbr1 -o eth0 -s 192.168.100.0/24 [10] -j
ACCEPT
 iptables -A FORWARD -i virbr1 -o virbr1 -j ACCEPT

Now you can create VM's with their own virtual devices, ie vmdev0,
vmdev1 etc, and simply add those devices to the virbr1. Then
each of the VM's would have static config of their eth0 interface
with ip of 192.168.100.0/24 [11] range and 192.168.100.1 as default
 gateway.

If you want to have the VM's get their ip via DHCP then you can
install dnsmasq and attach a process to virbr1. Something like
this:

/usr/sbin/dnsmasq -u dnsmasq --strict-order --bind-interfaces
 --pid-file=/var/run/dnsmasq/virbr1.pid --conf-file=
--except-interface lo --listen-address 192.168.100.1
--dhcp-range 192.168.100.10,192.168.100.20
--dhcp-leasefile=/var/run/dnsmasq/virbr1.leases
--dhcp-lease-max=11 --dhcp-no-override


I will try this stuff to discover what it does and how it does it, but the previous reply from Pascal Hamburg work like a charm.
Thanks a lot anyway for your time.

The purpose of the VLAN you have created is not clear as they are
usually used to extend a virtual network to more than one host. You
will need 802.1Q kernel module enabled and 802.1Q VLAN enabled
switch(s) in your network for this to work. Anyway, you can try adding the VLAN in the above configuration as an exercise, ie attach the vlan
to eth0 and then include the vlan in the virbr1.

About the use of this network, the goal is to simulate the network infrastructure of a client for which we work, but without polluting the LAN we work on. I'll use it to deploy client's network twice ( on different VLANs, obviously, to avoid conflicts ) : one for development purposes, which won't be stable and probably will have to be automatically rebuild regularly, and an other one for release candidates of our work. Since we do not do development tasks only for one client, it will probably contain other other VLANs for other clients at a point. Why I do this is because, currently... erm... I'm ashamed to say that, especially on a public list, but truth is that we send development versions a server, same for release candidate, and same for final version. The problem being that the server is always the same. Ugly imo, so I try to improve the situation, but I'm not a sysadmin, and I do not have the control of our local LAN structure, but I can control the VLAN's structures since they run on a server that my colleagues on admin "gave" me.


Reply to: