0

I have a set of iptables rules (see below) whose purpose is to disallow traffic to go out of my machine when my VPN connection is abruptly lost or manually terminated:

#!/bin/bash

echo "Please wait a moment......"
echo "Save original iptables. Apply new iptables rules"

iptables-save > /home/username/vpn/iptables.save

iptables -A INPUT -m conntrack -j DROP --ctstate INVALID
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp -m conntrack -s 123.123.123.123 -i eth0 --sport 443 -j ACCEPT  --ctstate ESTABLISHED #ca1.conf
iptables -A OUTPUT -p tcp -m tcp -m conntrack -d 123.123.123.123 -o eth0 --dport 443 -j ACCEPT --ctstate NEW,ESTABLISHED #ca1.conf
iptables -A INPUT -i eth0 -j DROP
iptables -A OUTPUT -o eth0 -j REJECT
iptables -A OUTPUT -p tcp -m tcp -m conntrack -o tun0 --dport 80 -j ACCEPT  --ctstate NEW,ESTABLISHED
iptables -A OUTPUT -p tcp -m tcp -m conntrack -o tun0 --dport 443 -j ACCEPT  --ctstate NEW,ESTABLISHED
iptables -A OUTPUT -p tcp -m tcp -m conntrack -o tun0 --dport 53 -j ACCEPT  --ctstate NEW,ESTABLISHED
iptables -A OUTPUT -p tcp -m tcp -m conntrack -o tun0 --dport 53 -j ACCEPT  --ctstate NEW,ESTABLISHED
iptables -A INPUT -p tcp -m tcp -m conntrack -i tun0 --sport 80 -j ACCEPT  --ctstate ESTABLISHED
iptables -A INPUT -p tcp -m tcp -m conntrack -i tun0 --sport 443 -j ACCEPT  --ctstate ESTABLISHED
iptables -A INPUT -p tcp -m tcp -m conntrack -i tun0 --sport 53 -j ACCEPT  --ctstate ESTABLISHED
iptables -A INPUT -p tcp -m tcp -m conntrack -i tun0 --sport 53 -j ACCEPT  --ctstate ESTABLISHED
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -j DROP

The above iptables rules work on a machine running an Intel Haswell CPU (i7-4xxx series, quad-core, 8 threads) and a Haswell chipset (H87 series).

However they do not work on a machine running an Intel Ivy-Bridge CPU (i7-3xxx series, quad-core, 8 threads) and an Ivy-Bridge chipset (H77 series).

Could someone tell me why?

The OS that is being used is Debian Wheezy and the same HDD is used for the above experiment.

  • 2
    How do they 'not work'? Do you get an error message? If so, post it. Also, it is highly unlikely that the cpu or its chipset has anything to do with your firewall problem; more likely there's some other difference somewhere. – Wouter Verhelst Aug 27 '15 at 21:51
  • @WouterVerhelst: Also, it is highly unlikely that the cpu or its chipset has anything to do with your firewall problem; Thanks for the clarification. – festivalofmusic Aug 28 '15 at 4:15
1

It's highly unlikely to be related to the CPU chipset. It's more likely to be related to the NIC.

If you're sharing the same hard disk and OS installation between two different machines, the NIC will be different so the MAC for that NIC will be different. Therefore it will almost certainly be bound on configuration to eth0 but to eth1 on the other.

You can fix this on Wheezy by editing /etc/udev/rules.d/70-persistent-net.rules and ensuring that both generated rules name the interface as eth0. (Just make sure you don't ever try to have a single machine with both NICs.)

Here is the appropriate entry from my system. Your systems' MACs will be different. This line instructs udevd to give the NIC with MAC 00:0a:cd:20:aa:3f the name eth0:

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:cd:20:aa:3f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
  • Firstly thank you for your help. If you're sharing the same hard disk and OS installation between two different machines That was what I did. It was an experiment. – festivalofmusic Aug 28 '15 at 4:17
  • Therefore it will almost certainly be bound on configuration to eth0 but to eth1 on the other. Are you saying that iptables rules firewall are bound to the MAC of an NIC? I didn't know that. – festivalofmusic Aug 28 '15 at 4:18
  • You can fix this on Wheezy by editing /etc/udev/rules.d/70-persistent-net.rules and ensuring that both generated rules name the interface as eth0. After changing the interface name of both generated rules to eth0, do I have to sudo update-grub or something? – festivalofmusic Aug 28 '15 at 4:20
  • (Just make sure you don't ever try to have a single machine with both NICs.) Why? What are the reasons? – festivalofmusic Aug 28 '15 at 4:21
  • @festivalofmusic because my suggestion requires naming both of them explicitly as eth0. And that can't work. – roaima Aug 28 '15 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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