Re: [gentoo-user] IPsec

[Grant Taylor]

On 4/6/21 8:09 AM, J. Roeleveld wrote:
> I only managed to get it working between off-the-shelve devices,
> but would prefer to do it from Linux.

That's where some of my experience is; SOHO routers, 15+ years ago.  I 
think I did manage to get FreeS/WAN (at the time) to establish a VPN 
with one of the SOHO routers that I was using at the time.

But I've started to get some more experience using IPsec without IKE 
recently.

> Please keep it on the list so I can participate in the process.

Okay.  Here's a copy of what I've sent to the handful of people that 
replied to me in the varies places I sent the broadcast.

I'll elaborate on the things that I'm pondering below.

- ip xfrm - I'm currently dabbling with IPsec transport mode between 
some systems using the following commands:

--8<--
      1    AKEY1=0x$(xxd -c 32 -l 32 -ps /dev/random)
      2    AKEY2=0x$(xxd -c 32 -l 32 -ps /dev/random)
      3    AID=0x$(xxd -c 4 -l 4 -ps /dev/random)
      4    ASRC="$LeftIP"
      5    ADST="$RightIP"
      6    ALOCAL="$ASRC"
      7    AREMOTE="$ADST"
      8    echo "Run the following commands on $LeftHost."
      9    ip xfrm state add src $ASRC dst $ADST proto esp spi $AID 
reqid $AID mode transport auth sha256 $AKEY1 enc aes $AKEY2  # b out 
state (SA)
     10    ip xfrm policy add src $ALOCAL dst $AREMOTE dir out tmpl src 
$ASRC dst $ADST proto esp reqid $AID mode transport      # b out policy
     11    ip xfrm state add src $ADST dst $ASRC proto esp spi $AID 
reqid $AID mode transport auth sha256 $AKEY1 enc aes $AKEY2  # b in 
state (SA)
     12    ip xfrm policy add src $AREMOTE dst $ALOCAL dir in tmpl src 
$ADST dst $ASRC proto esp reqid $AID mode transport       # b in  policy

     13    echo
     14    echo
     15    echo

     16    echo "Run the following commands on $RightHost."
     17    ip xfrm state add src $ADST dst $ASRC proto esp spi $AID 
reqid $AID mode transport auth sha256 $AKEY1 enc aes $AKEY2  # d out 
state (SA)
     18    ip xfrm policy add src $AREMOTE dst $ALOCAL dir out tmpl src 
$ADST dst $ASRC proto esp reqid $AID mode transport      # d out policy
     19    ip xfrm state add src $ASRC dst $ADST proto esp spi $AID 
reqid $AID mode transport auth sha256 $AKEY1 enc aes $AKEY2  # d in 
state (SA)
     20    ip xfrm policy add src $ALOCAL dst $AREMOTE dir in tmpl src 
$ASRC dst $ADST proto esp reqid $AID mode transport       # d in  policy
-->8--

This is working and does enable IPsec /transport/ /mode/ between 
$LeftHost and $RightHost.  But it's completely manual at the moment.

I'm curious if you have any comments on "ip xfrm".

- strongSwan / Libraswan / OpenSwan / FreeS/WAN - I dabbled with 
FreeS/WAN the better part of 20 years ago.  It worked at the time.  But 
I've not needed or wanted to do anything with IPsec again until 
recently.  --  I've taken a foray through OpenVPN and WireGuard, both of 
which were decidedly easier than IPsec.

It's my understanding that OpenSwan and strongSwan are direct forks of 
FreeS/WAN and that Libraswan is a fork or rename of OpenSwan.

What I'm not sure of is what the actual current status of the *Swan(s) is.

Also, how do the *Swan(s) relate to racoon, which I see reference as 
being independent.

- X.509 certificate based authentication - One of the reasons my script 
above is manual is because I don't want to embed keying material in 
config files on the VPSs that I'm using IPsec transport mode between. 
I'd like to figure out if it's possible to use X.509 certificates to 
have the two IPsec endpoints authenticate against each other and 
dynamically negotiate keying material based on their public & private 
key pairs that they already have.

E.g. can $LeftHost use use it's private key to authenticate itself to 
$RightHost and vice versa?

I presume that this would be done via IKE, and I further presume that it 
will likely be IKEv2.

- Opportunistic Encryption - I really like the idea of IPsec 
Opportunistic Encryption so that systems can dynamically / automatically 
configure and use IPsec /transport/ /mode/ encryption between each other.

- AH vs ESP - Do the cryptographic primitives of ESP supplant AH in 
confirming ~> authenticating that the traffic came from the host that is 
sending the traffic?  E.g. can ESP offer the same authentication that AH 
does?  Or are AH and ESP truly different functions which don't overlap?

- Transport vs Tunnel Mode - I'm really interested in /transport/ mode 
more than I am tunnel mode.  I'd like to get my various servers to use 
IPsec /transport/ mode configured (much like my script) to protect all 
of the traffic between them.

I did some playing this weekend with /transport/ mode between my Linux 
router at home and one of my VPS(s).  Yes, my Linux router is 
functioning as a basic NATing router.  But, it occurred to me 
/transport/ mode might work between my router and my VPS(s) in that 
Linux /was/ doing the /NAT/ing.  Meaning that it was effectively the 
endpoint of the traffic.  Thus the traffic might work via /transport/ mode.

Suffice it to say that I was pleasantly surprised that my script above 
actually worked both for my router's access to the VPS(s) /and/ mostly 
worked for traffic from NATed clients inside my home.  I say /mostly/ 
because traffic was working between clients and my VPS(s) with the 
annoying exception of SSH which was successfully negotiating and 
starting sessions before running into MTU issues.  I was able to work 
around the MTU issues via typical TCPMSS --set-mm games.

So ... I was able to ""tunnel NATed traffic through IPsec /transport/ 
mode ESP.  }:-D

I'd be very curious to learn what your reactions are to what I've done 
and would like to do plus any pointers or gotchas to avoid that you 
would care to share.

Thank you for replying to my open ended broadcast.  :-



-- 
Grant. . . .
unix || die