0

I have no networking experience but was tasked with setting up an IPSec tunnel at work with PPPoE. I've been working really hard at this, I didn't even know what IPSec and PPPoE were before starting this. But I'm stuck on a problem and need help, hopefully it is an easy/obvious fix. Thank you so much in advance for any help.

I was able to setup my IPSec tunnel using StrongSwan (Raspberry Pis running Raspbian) on just a home ethernet switch as a "test" to show that I could do it. However now I am trying to implement it on the real work server and the traffic keeps somehow getting passed but not encrypted. It is transferring as TCP instead of ESP. I am only trying to send TCP and eventually UDP packets. The setup is 2 Raspberry Pis plugged into a switch run by someone else so I'm not sure what exactly is going on on their end. They are guiding me with the configurations but I think there is something wrong on my end.

I will give as much background as possible. For my StrongSwan, here are my IPSec.conf IP addresses. I am simplifying the IPs for readability:

Pi 1:

left=1.1.130.10 leftsubnet=1.138.129.0/24 right=1.89.0.1 rightsubnet=1.138.130.0/24 Pi 2:

left=1.1.130.11 leftsubnet=1.138.130.0/24 right=1.89.0.1 rightsubnet=1.138.129.0/24 As you can see the way the server is set up (this config was given to me by the people running the server) the "right" is the same for both which I am not used to. Additionally I have to use PPPoE which I did not use on my personal ethernet switch test. My ppp0 interface IP is assigned 1.1.130.10 (Pi 1) and 1.1.130.11 (Pi 2).

The Pis each have a default eth0 connection set up with IPs 1.138.129.9 (Pi 1) and 1.138.130.9 (Pi 2). Here are the commands I am running to try to get this setup:

ip route flush all (get rid of all default routes) pon dsl-provider (start PPPoE) ip route delete default del ppp0 (remove the default route through ppp0) ip route add 1.89.0.1/32 dev ppp0 (add new route to "right") ifconfig eth0:1 1.138.129.1/24 up (create virtual interface) ip route add default dev eth0:1 (add default route via that interface) ipsec up myconn (start IPSec)

That is for Pi 1 and the only thing changed for Pi 2 is the 1.138.129.1 to 1.138.130.1. Everything establishes successfully running those commands. However using WireShark to check my packets they are coming through as TCP when I try to send my TCP data through the tunnel (expecting ESP). Additionally, each Pi seems to be somehow still sending to the opposite's eth0. So when I send from Pi 1, it "arrives" on Pi 2 at 1.138.130.9. I have tried a variety of troubleshooting with guidance from the server folks but there has to be something we are missing.

Any help would be extremely appreciated. I know some of this explanation probably makes no sense so I am happy to answer questions to clarify. Thank you again.

Sierra R
  • 1
  • You are using global IP addresses that (most likely) belong to someone else. This causes a variety of problems. If these IP networks were not assigned to you by Telstra, stop immediately and renumber your networks. – Michael Hampton Sep 02 '20 at 02:21
  • Hi, thank you so much for responding, sorry I wasn't specific enough in the initial question. The server that I am connected to is fully private and not connected to the internet or any wider network. It is just a "testbed" setup with those assigned IPs by whoever is running the server. – Sierra R Sep 02 '20 at 02:24
  • Also note that by default left is the local endpoint and right is the remote endpoint, and to reduce confusion it is a best practice to always make left the local endpoint on every endpoint. It looks like whoever gave you these configs mixed these up. You should make the obvious correction. – Michael Hampton Sep 02 '20 at 02:26
  • Ok, thank you so much for your help. So I thought the endpoints was supposed to be those ppp0 endpoints (1.1.130.10 for Pi 1 and 1.1.130.11 for Pi 2). Is that not correct? What I seem to be having is that even an IP address on the leftsubnet is somehow routing traffic around the tunnel and not being encrypted. – Sierra R Sep 02 '20 at 14:59

0 Answers0