0

This question already has an answer here:

I have a kvm VM with Ubuntu 14.04 set as a firewall in a virtual network (with eth0 and eth1)

This is not a course but at work. I have to learn this.

Intermittently eth1 will fail to come up.

In /etc/network/interfaces both eth0 and eth1 are set manually.

When eth0 should be up there is a up command /etc/interim-fw.sh that allows nothing and no forwarding between the ports.

Then eth1. There is a pre-up where i send a comment to a log file that it has reached this point. Then link up also and then up command to /etc/firewall.sh that will load the iptables with all rules that are needed.

Randomly this will not load and only reach pre-up of eth1. But once the VM has loaded if I run bash /etc/firewall.sh it will load completely and all will be fine!

So my question is: How can I solve this? Why am I getting a race condition, if that is what I am getting?

/etc/network/interfaces:

auto lo  
iface lo inet loopback  

auto eth0  
iface eth0 inet manual  
  up ip a a 5.156.241.126/25 dev eth0  
  up ip li set up dev eth0  
  up /etc/interim-fw.sh  
  down ifconfig eth0 0.0.0.0 down  


 auto eth1  
 iface eth1 inet manual  
    up ip a a 5.156.241.129/27 dev eth1  
    up ip li set up dev eth1  
    up ip route add default via 5.156.241.158  
    post-up /etc/firewall.sh  
    down ifconfig $IFACE 0.0.0.0 down  

/etc/firewall.sh

!/bin/bash -e

I_INT=eth0  # Intranet-LAN-Interface  
I_DMZ=eth1  # DMZ-LAN-Interface  
NAME=5.156.241.130                       
MASTER=5.156.241.1    
UBUNTU=141.30.13.10,141.30.13.20,141.76.1.200,141.76.1.204,141.76.1.208  
REACTOS=178.63.204.104,188.40.64.41  
MOZILLA=52.222.170.144  
PYTHON=151.101.0.223,151.101.64.223,151.101.128.223,151.101.192.223  
MAIL=5.156.241.142  
WWW=5.156.88.1  
STATE_NEW="-m state --state NEW"  
STATE_ESTABLISHED="-m state --state ESTABLISHED"  
PING="-p icmp --icmp-type 8"                        #ICMP packet type 8 alias echo request (= ping request )
REM="-m comment --comment"
{
iptables-restore << @@@@@@@@

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT   $STATE_ESTABLISHED -j ACCEPT
-A OUTPUT  $STATE_ESTABLISHED -j ACCEPT
-A FORWARD $STATE_ESTABLISHED -j ACCEPT


-A INPUT  -p icmp -m icmp --icmp-type any  $STATE_NEW  $REM "traceroute" -j ACCEPT
-A INPUT  -p udp      --dport 33434:33523  $STATE_NEW  $REM "traceroute" -j ACCEPT

-A INPUT   -i $I_INT -p tcp           --dport 22345 $STATE_NEW  $REM "ssh" -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -p tcp --dport 22345 $STATE_NEW  $REM "ssh" -j ACCEPT

-A OUTPUT -o $I_DMZ -d $SATURN -p tcp --dport 53  $STATE_NEW $REM "dns"  -j ACCEPT
-A OUTPUT -o $I_DMZ -d $SATURN -p udp --dport 53  $STATE_NEW $REM "dns"  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $SATURN -p tcp --dport 53  $REM "dns" $STATE_NEW  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $SATURN -p udp --dport 53  $REM "dns" $STATE_NEW  -j ACCEPT

-A FORWARD -i $I_INT -o $I_DMZ -d $MASTER -p tcp --dport 53  $REM "dns" $STATE_NEW  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $MASTER -p udp --dport 53  $REM "dns" $STATE_NEW  -j ACCEPT

-A OUTPUT -o $I_DMZ $PING $STATE_NEW $REM "Ping"  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ $PING $STATE_NEW $REM "Ping" -j ACCEPT

-A FORWARD -i $I_INT -o $I_DMZ -d $UBUNTU -p tcp --dport 80 $STATE_NEW $REM "Ubuntu"  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $REACTOS -p tcp -m multiport --dports 80,443 $STATE_NEW $REM "Reactos"  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $MOZILLA -p tcp -m multiport --dports 80,443 $STATE_NEW $REM "Mozilla"  -j ACCEPT
-A FORWARD -i $I_INT -o $I_DMZ -d $PYTHON -p tcp -m multiport --dports 80,443 $STATE_NEW $REM "Python"  -j ACCEPT
-A OUTPUT            -o $I_DMZ -d $UBUNTU -p tcp --dport 80 $STATE_NEW $REM "Ubuntu"  -j ACCEPT

-A FORWARD -i $I_INT -o $I_DMZ -d $WWW -p tcp --dport 80 $STATE_NEW $REM "www"  -j ACCEPT
-A OUTPUT            -o $I_DMZ -d $WWW -p tcp --dport 80 $STATE_NEW $REM "www"  -j ACCEPT

COMMIT

@@@@@@@@
} && {
  test $(sysctl -n net.ipv4.ip_forward) -eq 0 && sysctl net.ipv4.ip_forward=1  #Forwarding aktivieren
        echo "ok"
  echo "GOT HERE - ok!" >> /tmp/fw.log
  exit 0
} || {
  test $(sysctl -n net.ipv4.ip_forward) -ne 0 && sysctl net.ipv4.ip_forward=0  #Forwarding de-aktivieren
  /etc/firewall-vorlaeufig.sh

echo "GOT HERE - not ok " >> /tmp/fw.log

This does not duplicate How to save rules of the iptables? Reason is that my Senior Admin insists that I use this /etc/firewall.sh script. Also the script runs fine but randomly fails.

Thank you for your comments so far. I would really appreciate any help if trying to find out the cause of this. Thanks. Bob

marked as duplicate by Panther, Eric Carvalho, Kevin Bowen, David Foerster, Elder Geek Jul 17 '17 at 12:37

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • good lord who knows, you are running a VM and so netwroking is that much more complicated, and it sounds as if you are running custom scripts so who knows? Perhaps run the scripts all at once after both devices are up. My guess is you are making this more complicated then it has to be, there are way too many "iptables scripts" that are way too complex. – Panther Jul 14 '17 at 19:53
  • Just use sudo apt-get install iptables-persistent – Panther Jul 14 '17 at 19:53
  • 1
    it's not a good idea to post a work-in-progress question on a Stack Exchange site, especially one with high traffic. If your question lacks details, it's likely to be closed. If we left it open to wait for you to finish it, that wouldn't help you, because questions asked on Friday will be several pages back by Monday, and while editing does bump the post, it's only on the front page, which moves very fast. Editing your question after it's closed will send it to the reopen queue, and that will get some more eyes on it, but the edit has to be good enough to convince folks to reopen. – Zanna Jul 15 '17 at 9:12
  • 3
    If your senior admins insist on a particular solution you should ask them for help with its implementation. – David Foerster Jul 17 '17 at 9:51
  • This is another example of recreating the wheel when better solutions exits. If you were using iptables-persistent you would be able to file a bug report. As it is now, you have obscured your iptables rules by creating so many $VARIABLES it is hard to read the script. I really do not understand why people insist on making obscure iptables scripts, makes it difficult for people like me to debug =) . – Panther Jul 17 '17 at 15:46
0

Your situation is complicated as you are running a VM and you seem to be using some sort of script and you are trying to call the script in your network pre/post up/down rules.

IMO most of the "scripts" to generate rules for iptables are overly complex and completely unnecessary. Most scripts may seem "smart" but often the only purpose is obscurification of iptables.

Easiest way to save/restore your rules is with iptables-persistent

sudo apt-get install iptables-persistent

Once you install the package it will restore your rules no matter if you manually entered them or generated them from some sort of script.

If you really want help with your script you need to post it as well as your configuration files.

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