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
