On Fri, 2019-04-05 at 15:54 +0100, David Woodhouse wrote:
> On Fri, 2019-04-05 at 17:31 +0300, Daniel Lenski wrote:
> > There doesn't seem to be much (if any) wiggle room in how the ESP
> > packets are formatted once the enc+MAC methods are specified,
>
> Hah. You say that, and yet as I try to make OpenConnect talk to the
> kernel's ESP implementation following on from my last email, I see that
> Wireshark (equipped with ESP keys and everything) can decode the
> kernel's traffic, and shows that it has padding and "next header"
> fields in the ESP, while what OpenConnect sends is the bare SPI/seq/IV
> that we know.
>
> So there's something else going on there. I wonder if I needed the
> UDP_ENCAP_NO_IKE variant...
No, I'm being dim. It's showing the padding etc. from inside the
encrypted payload, because it managed to decrypt it. While it didn't
manage to decrypt the packets from OpenConnect.
If I set the AES128 and SHA1-HMAC keys to actually be 128 and 160 bits
respectively, I have OpenConnect talking to the kernel.
#!/bin/sh
EKEY=0x12345678901234567890123456789012
AKEY=0x1234567890123456789012345678901234567890
SPI1=0x12345678
SPI2=0x87654321
SRC=10.0.161.101
DST=10.0.186.131
LOCAL=172.16.0.1
REMOTE=172.16.0.2
if ip addr list dev eth0 | grep -q $DST; then
xDST=$SRC
SRC=$DST
DST=$xDST
xLOCAL=$REMOTE
REMOTE=$LOCAL
LOCAL=$xLOCAL
xSPI1=$SPI2
SPI2=$SPI1
SPI1=$xSPI1
fi
echo $SPI1 $SPI2
ip xfrm state del src $SRC dst $DST proto esp spi $SPI1
ip xfrm state del src $DST dst $SRC proto esp spi $SPI2
ip xfrm state add src $SRC dst $DST proto esp spi $SPI1 reqid $SPI1 mode tunnel auth sha1 $AKEY enc aes $EKEY encap espinudp 8443 8443 $SRC
ip xfrm state add src $DST dst $SRC proto esp spi $SPI2 reqid $SPI2 mode tunnel auth sha1 $AKEY enc aes $EKEY encap espinudp 8443 8443 $SRC
ip xfrm policy add src $LOCAL dst $REMOTE dir out tmpl src $SRC dst $DST proto esp reqid $SPI1 mode tunnel
ip xfrm policy add src $REMOTE dst $LOCAL dir in tmpl src $DST dst $SRC proto esp reqid $SPI2 mode tunnel
ip addr add $LOCAL dev lo
ip route add $REMOTE dev eth0 src $LOCAL
HTTP/1.1 200 OK
Content-Length: 991
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response>
<ip-address>172.16.0.1</ip-address>
<netmask>255.255.255.0</netmask>
<mtu>1460</mtu>
<gw-address>172.16.0.2</gw-address>
<ipsec>
<udp-port>8443</udp-port>
<enc-algo>aes128</enc-algo>
<hmac-algo>sha1</hmac-algo>
<c2s-spi>12345678</c2s-spi>
<s2c-spi>87654321</s2c-spi>
<ekey-c2s>
<bits>512</bits>
<val>1234567890123456789012345678901234567890123456789012345678901234</val>
</ekey-c2s>
<ekey-s2c>
<bits>512</bits>
<val>1234567890123456789012345678901234567890123456789012345678901234</val>
</ekey-s2c>
<akey-c2s>
<bits>512</bits>
<val>1234567890123456789012345678901234567890123456789012345678901234</val>
</akey-c2s>
<akey-s2c>
<bits>512</bits>
<val>1234567890123456789012345678901234567890123456789012345678901234</val>
</akey-s2c>
<ipsec-mode>esp-tunnel</ipsec-mode>
</ipsec>
</response>
HTTP/1.1 200 OK
Content-Length: 124
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response>
<hip-report-needed>no</hip-report-needed>
</response>
START_TUNNEL
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
