libreswan configure virtual interface for ipsec traffic

Question

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.

Answer 1

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.