Various problems with VPN after ipfire reinstallation

Virtual Private Networks OpenVPN
1

Hi,
For explaining, i had before 2 ipfire with core166 installed on them. One day perhaps 2 years ago, after a core update, VPN was not working anymore. As i’m alone to manage that, i wasn’t able to test more times why it was not working.
So i had restored VM backups to have a working solution.
During holidays after, i’ve tested rebuild ipfire and restore ipfire backup. The result was the same, it was not working.
So, this year, i’ve rebuilt each ipfire from scratch core193 and set each parameters manually.
I’ve switched ipfire last week and i have several issues now.

I have problems with firewall/openvpn/ipfire. I can’t find the origin of the issue.
My old systems was core166 and everything was working as expected. I will explain the network configuration and hope that someone could help me to resolve the issue.

I’m IT manager in a school. There is two sites so i have one ipfire on each site. On each site, there is the same configuration. Some networks (a green for students networks (class computers, wifi etc…) and blue for administration people).
Ipfire is running in VM with XCP-ng like others DC and fileservers on each site.

On siteA, hypervisor XCP-ng is 172.16.4.1 and hosting several servers like ipfire and
samba dcA 172.16.4.3
samba FileSrvA 172.16.4.5
windows VM administration for me 172.16.4.6
My laptop on siteA is on network 10.29.111.x
green LAN is 10.1.0.6/29 behind a router that manage several networks

  • 172.16.4.0/22 for wired computers
  • 172.16.8.0/22 for wifi laptops/ipads
  • 10.29.111.0/24 for administration people (primary site for administration people)
    Roadwarrior VPN is 10.1.201.0/24

On siteB, hypervisor XCP-ng is 172.16.0.1 and hosting several servers like ipfire and
samba dcB 172.16.0.3
samba FileSrvB 172.16.0.5
windows VM administration for me 172.16.0.6
My laptop on siteB is on network 172.16.0.x
green LAN is 10.0.0.6/29 behind a router that manage differents networks

  • 172.16.0.0/22 for wired computers
  • 172.16.64.0/22 for wifi laptops/ipads
    blue LAN is 10.29.112.0/24
    Roadwarrior VPN is 10.1.202.0/24

There is a n2n vpn named vpninterco between ipfireB (server) and ipfireA (client)
local subnet 10.0.0.0/255.255.255.248 ↔ remote subnet 10.1.0.0/255.255.255.248
openvpn subnet 10.10.2.0/255.255.255.0 port 11960

There is a n2n vpn named vpnpedagogie between wired network 172.16.0.0/22 (server) and 172.16.4.0/22 (client)
local subnet 172.16.0.0/255.255.252.0 ↔ remote subnet 172.16.4.0/255.255.252.0
openvpn subnet 10.20.20.0/255.255.255.0 port 11950

There is a n2n vpn named vpnadministration between 10.29.112.0/24 on siteB and 10.29.111.0/24 on siteA
local subnet 10.29.112.0/255.255.255.0 ↔ remote subnet 10.29.111.0/255.255.255.0
openvpn subnet 10.10.10.0/255.255.255.0 port 11940

Public IPs are been renamed
SiteA routing table
default via SiteA-RED-GW dev red0
10.0.0.0/29 via 10.10.2.1 dev tun1
10.1.0.0/29 dev green0 proto kernel scope link src 10.1.0.6
10.1.201.0/24 via 10.1.201.2 dev tun0
10.1.201.2 dev tun0 proto kernel scope link src 10.1.201.1
10.10.2.1 dev tun1 proto kernel scope link src 10.10.2.2
10.10.10.1 dev tun2 proto kernel scope link src 10.10.10.2
10.20.20.1 dev tun3 proto kernel scope link src 10.20.20.2
10.29.112.0/24 via 10.10.10.1 dev tun2
10.29.113.0/24 dev blue0 proto kernel scope link src 10.29.113.253
172.16.0.0/22 via 10.20.20.1 dev tun3
SiteA-RED-NET/30 dev red0 proto kernel scope link src SiteA-RED-IP
SiteA-RED-GW dev red0 scope link

SiteB routing table
default via SiteB-RED-GW dev red0
10.0.0.0/29 dev green0 proto kernel scope link src 10.0.0.6
10.1.0.0/29 via 10.10.2.2 dev tun2
10.1.202.0/24 via 10.1.202.2 dev tun1
10.1.202.2 dev tun1 proto kernel scope link src 10.1.202.1
10.10.2.2 dev tun2 proto kernel scope link src 10.10.2.1
10.10.10.2 dev tun3 proto kernel scope link src 10.10.10.1
10.20.20.2 dev tun0 proto kernel scope link src 10.20.20.1
10.29.111.0/24 via 10.10.10.2 dev tun3
10.29.112.0/24 dev blue0 proto kernel scope link src 10.29.112.9
SiteB-RED-NET/30 dev red0 proto kernel scope link src SiteB-RED-IP
SiteB-RED-GW dev red0 scope link
172.16.4.0/22 via 10.20.20.2 dev tun0

For my administration, I had several rules on each firewall to allow me access all networks and i’ve recopied all rules from old servers to new servers

Now what is working fine

  • IpfireA and IpfireB can ping themselves
  • dcA and dcB can ping themselves, and rsync tasks ok
  • FileSrvA and FileSrvB can ping themselves
  • on each site, VM administration (172.16.X.6) can see both hypervisors 172.16.4.1 and 172.16.0.1 and can manage and see console
    on VM administration i can access smb shares from dcA,dcB,FileSrvA,FileSrvB each site
  • computers on BLUE network 10.29.112.x can make RDP sessions without issues to 10.29.111.2 which is RDP server for administration people on siteB
  • My laptop on siteB can see hypervisors 172.16.4.1 and 172.16.0.1 and can manage and see console

Now what is not working anymore and was working on my previous install core166

  • computers on siteB (wired 172.16.0.x and wifi networks 172.16.64.x) can’t make RDP sessions on 10.29.111.2 siteB
  • computers on siteB (wired 172.16.0.x and wifi networks 172.16.64.x) can’t print on BLUE network 10.29.112.8
  • iPads/laptop connected on 172.16.64.0/22 siteB can’t communicate with mdm server on siteA (172.16.4.40) and more generally network 172.16.4.x
  • My laptop on siteA can’t access hypervisor 172.16.0.1 and more generally network 172.16.0.x
    but can access hypervisor 172.16.4.1

I don’t know if the problem come from ipfireB or ipfireA
If someone has some ideas, i’m alone to manage that and i haven’t ideas anymore.

thanks
Pierre

2

UPDATE 30/04: what is not working anymore and was working on my previous install core166

  • WORKING NOW: computers on siteB (wired 172.16.0.x and wifi networks 172.16.64.x) can’t make RDP sessions on 10.29.111.2 siteB (a firewall rule solve the problem)

  • WORKING NOW: computers on siteB (wired 172.16.0.x and wifi networks 172.16.64.x) can’t print on BLUE network 10.29.112.8 (a firewall rule solve the problem)

  • NOT WORKING iPads/laptop connected on 172.16.64.0/22 siteB can’t communicate with mdm server on siteA (172.16.4.40) and more generally network 172.16.4.x
    172.16.4.40 siteA can ping devices on 172.16.64.0/22 siteB
    172.16.64.0/22 siteB can’t ping 172.16.4.40 siteA

  • NOT WORKING My laptop on siteA can’t access hypervisor 172.16.0.1 and more generally network 172.16.0.x
    but can access hypervisor 172.16.4.1

I don’t know if the problem come from ipfireB or ipfireA
If someone has some hints, i would really appreciate. I’m alone to manage that and i haven’t ideas anymore.

thanks
Pierre

3

Thanks for a detailed description of your current setup. Reduces a lot the headaches and the questions, but does not ease them all.

From your detailed description, you’re using OpenVPN for both Roadwarrior and Site 2 Site connection. Am i correct?

Your current setup works with IpFire 166 but doesnt work with IPFire 193, and on both sites you have two XCP-NG guests. The working one with IPFire 166 and the not working one with 193.

Version 166 is really quite stale (release date march 2022) probably some of the cypers used are now deprecated in Core 193, this could lead to some issues.
Also, I have no experience i XCP-NG environemnt, may I assume that the installation of this Hypervisor is fully updated?

Last but not least: are you “resident” (present most of the times) on one site? Can you reach IPFire console via public internet from the public ip address of the “other” site?

4

Hi Pike
thanks for your answer

No, not exactly
My previous setup with 2 ipfire core166 was working as expected.
My new setup with 2 ipfire updated core193 is not working with the different parts explained.
I can access both ipfire from outside, so i can change rules easily.
thanks

5

IMVHO you should verify:
-delivered routing table on 172.16.64.0/22 subnet devices: traceroute is a important tool to understand where packets are delivered and on which path
-current routing table on IPFire Site B specifically for 172.16.64.0/22 subnet, back and forth
-current firewall rules with source 172.16.64.0/22 and destination 172.16.64.0/22 in Site B ipfire

Once sorted the “working theory” (you have all the routes necessary on on site B and the firewall rules are correct)… the same, reversed, should be verified on IPFire Site A.
Consider, for checking, keeping at ease the default “firewall rules” for IPFire and the default behaviour for zones (Green can go to Blue but not viceversa, and such). Check in which zone the remote networks (as IPFire POV are located.

And the same approach should be applied here, contextually adjusted.

While you need both routing and firewall rules be correctly configured to be accessed, routing has (sorf of) higher priority compared to firewalling: if packets are not routed correctly, Ipfire log will not show any “error” on firewall rules.

Hope this suggestion will help you in some way.

In any case: Backup Before Begin. At least you’ll have a “safe harbor” to get back in case something goes sideways.