-
-
Save vishvananda/7094676 to your computer and use it in GitHub Desktop.
#!/bin/bash | |
if [ "$4" == "" ]; then | |
echo "usage: $0 <local_ip> <remote_ip> <new_local_ip> <new_remote_ip>" | |
echo "creates an ipsec tunnel between two machines" | |
exit 1 | |
fi | |
SRC="$1"; shift | |
DST="$1"; shift | |
LOCAL="$1"; shift | |
REMOTE="$1"; shift | |
KEY1=0x`dd if=/dev/urandom count=32 bs=1 2> /dev/null| xxd -p -c 64` | |
KEY2=0x`dd if=/dev/urandom count=32 bs=1 2> /dev/null| xxd -p -c 64` | |
ID=0x`dd if=/dev/urandom count=4 bs=1 2> /dev/null| xxd -p -c 8` | |
echo "spdflush; flush;" | sudo setkey -c | |
sudo ip xfrm state add src $SRC dst $DST proto esp spi $ID reqid $ID mode tunnel auth sha256 $KEY1 enc aes $KEY2 | |
sudo ip xfrm state add src $DST dst $SRC proto esp spi $ID reqid $ID mode tunnel auth sha256 $KEY1 enc aes $KEY2 | |
sudo ip xfrm policy add src $LOCAL dst $REMOTE dir out tmpl src $SRC dst $DST proto esp reqid $ID mode tunnel | |
sudo ip xfrm policy add src $REMOTE dst $LOCAL dir in tmpl src $DST dst $SRC proto esp reqid $ID mode tunnel | |
sudo ip addr add $LOCAL dev lo | |
sudo ip route add $REMOTE dev eth1 src $LOCAL | |
ssh $DST /bin/bash << EOF | |
echo "spdflush; flush;" | sudo setkey -c | |
sudo ip xfrm state add src $SRC dst $DST proto esp spi $ID reqid $ID mode tunnel auth sha256 $KEY1 enc aes $KEY2 | |
sudo ip xfrm state add src $DST dst $SRC proto esp spi $ID reqid $ID mode tunnel auth sha256 $KEY1 enc aes $KEY2 | |
sudo ip xfrm policy add src $REMOTE dst $LOCAL dir out tmpl src $DST dst $SRC proto esp reqid $ID mode tunnel | |
sudo ip xfrm policy add src $LOCAL dst $REMOTE dir in tmpl src $SRC dst $DST proto esp reqid $ID mode tunnel | |
sudo ip addr add $REMOTE dev lo | |
sudo ip route add $LOCAL dev eth1 src $REMOTE | |
EOF |
During Outgoing, first SP is consulted.. then appropriate SA is consulted and ecrypted and packet is sent out.
During incoming ESP, how do these rules come into picture... Is SA first consulted..and then SP consulted. ? Reason i ask this is, the incoming ESP packet is already encrypted. So for decrypting we would nee the SA information first. Kindly help clarifying my queries.
Thank you for all your help increase my understanding on this topic.
Thanks,
Ravikanth
Is there some way that I can specify AES encryption key lengths 64, 128 or 256bits?
Thanks a lot, Ondrej
AES support 128, 192, 256bits
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
For AES, NIST selected three members of the Rijndael family, each with a block size of 128 bits, but three different key lengths: 128, 192 and 256 bits.
the xfrm key length change to using aes128, aes192, aes256
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(md5)" "0x1122"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(md5)" "0x1111"
//ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc cipher_null "" auth-trunc "hmac(md5)" "0x1122" 96
//ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc cipher_null "" auth-trunc "hmac(md5)" "0x1111" 96
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(sha1)" "0x1122"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(sha1)" "0x1111"
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(sha256)" "0x1122"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc cipher_null "" auth "hmac(sha256)" "0x1111"
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "cbc(des)" "0x1122020304050607"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "cbc(des)" "0x1111020304050607"
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "cbc(des3_ede)" "0x112202030405060708090a0b0c0d0e0f0001020304050607"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "cbc(des3_ede)" "0x111102030405060708090a0b0c0d0e0f0001020304050607"
aes128bit
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "cbc(aes)" "0x112202030405060708090a0b0c0d0e0f"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "cbc(aes)" "0x111102030405060708090a0b0c0d0e0f"
aes256bit
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "cbc(aes)" "0x112202030405060708090a0b0c0d0e0f112202030405060708090a0b0c0d0e0f"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "cbc(aes)" "0x111102030405060708090a0b0c0d0e0f111102030405060708090a0b0c0d0e0f"
ctraes128bit (add 4byte nonce)
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "rfc3686(ctr(aes))" "0x112202030405060708090a0b0c0d0e0f00000000"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "rfc3686(ctr(aes))" "0x111102030405060708090a0b0c0d0e0f00000000"
ctraes256bit (add 4byte nonce)
ip xfrm state flush
ip xfrm state add src 192.168.168.1 dst 192.168.168.155 proto esp spi "0x1122" reqid "0x1" mode tunnel enc "rfc3686(ctr(aes))" "0x112202030405060708090a0b0c0d0e0f112202030405060708090a0b0c0d0e0f00000000"
ip xfrm state add src 192.168.168.155 dst 192.168.168.1 proto esp spi "0x1111" reqid "0x1" mode tunnel enc "rfc3686(ctr(aes))" "0x111102030405060708090a0b0c0d0e0f111102030405060708090a0b0c0d0e0f00000000"
I believe that echo "spdflush; flush;" | sudo setkey -c
can be replaced by ip xfrm state flush && ip xfrm policy flush
, in which case there is no need to install ipsec-tools for setkey
.
(Thanks for this and netlink API!)
I believe that
echo "spdflush; flush;" | sudo setkey -c
can be replaced byip xfrm state flush && ip xfrm policy flush
, in which case there is no need to install ipsec-tools forsetkey
.(Thanks for this and netlink API!)
+1
/tunnel.sh 10.10.10.1 10.10.10.2 192.168.0.1 192.168.0.2
Does it mean, the outer IP packets have the src IP as 192.168.0.1 and destination as 192.168.0.2 ? Also the inner encrypted packet has src IP 10.10.10.1 and destination as 10.10.10.2 ?
I am a newbie to ipsec and was trying to explore how ip xfrm commands work.
Thanks,
Ravi