One network cannot ping hosts on another via ipsec

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.

Any ideas?

Perhaps this will help.

I tried the suggested commands on both sides, thanks for the thought, unfortunately I still cannot ping from the remote site to the main site.

Chris

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

[root@ipfire var]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G  4.0K  3.9G   1% /dev
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           3.9G  640K  3.9G   1% /run
/dev/sda3       2.0G  1.8G   73M  97% /
/dev/sda1        59M   36M   20M  65% /boot
/dev/sda4       107G   66G   37G  65% /var
/var/lock       8.0M   12K  8.0M   1% /var/lock

Please help.

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.

2 Likes

Can anyone assist Chris? I’d hate for him to be terminated because of a mis-configured device. That just seems mean! No pressure, eh?

Chris - read through this and see if it might help:

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?

Chris

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.

Chris

Get the patch file from the IPFire git.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8077bacb826bb336d98d90c628ad8fece098dc16

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.

patch -b /usr/libexec/ipsec/_updown -i patch-file-path-and-name

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.

Any help is appreciated.

This is a wild guess - I don’t use ipsec network to network.

with ipsec - look-up the nat_traversal setting. This may only exist with pluto which I don’t think ipfire uses any longer.

I can try it, where do I find that setting in IPFire?

It is not in IPFire.

It is part of the configuration of ipsec. I just looked in /var/ipfire/vpn/ipsec.conf and /etc/ipsec.user.conf and it is NOT there.

So you will need to research what it is and how it is added to one of the config files above.

Are there any errors in the ipsec logs? please post the logs (redact as needed).

Look at the same time the system connects and then disconnects.

Nothing that I can see, here’s the log:

11:38:52 charon: 12[NET] received packet: from MAIN_OFFICE_IP[500] to REMOTE_OFFICE_IP[500] (228 byte s)
11:38:52 charon: 12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG _SUP) N(HASH_ALG) N(REDIR_SUP) ]
11:38:52 charon: 12[IKE] MAIN_OFFICE_IP is initiating an IKE_SA
11:38:52 charon: 12[IKE] MAIN_OFFICE_IP is initiating an IKE_SA
11:38:52 charon: 12[CFG] selected proposal: IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_25519
11:38:52 charon: 12[IKE] sending cert request for C=US, ST=WI, L=Hudson, O=3DPA, OU=IS, CN=3DPA CA, E=netadmin@five-star-plastics.com
11:38:52 charon: 12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) C ERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
11:38:52 charon: 12[NET] sending packet: from REMOTE_OFFICE_IP[500] to MAIN_OFFICE_IP[500] (261 bytes )
11:38:52 charon: 14[NET] received packet: from MAIN_OFFICE_IP[4500] to REMOTE_OFFICE_IP[4500] (360 by tes)
11:38:52 charon: 14[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT _AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
11:38:52 charon: 14[IKE] received 2 cert requests for an unknown ca
11:38:52 charon: 14[CFG] looking for peer configs matching REMOTE_OFFICE_IP[B]…MAIN_OFFICE_IP[A]
11:38:52 charon: 14[CFG] selected peer config ‘FSP3DPA’
11:38:52 charon: 14[IKE] authentication of ‘A’ with pre-shared key successful
11:38:52 charon: 14[IKE] peer supports MOBIKE
11:38:52 charon: 14[IKE] authentication of ‘B’ (myself) with pre-shared key
11:38:52 charon: 14[IKE] IKE_SA FSP3DPA[2] established between REMOTE_OFFICE_IP[B]…MAIN_OFFICE_IP[A ]
11:38:52 charon: 14[IKE] IKE_SA FSP3DPA[2] established between REMOTE_OFFICE_IP[B]…MAIN_OFFICE_IP[A ]
11:38:52 charon: 14[IKE] scheduling reauthentication in 27805s
11:38:52 charon: 14[IKE] maximum IKE_SA lifetime 28345s
11:38:52 charon: 14[CFG] selected proposal: ESP:CHACHA20_POLY1305/NO_EXT_SEQ
11:38:52 charon: 14[IKE] CHILD_SA FSP3DPA{1} established with SPIs c330a327_i c8c3cd4d_o and TS 1 0.1.10.0/24 === 10.5.1.0/24
11:38:52 charon: 14[IKE] CHILD_SA FSP3DPA{1} established with SPIs c330a327_i c8c3cd4d_o and TS 1 0.1.10.0/24 === 10.5.1.0/24
11:38:52 charon: 14[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD _4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
11:38:52 charon: 14[NET] sending packet: from REMOTE_OFFICE_IP[4500] to MAIN_OFFICE_IP[4500] (274 byt es)

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.

All of the IPs listed above are a little confusing. Can you fill in the blanks? (redact as needed)

Site A:

IP for GREEN ?
IP for ipsec ?
IP for red (Comcast) ?

Site B:

IP for GREEN ?
IP for ipsec ?
IP for red (Comcast) ?

hopefully I didn’t miss something important!

1 Like

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.

1 Like