OpenVPN Server And Firewalld

Home » CentOS » OpenVPN Server And Firewalld
CentOS 9 Comments

How do I insert the iptables rule below using firewalld?

I’m moving up from CentOS 6 to 7 on an office gateway and I’m trying to get OpenVPN working to allow home workers to access PCs at the office. I’ve got it all working but only by manually inserting an ACCEPT rule in the FORWARD
iptables chain:

iptables -I FORWARD 3 -i tun+ -j ACCEPT

This rule was extracted from my iptables firewall under CentOS6. The 3 puts it after the accepts for established connections and loopback connections, but before any firewalld sub-chains. With this I can connect to an internal Windows 10 system with Remote Desktop.

How can I inject this rule using firewalld, either as a direct rule or as some more firewalld-approved kind of rule?

9 thoughts on - OpenVPN Server And Firewalld

  • W dniu 29.12.2017 o 10:32, Kenneth Porter pisze:

    Hi, firstly check which zone are your interface in :

    bash> firewall-cmd –get-active-zones

    then all you have to do is add a service to the firewall

    firewall-cmd –zone= –add-service=openvpn –permanent

    assuming that your Openvpn is running on standard port 1194/tcp|udp, If not then modify firewall-cmd rule and add your port/proto

    e.g. firewall-cmd –zone= –add-port=11193/tcp

    I hope this will help you,

    —
    Pozdrawiam / Best regards Wojciech Łysiak

  • That opens the physical Ethernet interface to allow the raw SSL
    connection from the client into the server. It doesn’t open a connection for the tunnel (tun0 interface) that’s been created by the OpenVPN
    service to forward packets to the internal LAN zone.

    I tried adding the tun0 interface to the internal zone and firewall-cmd told me tun0 was managed by NetworkManager. After that it didn’t show tun0 as a member of any zone.

    #  firewall-cmd –zone=internal –add-interface=tun0
    The interface is under control of NetworkManager, setting zone to
    ‘internal’. success
    # firewall-cmd –list-all-zones
    (long list of zones, none of which have tun0 in their interfaces field)

  • Hello, in case your need is not covered by the “–add-service” and/or the
    “–add-port” you can still use a direct rule for it.

    I think it should be something like this to test:
    firewall-cmd –direct –add-rule ipv4 filter FORWARD 0 -i tun+ -j ACCEPT

    Manual page and some examples with man firewalld.direct

    The “iptables like” rule will be added into the pre-built chain named FORWARD_direct The 0 above means it is put at top of FORWARD_direct chain. In your example appears “3” and it is not clear what are lines 1 and 2. With iptables -L command you will see:

    # iptables -v -L FORWARD_direct Chain FORWARD_direct (1 references)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT all — tun+ any anywhere anywhere
    #

    With firewall-cmd you can see with
    # firewall-cmd –direct –get-all-rules ipv4 filter FORWARD 0 -i tun+ -j ACCEPT
    #

    If it works ok as expected, you can make it permanent with

    firewall-cmd –permanent –direct –add-rule ipv4 filter FORWARD 0 -i tun+
    -j ACCEPT
    firewall-cmd –reload

    HIH digging into, Gianluca

  • This is not and answer to your questions, still I will mention it anyway. I use pfsense for the same, and it installs seamlessly, is configured easily (through web interface), and works reliably. Also: it is really very lightweight on hardware demands and is quite small footprint. It is based on FreeBSD. If I were replacing/upgrading any firewall/gateway/… VPN… I will definite consider pfsense (add to my scope of candfidates):

    https://www.pfsense.org/

    I hope, this helps.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • –Thanks. That looks right.

    The “3” was for putting it in the main FORWARD chain before the call the FORWARD_direct. (A quick and dirty hack just to test if that was the rule I
    needed to make the VPN work.) “0” would be the correct argument for putting it as the first rule in the FORWARD_direct subchain.

  • –Alas, this doesn’t seem to allow forwarding from the tun0 device. That’s the setup I had that failed. I needed the direct rule to allow forwarding from tun0 to get packets delivered to PCs on my LAN. Without that, the remote PC can only access the VPN server itself and not the internal PCs behind it.

    It’s also necessary for the LAN PCs to know that the addresses in the VPN
    must be routed through this gateway, but that’s a given since this is also the Internet gateway for the LAN. Their default route takes care of that. If you run a separate VPN concentrator, you may need to advertise a route on the LAN (via DHCP) or add a route on your Internet gateway to the separate concentrator for your VPN netblock so the return packets find their way back to the tun device.

    My OpenVPN server config includes a line to push a route to the remote clients for the office’s LAN net block:

    push “route 192.168.20.0 255.255.255.0”

  • I am experiencing the same thing getting IPSec protected GRE packets to the gre1 interface.

    It works with the firewall disabled; haven’t been able to figure out how to make it work with the firewall enabled.

    firewall-cmd allows me to add the interface, but then forgets about it.

  • While I cannot reference the interface in a firewall rule I have been able to get the tunnel operational using: