2

Description:

I am learning how to configure ipsec with libreswan. I want to set up a host-to-host vpn between two hosts. I want each host to use a virtual interface for their ipsec tunnel.

Problem:

I set up my ipsec configuration with RSA, and started the tunnel, however no virtual interface was built.

System:

(2) RHEL 8.2 virtual machines

Whats not clear to me

  • How do I start the tunnel? I get that I run ipsec auto --up mytunnel, however does that command need to be run on both systems at the same time or on the right first then the left?
  • My "left" and "right" ips are ip addresses configuring on interfaces that can route to each other. Is this correct?
  • I feel like I am missing a step here, like configuring an interfaces and setting up libreswan to use it possibly?

Troubleshooting:

  • I followed these instructions on how to set up the ipsec tunnel.
  • I confirmed with netstat, seems all interfaces are listening on 500 and 4500.
  • Performed a ip a, I see no virtual interface being created.
  • To start the tunnel I run systemctl restart ipsec.service, then ipsec auto --up mytunnel, and lastly ipsec auto --up mytunnel, I see this output
181 "mytunnel" #1: initiating IKEv2 IKE SA 181 "mytunnel" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 182 "mytunnel" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=DH19} 002 "mytunnel" #2: IKEv2 mode peer ID is ID_FQDN: '@west' 003 "mytunnel" #2: Authenticated using RSA with IKEv2_AUTH_HASH_SHA1 002 "mytunnel" #2: negotiated connection [10.10.10.111-10.10.10.112:0-65535 0] -> [10.10.10.111-10.10.10.112:0-65535 0] 004 "mytunnel" #2: STATE_V2_IPSEC_I: IPsec SA established transport mode {ESP=>0xe25ebdee <0x3d8ac123 xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=passive}

My ipsec config:

conn mytunnel auto=add leftid=@west left=10.10.10.111 leftrsasigkey=0sAwEAAbqd ... blqu1K0= rightid=@east right=10.10.10.112 rightrsasigkey=0sAwEAAboA ... NEJbLk= authby=rsasig

EDIT Fixed my log output.

EDIT2 I learned that ipsec does not set up a virtual interface on its own. This needs to be done via IPIP, GRE, or other methods.

  • This is a helpful link on different kinds of ways to set up VPN routing.
  • This is a good link on how to set up IPIP.
Improve this question

1 Answer 1

Reset to default
2

IPsec doesn't necessarily use a virtual interface.

Instead, you have an IPsec policy database (setkey -DP shows the current contents), and these policies are applied to packets as they pass through the stack.

This is useful when you don't want the extra effort of assigning additional addresses and making sure they are conflict-free with other uses.

Transport mode, as you have configured it, does not even have space in the packets for the additional addresses. A policy like yours says "any packet from 10.10.10.111 to 10.10.10.112 needs to be encrypted and then routed normally", but if you don't have any interface using these addresses, then no such packet would ever be generated.

It's not entirely clear to me why you'd have different addresses in the logfile than in the configuration.

The IPsec setup you have would encrypt packets between 10.104.8.109 and 10.104.8.108, according to the log. If you ping one of these hosts from the other, the ping packets should be encapsulated, with a packet structure IP - ESP - ICMP, and anyone not in possession of the key would only be able to see the ESP and not be able to tell what inner protocol was transported in it.

For tunneling, two main approaches exist: applying an IPsec policy to an unencrypted tunnel, and connecting two networks that would be routed through the same interface anyway.

The unencrypted tunnel would use GRE or IPIP, to create a packet structure IP - IP - ICMP, and the encryption policy (in transport mode) would then wrap around the inner IP header to get IP - ESP - IP - ICMP. The tunnel provides the virtual interface that the IP addresses are bound to.

The network link approach uses tunnel mode IPsec, that still doesn't create an interface though. Here, the packets arrive from the internal network interface and are addressed to a destination not on the internal interface, so they are routed to the default route. The IPsec policy wraps the entire packet in a transport packet that brings it to the other side, where it is unwrapped and routed normally to the internal interface there. The routers in between do not see the internal addresses, so they can be in private ranges. For this approach, no virtual network device is needed either, and the routers do not need routing entries for the remote network.

Improve this answer
6
  • Thanks for the explanation. Re: the logs showing different IPs, I realized I posed the wrong log entry from a previous attempt, which I was using different systems. I have updated the log output in my original post. I want to make sure I understand, the "right" and "left" ip addresses specified are used to negotiate the handshake for ESP. The right and left ip interfaces are then used to encrypt traffic. So basically my libreswan connection is working, all traffic (L3 and above) going to the specified left to right or right to left, is encrypted. Is that true? Commented Apr 14, 2021 at 18:01
  • If this is all true, could I just create another interface, assign them different IPs, and use those interfaces in my libreswan config for left and right? If so, is there anyway to automatically have these interfaces be turned on when the the tunnel is turned up, outside of scripting it? Note: the traffic is all L2, and no tagging is involved (all access ports). Commented Apr 14, 2021 at 18:01
  • @Dave, first check if you really need an extra interface. For point-to-point encryption, you can just use the global addresses, for net-to-net connections, you can use tunnel mode. The only scenario left is node-to-net, the "laptop and company VPN" scenario. The IPsec people call this the "roadwarrior" scenario, and there are several guides how to do this. Commented Apr 15, 2021 at 8:35
  • @Dave if you really need an interface, IPIP or GRE are how you create it, and you'd use left/right for the public IPs, and leftsubnet/rightsubnet for the private ones. The route-based VPNs wiki page has a few more details. Commented Apr 15, 2021 at 8:40
  • @Dave, but the general assumption in IPsec is that the VPN will be statically configured because it maps the policy requirements, and these don't change. So if the policy is "you need to use a VPN to access the email server", you set up a policy for the IP address of the mail server, and have the IKE daemon negotiate the encryption on first use. Commented Apr 15, 2021 at 8:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.