IPFire as OpenVPN Server in existing network

Hi there,

is it possible to use IPFire as OpenVPN Server in a existing network which has a Router that handles the Internet connection? I am asking how to setup this?

There is a Internet Router with Public IP and NAT, Behind it there is a Network 192.168.100.x/24 with workstations and servers. On one of the Servers there is a Hyper-V Setup with IPFire. I am wondering how to set up the networking with only one Subnet? I have setup the green interface with 192.168.100.121 and can access the Webgui. I have setup the red Interface with 192.168.100.122 and can also access the webgui. I think I have to disable the green interface to get this setup working but if I do that I can not access the Webgui anymore, also not through the red interface. Does such setup work in General? All I need is a OpenVPN Server in a existing network environment.

Thanks for Help
Stefan

As IPFire is a router/firewall you can not have the green and red interfaces on the same subnet.

I believe that what you are trying to do with IPFire is to use it with only the red interface being connected to your 192.168.100.x/24 subnet and trying to get the IPFire OpenVPN service to that subnet via the red interface.

If that is the case then I don’t believe it will function as it was not designed to work in that way, other more experienced users can confirm or deny that.

The only way I can think of to use IPFire to provide the OpenVPN service would be to place IPFire after your existing Internet Router, presuming that you are not able to replace that Internet Router with IPFire for some reason and use it to service your workstations and servers.

You will then have a double NAT situation and you would have to change the subnet definitions either on the workstations and servers or on the Internet Router.

I have not used the IPF OpenVPN, but as an approach can you connect IPF’s green interface to your LAN - give it a static IP and disable its DHCP server. Do not connect red at all. You would have to port forward udp:1194 through your router to green.

If you want to do reverse connections, so for example if a road warrior needs remote support that you provide from your LAN, in your router you would need a static route to your OpenVPN subnets via IPF green. On some routers (e.g IPF and pfSense) you would also need a firewall rule to SNAT traffic from your LAN to the OpenVPN subnets to a source IP of your router LAN. You may be able to avoid setting static routes in your router, if you directly add them to your workstation.

A problem of this approach is that, as IPF has no red connection, you will not be able to update IPF. You would also need to set its DNS resolver to an internal IP address like your router.

Looking at the docs, it looks like you can also do it with a red connection, in a similar way as I did with IPFire as a router and ClearOS (in router mode) as my OpenVPN server. The set up goes like this:
Do not connect green (you may want to connect it straight to your PC for the initial set up)
Connect red to your LAN, with a static IP or fixed lease from your router
Port forward udp:1194 from your router to IPF
In IPF OpenVPN Advanced options, add a route to the red0 LAN
You will need to check this one as I can’t, but you may need to add a firewall rule in IPF to SNAT all incoming traffic from your OpenVPN subnets to your red IP.

If you want to connect to your road warriors from your LAN you need the set up as explained before but you also need more:
In IPF open the incoming red firewall to all traffic from your router LAN (you may want this anyway to administer your IPF)
I also had to add a firewall rule to allow traffic from the red subnet through the FORWARD chain to the OpenVPN subnets. This is not a full port forward rule as there are no ports specified and no DNAT rule is needed. In ClearOS the rule was:

iptables -I FORWARD -s red_subnet -d openvpn_subnet -j ACCEPT

With this approach, red is connected so you can update IPF. It is just the firewalling becomes more complicated and I had to do a bunch of packet sniffing to get it to work. It was only complicated as I need to provide remote support to a road warrior (my 94 year old mother).