I setup an openVPN server and it works ok.

The next step is to secure it, I opted to use IPTABLES to only allow certain connections through but so far it is not working.

I want to enable access to the network behind my openVPN server, and allow other services (web access), when iptables is disabaled or set to allow all this works fine, when using my following rules it does not.

also note, I already configured openVPN itself to do what i want and it works fine, its only failing when iptables is started.

Any help to tell me why this isnt working will appreciated here.

These are the lines that I added in accordance with openVPN's recommendations, unfortunately testing these commands shows that they are requiered, they seem incredibly insecure though, any way to get around using them?

# 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

# Allow TAP interface connections to OpenVPN server
-A INPUT -i tap+ -j ACCEPT

# Allow TAP interface connections to be forwarded through other interfaces
-A FORWARD -i tap+ -j ACCEPT

These are the new chains and commands i added to restrict access as much as possible unfortunately with these enabled, all that happens is the openVPN connection establishes fine, and then there is no access to the rest of the network behind the openVPN server

  • note I am configuring the main iptables file and I am paranoid so all ports and ip addresses are altered, and -N etc appears before this so ignore that they dont appear.

  • and i added some explanations of what i 'intended' these rules to do, so you dont waste time figuring out where i went wrong :>

    #accepts the vpn over port 1192
    -A INPUT -p udp -m udp --dport 1192 -j ACCEPT
    #packets that are to be forwarded from network (all open vpn clients) to the internal network ( jump to [sic]foward-firewall chain
    #same as above, except for a different internal network
    # reject any not from either of those two ranges
    -A INPUT-FIREWALL -p tcp -m tcp --dport 22 -j ACCEPT
    #80 443 and 53 are accepted 
     -A FOWARD-FIREWALL -m tcp -p tcp --dport 80 -j ACCEPT
    -A FOWARD-FIREWALL -m tcp -p tcp --dport 443 -j ACCEPT
    # = openVPN sever
    -A FOWARD-FIREWALL -m tcp -p tcp -d --dport 53 -j ACCEPT
    -A FOWARD-FIREWALL -m udp -p udp -d --dport 53 -j ACCEPT

now I wait :D

  • Are you really using both a tap and tun configuration? You almost certainly can remove the rules for type you are not using. – Zoredache Feb 18 '10 at 2:50

Use Shorewall instead of iptables directly. Shorewall is a lightweight config tool that makes it much easier to manage your iptables rules. You can get OpenVPN up and running with your firewall in about 10 minutes by following the OpenVPN HOWTO.

  • +1 shorewall is a great tool. Not only make easier to manage firewall, but it makes very well structured rules. – PiL Jul 13 '10 at 9:22

Have you tried adding -j LOG statements in front of the REJECTs so one can at least see with which reject they end up and what exactly gets rejected?

Can you provide a traceroute, e.g. traceroute from

  • the log file I am reading is from /var/log/messages It gave me nothing but broadcasts, rather strange I am not sure if I used the right command (my two chains): -A INPUT-FIREWALL -j REJECT -A FOWARD-FIREWALL -j REJECT -- also tried the tracert with iptables enabled: Tracing route to FILESERVER [] over a maximum of 30 hops: 1 113 ms 126 ms 109 ms 2 116 ms 119 ms 149 ms FILESERVER [] and with iptables enabled: 1 458 ms 529 ms 519 ms 2 * * * request timed out and so on.. – bob franklin smith harriet Feb 18 '10 at 6:31
  • and it seems you cant put things on new lines here sorry – bob franklin smith harriet Feb 18 '10 at 6:32
  • as I said use iptables logging and take a look what packets are rejected exactly and where – Marki Feb 18 '10 at 19:49
  • (also you might try checking out dmesg instead of /var/log/messages unless you use ulogd or alike) – Marki Feb 18 '10 at 19:51

Your Answer

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