Changed iptables behavior

This forum is dedicated to advanced help and support :

Ask here your questions about advanced usage of Mageia. For example you may post here all your questions about network and automated installs, complex server configurations, kernel tuning, creating your own Mageia mirrors, and all tasks likely to be touchy even for skilled users.

Changed iptables behavior

Postby jiml8 » Oct 1st, '17, 22:57

I finally had a bit of time available, and I upgraded to Mageia 6. As usual with my system, it wasn't totally smooth, but I got there and most of it is working. I still have some important stuff broken (sshd, smbd notably), but the one that is really going to bite me is an apparent change in iptables behavior.

Also in the last week, I have upgraded from VMWare Workstation 11 to VMWare Workstation 14. So, there have been some big changes in my environment recently.

Now, in my vmware environment, I have a virtual network called vmnet1. This network is a host-only network, which means it has no access to any interfaces that leave the host; any VMs that are assigned on this network are only networked within the host. I use this network to control my Windows virtual machines. I can run them while denying them access to the internet, or I can allow them to have access to the internet by adding two rules into iptables.

Those two rules are these:
Code: Select all
sudo iptables -t nat -A POSTROUTING -s 172.16.187.0/24 -j SNAT --to-source 192.168.0.2
sudo iptables -I FORWARD -s 192.168.0.0/24 -d 172.16.187.0/24 -j ACCEPT


I have used this mechanism since the day I created a Windows 7 vm and saw how much it wanted to talk to Microsoft. This mechanism has worked flawlessly in all that time.

Until now.

These rules no longer connect my windows subnet to the internet.

I have used tcpdump -i vmnet1 and confirmed that traffic is arriving on the interface, so this is nothing that the new version of VMWare Workstation is doing.

I thought that the new version of shorewall might be responsible, so I tried several things. I disabled it and applied only my two rules; no change. However, the windows VMs could no longer ping vmnet1; it seems that some rule is required to make that possible.

I studied the docs and implemented the SNAT rule in the /etc/shorewall/snat file - and shorewall put it into iptables the same way I do - but it didn't work; traffic appears at vmnet1 and no matching traffic appears outgoing at eth0 (which is my WAN interface)

I have run
Code: Select all
iptables -L -v -n
on all my variants of the ruleset, and it shows that my rules are not encountering any packets; something else is killing them.

This looks a lot like some change in iptables. I searched the release notes for Mageia 6 and the errata, and found nothing. A search of the wiki turns up nothing useful.

I am wondering about the fact that with no rules in iptables pinging vmnet1 from a guest on that net does not work; I think I need to figure out what rule has to be bound to that interface to allow pinging. Probably a clue.

Does anybody here have any knowledge about this?
jiml8
 
Posts: 1254
Joined: Jul 7th, '13, 18:09

Re: Changed iptables behavior

Postby wintpe » Oct 4th, '17, 14:45

no specific knowlage about your issue.

how to diagnose.

well its going to be a remove everything and start from scratch i would say.

you have to see where it breaks and for that you need to build up the ruleset from nothing.

regards peter
Redhat 6 Certified Engineer (RHCE)
Sometimes my posts will sound short, or snappy, however its realy not my intention to offend, so accept my apologies in advance.
wintpe
 
Posts: 1204
Joined: May 22nd, '11, 17:08
Location: Rayleigh,, Essex , UK

Re: Changed iptables behavior

Postby jiml8 » Nov 6th, '17, 02:43

I have confirmed changed behavior in iptables.

I have three physical NICs in this box, and usually there are 5 virtual LANs running. One of these virtual LANs is bridged to my WAN interface (eth0) and therefore becomes a part of my external subnet, but the other 4 are either NAT or host only - so I get to control how they behave and connect. I often use my workstation as a router, connecting these subnets in various ways to support the particular work I am doing. Commonly, I use forwarding and SNAT to pass these packets. This lets me hook into the packet stream pretty much anyplace I want to do whatever it is I need to do.

So this changed behavior has proven highly troublesome to me

So, I disabled shorewall and created my own firewall, using iptables. This placed all the variables under my control. I then played with it a bit, and I have learned the following:

1. As noted in my first post, when I disabled all rules, my virtual machines were unable to even ping their own gateway (172.16.187.1, the vmnet1 virtual interface address). I must now define a rule allowing this ping before they can do this.

2. The rules for forwarding packets back and forth via SNAT have changed. Previously, I handled my host-only Windows vmware subnet with these rules:
Code: Select all
sudo iptables -t nat -A POSTROUTING -s 172.16.187.0/24 -j SNAT --to-source 192.168.0.2
sudo iptables -I FORWARD -s 192.168.0.0/24 -d 172.16.187.0/24 -j ACCEPT


Now, the rules look like this:
Code: Select all
sudo iptables -t nat -A POSTROUTING -o eth0 -s 172.16.187.0/24 -j SNAT --to-source 192.168.0.2
sudo iptables -I FORWARD -d 172.16.187.0/24 -j ACCEPT
sudo iptables -I FORWARD -s 172.16.187.0/24 -j ACCEPT


These rules are not part of my default firewall, but are contained in a separate script (one of many) that I run to establish "pre-canned" configurations. I have been busy this afternoon altering these scripts to accommodate the changes.

These changes actually make iptables look a bit more like a freebsd firewall, and improves the granularity. So I will call it an improvement. But it was a PITA to figure out and deal with.

For anyone who is interested, here is my complete default firewall. I think I will stick with it; this is much simpler than shorewall (which means the likelihood of an error is reduced) and it does everything I need it to do.

I welcome any criticisms, if you spot a hole in it. I started with a template I found at https://danielmiessler.com/blog/professional-firewall-iptables/

Code: Select all
#!/usr/bin/env bash

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

#############################
#  SETUP
#############################

# Define our hostname
DADSBOX=192.168.2.33

# Define all allowed networks
ETH0=192.168.2.0/24
VMNET1=172.16.187.0/24
VMNET2=172.16.188.0/24
VMNET8=192.168.218.0/24
ETH1=192.168.11.0/24
ETH2=192.168.12.0/24

# Define all allowed source nets
SOURCENET=$ETH1,$ETH2,$VMNET1,$VMNET2,$VMNET8

# Define all allowed destination nets
DESTNETS=$ETH1,$ETH2,$VMNET1,$VMNET2,$VMNET8

# Clear all rules
/sbin/iptables -F
/sbin/iptables -t nat -F

# Don't forward traffic  Uncomment if you don't want any IP forwarding.
#/sbin/iptables -P FORWARD DROP

# Allow outgoing traffic
/sbin/iptables -P OUTPUT ACCEPT

# Allow established traffic
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow localhost traffic
/sbin/iptables -A INPUT -i lo -j ACCEPT

# Allow all incoming local interface traffic
/sbin/iptables -A INPUT -s $SOURCENET -j ACCEPT

#############################
#  MANAGEMENT RULES
#############################

# Allow SSH
/sbin/iptables -A INPUT -p tcp -d $DADSBOX --dport 22 -j LOG --log-level 7 --log-prefix "Accept 22 ssh"
/sbin/iptables -A INPUT -p tcp -d $DADSBOX --dport 22 -j ACCEPT

#############################
#  ACCESS RULES
#############################

# Allow web server
/sbin/iptables -A INPUT -p tcp -d $DADSBOX --dport 80 -j LOG --log-level 7 --log-prefix "Accept 80 HTTP"
/sbin/iptables -A INPUT -p tcp -d $DADSBOX --dport 80 -j ACCEPT

#allow SMB
/sbin/iptables -A INPUT -p tcp -d $DESTNETS --dport 137 -j LOG --log-level 7 --log-prefix "Accept SMB on 137"
/sbin/iptables -A INPUT -p tcp -s $SOURCENET -d $DADSBOX --dport 137 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d $DESTNETS --dport 139 -j LOG --log-level 7 --log-prefix "Accept SMB on 139"
/sbin/iptables -A INPUT -p tcp -s $SOURCENET -d $DADSBOX --dport 139 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d $DADSBOX --dport 445 -j LOG --log-level 7 --log-prefix "Accept SMB on 445"
/sbin/iptables -A INPUT -p tcp -s $SOURCENET -d $DADSBOX --dport 445 -j ACCEPT

# Allow two types of ICMP
/sbin/iptables -A INPUT -p icmp -d $DESTNETS --icmp-type 8/0 -j LOG --log-level 7 --log-prefix "Accept Ping"
/sbin/iptables -A INPUT -p icmp -d $DESTNETS --icmp-type 8/0 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -d $DESTNETS --icmp-type 8/0 -j LOG --log-level 7 --log-prefix "Accept Time Exceeded"
/sbin/iptables -A INPUT -p icmp -d $DESTNETS --icmp-type 11/0 -j ACCEPT

# Allow other ports
# TOR
/sbin/iptables -A INPUT -d $DADSBOX -p tcp --dport 9001:9030 -j LOG --log-level 7 --log-prefix "Accept TOR connections"
/sbin/iptables -A INPUT -d $DADSBOX -p tcp --dport 9001:9030 -j ACCEPT

/sbin/iptables -A INPUT -d $DADSBOX -p udp --dport 30666 -j LOG --log-level 7 --log-prefix "Accept connection from sharon"
/sbin/iptables -A INPUT -d $DADSBOX -p udp --dport 30666 -j ACCEPT
#############################
#  DEFAULT DENY
#############################

/sbin/iptables -A INPUT -d $DADSBOX -j LOG --log-level 7 --log-prefix "Default Deny"
/sbin/iptables -A INPUT -j DROP

/bin/blockhosts.py
jiml8
 
Posts: 1254
Joined: Jul 7th, '13, 18:09


Return to Advanced support

Who is online

Users browsing this forum: No registered users and 1 guest