2

I'm currently in the process of setting up OpenVPN across multiple data centres on Linode. The OpenVPN set up is working great and I'm now focusing on getting my firewall set up so that my public and private IP's provided by Linode are protected.

However, I seem to be running into an issue with this. On my VPN server, when I set up my firewall and reboot the VPN server, the firewall is loaded at start up automatically, however, none of my VPN clients seems to be able to ping the VPN server (located at 10.8.0.1). When I bring down my firewall on the VPN server (iptables -F), the clients are capable of pinging the VPN server. When I then reinstate my firewall on the server (iptables-restore < /etc/iptables.up.rules) the clients are still capable of pinging the VPN server.

I would assume that the firewall would either block or not and I can't seem to figure out why this behaviour occurs.

These are my iptables on the VPN server:

*filter

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allows all outbound traffic
# You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

# prevent attacks on port 22.
-I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
-I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 -j DROP


# OpenVPN
-A INPUT -i eth0:0 -m state --state NEW -p udp --dport 1194 -j ACCEPT
-A INPUT -i eth0:1 -m state --state NEW -p udp --dport 1194 -j ACCEPT

# Allow TUN interface connections to OpenVPN server
-A INPUT -i tun+ -j ACCEPT

# Allow TUN interface connections to be forwarded through other interfaces
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

COMMIT

# NAT the VPN client traffic to the internet
*nat

-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

COMMIT
3
  • Its probably because iptables -F doesn't actually flush everything. Check cyberciti.biz/tips/linux-iptables-how-to-flush-all-rules.html
    – GeoSword
    Jan 8, 2015 at 8:35
  • Not sure I understand your comment. If the iptables -F doesn't do anything, then why am I able to ping the VPN server after issuing it?
    – Luke
    Jan 8, 2015 at 9:44
  • I didnt say it did nothing :) You are assuming that iptables -F flushes all rules, thus leaving you with a "clean slate". It does not.
    – GeoSword
    Jan 8, 2015 at 13:58

1 Answer 1

2

The firewall won't block already established VPN connections because you have the following rule near the top:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

That means, connections already in the ESTABLISHED state (from the point of view of the conntrack module of netfilter) will keep passing through.

Plus, most likely your INPUT chain has a 'policy' of ACCEPT; that's why doing iptables -F opened up your firewall, allowing OpenVPN to make the connection.

Note that even when the netfilter rules are flushed, connections are still being tracked.

In summary, what happened was:

  1. Firewall blocked OpenVPN connection attempt
  2. Rules were flushed
  3. OpenVPN can connect ==> state transitions to ESTABLISHED
  4. Rules were reinstated
  5. OpenVPN traffic can resume because state is already ESTABLISHED

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .