Tag: IPsec

Ubuntu server used as ipsec vpn router

Could you please help me to configure simple ubuntu router?

I have configured very simple 2 port ubuntu router, 1 wan and 1 lan port. source How To: Build a Simple Router with Ubuntu Server 18.04.1 LTS (Bionic Beaver) by Blaz Valentinuzzi.

I also setup VPN server using IKEv2-setup guide, source Set up Ubuntu Server 18.04 as an IKEv2 VPN server by George MacKerron.

Could some one help me to get it working?

Secure ways to share IPsec Pre-Shared Keys

I’m looking to setup a Site to Site IPsec VPN with a 3rd party and require to give a pre-shared key with the 3rd party for authentication as described here.

It mentions you should share this key over Phone/Fax/SMS rather than over the internet. The benefit I can see of over the phone is that once shared and configured there is no audit trail or copy of this key. If there are any issues we simply generate a new key and configure on the other end.

Would it be safer and more secure to share this pre-shared key over the phone or via PGP Email? Are the risks associated with “tapping the phone line” negligible in this instance?

Could IPSec flows be decrypted using PSK [duplicate]

This question already has an answer here:

  • IPsec with PSK: Can PSK be used for passive eavesdroping? 1 answer

I created an IPSec tunnel between two VMs using StrongSwan. It relies on a Pre-Shared Key. I wonder, if this key is leaked, what could an attacker perform? Would he/she be able to decrypt previous exchanges? Could he/she perform a MITM without be detected? And more generally, what is the impact?

Some details:

  • Mode Tunnel
  • auth-trunc hmac(sha256)
  • enc cbc(aes)

How can I make sure ping traffic over ipsec is going outside?

I’ve got a VPN tunnel (ipsec / StrongSwan) setup, connected. The other side is apparently able to ping me through the tunnel. However a ping from my side is said to be never received on the other side. The other side (that I cannot control) is thus assuming it’s a configuration issue from my side.

I’m really not sure about this, because I can see the ping packets going out when tcpdumping:

$   ping -c 5 192.168.33.1 PING 192.168.33.1 (192.168.33.1) 56(84) bytes of data. --- 192.168.33.1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4009ms  (at the same time in another console) $   tcpdump host REMOTE 09:22:07.539582 IP LOCAL > REMOTE: ESP(spi=0xXXXXXX,seq=0x3), length 132 09:22:08.547608 IP LOCAL > REMOTE: ESP(spi=0xXXXXXX,seq=0x4), length 132 (... one packet per ping ...)

The ESP traffic is obviously my ping. To make sure I’ve disabled all firewalling from my side.

Thus my question: How can I make sure the ping packets are going out and received? What can be the cause and what can I do more to help debug the issue?

As a side note, I’ve got another VPN setup and working, using the exact same configuration.

What is the Identification Payload of RFC2407 used for in IPsec?

RFC2407 outlines the Identification Payload in section 4.6.2, which appears in the fifth and sixth packets of the Main Mode’s SA negotiation when using IKEv1. What is this information used for?

From what I understand, when using PSK, this gets set to the IP address of the VPN peer, which can already be found in the source IP field. The source IP field might not be encrypted, but so what? Is there some advantage to having this same IP information encrypted?

Doesn’t the fact that both sides know the PSK, or both have the private key that goes with the certificate they present already identify them? Why does the Identification Payload need to identify them again?

Host connected to IPSec tunnel, docker not able to talk to VPN hosts

Host can ping hosts in vpn, docker container cannot ping any hosts that are in vpn.

route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.1 0.0.0.0 UG 600 0 0 wlan0 3.210.122.60 192.168.100.1 255.255.255.255 UGH 0 0 0 wlan0 172.17.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.18.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.19.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.20.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.21.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.22.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.23.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.24.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.25.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.26.0.0 192.168.100.86 255.255.0.0 UG 0 0 0 wlan0 172.41.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.100.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0 tcdump showing the ping goes to the VPN, and it returns to host, but not to the container. I believe the host has no idea what to do with the package it receives back from the vpn.

I tried some iptables rules but to no avail. Can’t debug more than tcpdump…

docker --version Docker version 18.03.1-ce, build 9ee9f40

cat /etc/*release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS" NAME="Ubuntu" VERSION="18.04.2 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.2 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic