We have Two networks, connected via IPSEC Point to Point VPN tunnel. Our main 10.5.1 network can ping any host on the second network 10.1.10, but no host from 10.1.10 can ping any host on 10.5.1 except for the gateway, 10.5.1.1, that they can ping. I don’t see a firewall rule that’s blocking things, and IPSec is set up the same on both sides, the tunnel says it’s up.
I have two networks, the local network is 10.5.1.X (10.5.1.1 Gateway), The remote network is 10.1.10.X (10.1.10.1 Gateway). There is an IPSec tunnel established between the sites, and I can ping anything on the 10.1.10 network from 10.5.1.X hosts. However 10.1.10.X hosts can only ping the 10.5.1.1 Gateway, nothing inside of the network, and this is messing up time clock punches and now I’m being threatened that if I don’t get this fixed by tomorrow that I may be suspended or terminated.
I am not sure if this is related but I also cannot upgrade from 163 to 169 on the remote host because the file system / on /dev/sda3 only has 3% free of disk space
Not related. This is a known problem due to the growth of the kernel. You need to install IPFire from scratch so that a larger partition will be created and restore the back up.
I read through the replies from that thread, seems like there is an issue with Core Update 167, but it has been patched now in 168, referencing this patch: git.ipfire.org Git - ipfire-2.x.git/commit
I honestly do not know how to apply this patch in a live system, is this a process done via bash with pakfire? Does anyone have instructions?
I’ve already tried to update the remote site from 163 to 169 but the process fails every time because there is not enough free space on the device in the default place where it tries to pull the update file. Per cfusco above you have to install IPFire from scratch, which is easier said than done because that hardware is one hour away in a remote office.
Near the top there is a link called “patch”. Right click on that link and save the file somewhere and then copy it to your IPFire system that you want to patch.
It needs to end up in /usr/libexec/ipsec/
Then run this command, adding in the name of the patch that you downloaded in place of "patch-file-path-and-name. You can always rename it as it tends to be a name with a lot of digits/chars.
To be on the safe side I always make sure that I am in the directory where the file to be patched is located. Also ensures that the backup file will end up in that same directory.
The -b option means that it will also create a backup of the original file before patching so you can always revert back. Just don’t run the command twice otherwise the backup name will contain the result from the first attempt and not the original version.
The -i option specifies the location where you have placed the patch file. I usuacopy it to the /tmp/ directory.
However as always when you are patching a running system, take care that everything has been typed correctly. It is worth setting up a vm running IPFire so you can test out the patching process.
I am also not sure if having patched that file whether you then need to restart some daemon or reboot or not. I am not familiar enough with IPSec.
Well after troubleshooting the connection until 9:30 PM last night on site at the remove facility, I set up a brand new IPFire setup, running Core 169, so that’s running on both sides now. Initially when I set it up then restored the backup config from the older IPFire here, for 10 minutes the VPN was up and I could ping the punch clock server at the main office at 10.5.1.21. After 10 minutes the whole internet connection went offline here. I don’t know why. I rebooted the router, then after that the internet was back online and stayed online but I was back to the same scenario, the VPN was up and I could ping 10.5.1.1 but I could not get to anything else inside the network.
So both networks are online and the VPN says it’s connected now, but the result is the same, the 10.1.10 remote office cannot get to any other host on the 10.5.1.X network, it can just ping the gateway.
One clue to this whole mystery is that the comcast business modem here was handing out it’s own IP addresses via DHCP on a 10.1.10.X network, the scope was 10.1.10.2 - 253, that’ was the same range as what my internal green network was handing out. I changed the IP scheme of the cable modem to 10.1.2.1. Shortly after doing that last night for some reason the Comcast connection went offline entirely, even when restarting the modem and the router.
I called Comcast last night at 9 PM, they said a tech would come out within an hour, they didn’t show up so I drove home for an hour, finally getting to bed around midnight.
Today I’m back on site, and I talked to comcast who said the modem was online even though we didn’t have internet at the site. After troubleshooting we had to switch the red interface of the IPFire to be set to DHCP instead of the static address we paid for that we used before. After it was set to DHCP the IPFire was online. It was a different IP so I had to remote into the main office and change the IP the VPN connects into the remote office, so now the VPN is up but I’m back to the same scenario, 10.1.10.X hosts cannot ping anything on 10.5.1.X except for the gateway at 10.5.1.1.
I tried putting nat_traversal=yes in ipsec.conf, then restarted the tunnel, and now the tunnel will not come back up. It was not in the config file before at all.
After restarting the VPN connection, I tried checking Force using MOBIKE (only IKEv2) on both sides, and the tunnel came back up, but I still cannot ping anything from the remote office on the main office network of 10.5.1.X.
I think, he has a general problem with his network-setup.
I guess, his modem/router is not only connected to RED via WAN, but the modem LAN is also part of the physical GREEN internal network. And because Ipfire and the modem appear to be using the same internal network, he has a gateway problem. The clients are probably using the modem as gateway and not Ipfire. That would explain why he had no internet when he switched the modem’s network. And it would also explain why he can ping the X.1 via VPN but not the clients, because the clients communicate with the modem. And that would also explain why it worked for a short time when he made the new setup.
In short, I think, there is an IP conflict, because Ipfire and the modem are using 10.1.10.1 and are connected to the same physical network. If that’s the case, it’s enough to disconnect the modem lan or change the network of the modem and then restart Ipfire.