<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Have you seen <a class="moz-txt-link-freetext" href="https://libreswan.org/wiki/Interoperability">https://libreswan.org/wiki/Interoperability</a>? It has an
AWS section. If you have, I'll duck out again.<br>
<br>
Nick<br>
<br>
<div class="moz-cite-prefix">On 23/03/2020 23:55, Mattias Mattsson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:809058276.635387.1585007733445@mail.yahoo.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="yahoo-style-wrap" style="font-family:Helvetica Neue,
Helvetica, Arial, sans-serif;font-size:16px;">
<div>Hi,</div>
<div><br>
</div>
<div>I’ve been trying to set up Libreswan to have a client
behind a NAT and a server on an AWS instance and I need some
help on completing this setup. Any assistance would be
appreciated.</div>
<div><br>
</div>
<div dir="ltr" data-setdir="false">The basic setup would be
(I've changed the public IP to 1.1.1.100 in all text below).<br>
</div>
<div dir="ltr" data-setdir="false"><client ubuntu
10.0.2.15> -- <NAT 1.1.1.100> -- <AWS
3.101.15.189> -- <AWS Private IP 172.31.10.176></div>
<div><br>
</div>
<div>I’ve created a Ubuntu 18.04 client in a VM using Virtualbox
and started a Ubuntu 18.04 EC2 instance in AWS. I installed
Libreswan from source (in order to ensure that I get the exact
same version on both client and server) following these
directions (roughly);
<a class="moz-txt-link-freetext" href="https://computingforgeeks.com/how-to-install-libreswan-on-ubuntu/">https://computingforgeeks.com/how-to-install-libreswan-on-ubuntu/</a></div>
<div><br>
</div>
<div>I’ve also disabled ICMP redirects and rp-filters according
to these directions<br>
<a class="moz-txt-link-freetext" href="https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_send_redirects_in_.2Fproc.2Fsys.2Fnet_.3F">https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_send_redirects_in_.2Fproc.2Fsys.2Fnet_.3F</a><br>
<a class="moz-txt-link-freetext" href="https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_rp_filter_in_.2Fproc.2Fsys.2Fnet_.3F">https://libreswan.org/wiki/FAQ#Why_is_it_recommended_to_disable_rp_filter_in_.2Fproc.2Fsys.2Fnet_.3F</a></div>
<div><br>
</div>
<div>In order to focus on establishing the connection I’ve
created a minimalistic configuration file for the client and
the server. <br>
ipsec.secrets (common for client and server)<br>
10.0.2.15 172.31.10.176 : PSK
"abcdefghijklmnopqrstuvwxyz0123456789"</div>
<div><br>
</div>
<div>ipsec.conf (client)<br>
conn ipsec_aws<br>
authby=secret<br>
encapsulation=yes<br>
right=3.101.15.189<br>
rightid=172.31.10.176<br>
left=10.0.2.15<br>
ikev2=no</div>
<div><br>
</div>
<div>ipsec.conf (server)<br>
config setup<br>
protostack=netkey</div>
<div>conn ipsec_aws<br>
authby=secret<br>
encapsulation=yes<br>
right=172.31.10.176<br>
left=1.1.1.100<br>
leftid=10.0.2.15<br>
ikev2=no</div>
<div><br>
</div>
<div dir="ltr" data-setdir="false">With this setup, the tunnel
seems to have been established and I see keep-alives between
client and server. However, I cannot connect from the client
to the server using e.g. ssh.<br>
<br>
The server shows the following IPsec connection from 'ipsec
auto --status'<br>
000 Connection list:<br>
000 <br>
000 "ipsec_aws":
172.31.10.176<172.31.10.176>...1.1.1.100<1.1.1.100>[10.0.2.15];
erouted; eroute owner: #2<br>
<br>
The server shows the following IP XFRM from 'ip xfrm state'<br>
# ip xfrm state<br>
src 1.1.1.100 dst 172.31.10.176<br>
proto esp spi 0x614eef4e reqid 16389 mode tunnel<br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0x8a6dd1d895008c75bd7a20e0160f05e8e83cb4ae 96<br>
enc cbc(aes) 0x60b4a07fda9d290b1ad74b060a557721<br>
encap type espinudp sport 65255 dport 4500 addr
0.0.0.0<br>
anti-replay context: seq 0xd, oseq 0x0, bitmap
0x00001fff<br>
src 172.31.10.176 dst 1.1.1.100<br>
proto esp spi 0xb531180d reqid 16389 mode tunnel<br>
replay-window 32 flag af-unspec<br>
auth-trunc hmac(sha1)
0xbded8cbbbd1c49056a3b72d7a15fa3a24b5ab77c 96<br>
enc cbc(aes) 0xb8e88ca3ac6e67b3130f745570f968d8<br>
encap type espinudp sport 4500 dport 65255 addr
0.0.0.0<br>
anti-replay context: seq 0x0, oseq 0x0, bitmap
0x00000000<br>
<br>
Doing tcpdump on the server (excluding the jump host to avoid
ssh traffic from the jump host) when trying to connect from
client to server via ssh.<br>
# tcpdump -ni eth0 not host xx.xx.xx.xx<br>
tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode<br>
listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes<br>
22:28:25.884430 IP 1.1.1.100.65255 > 172.31.10.176.4500:
UDP-encap: ESP(spi=0x614eef4e,seq=0x7), length 100<br>
22:28:25.884430 IP 10.0.2.15.54602 > 3.101.15.189.22: Flags
[S], seq 2809184565, win 64240, options [mss 1460,sackOK,TS
val 2951550712 ecr 0,nop,wscale 7], length 0<br>
<br>
I can see that the initial TCP SYN arrives from the client as
a UDP encapsulated ESP packet from the client's public IP (<span><span
style="text-align: left; color: rgb(0, 0, 0);
text-transform: none; text-indent: 0px; letter-spacing:
normal; font-family: "Helvetica
Neue",Helvetica,Arial,sans-serif; font-size: 16px;
font-style: normal; font-variant: normal; font-weight:
400; text-decoration: none; word-spacing: 0px; display:
inline !important; white-space: normal; orphans: 2; float:
none; background-color: rgb(255, 255, 255);">1.1.1.100.65255
> 172.31.10.176.4500</span></span>). The packet is
decrypted and forward to the server's public IP but from the
client's private IP (<span><span style="text-align: left;
color: rgb(0, 0, 0); text-transform: none; text-indent:
0px; letter-spacing: normal; font-family: "Helvetica
Neue",Helvetica,Arial,sans-serif; font-size: 16px;
font-style: normal; font-variant: normal; font-weight:
400; text-decoration: none; word-spacing: 0px; display:
inline !important; white-space: normal; orphans: 2; float:
none; background-color: rgb(255, 255, 255);">10.0.2.15.54602
> 3.101.15.189.22</span></span>). Given that the AWS
instance does not have the public IP it will not process the
packet.<br>
<br>
The question is what should be done here. Should I try to DNAT
the packet to the AWS instance’s private IP? Should I try to
use the servers private IP in the client configuration ‘right’
setting in order to use the server’s private IP instead? If I
change the ipsec.conf settings I can't get the tunnel to
connect. But if I keep them, the client gets an ip xfrm policy
between the clients private IP and the servers public IP so I
have to use the servers public IP to when doing ssh to get the
traffic to go through the tunnel. </div>
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">Any help would be
appreciated. Thanks!</div>
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">/ Mattias</div>
<div dir="ltr" data-setdir="false"><br>
<br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Swan mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a>
</pre>
</blockquote>
<br>
</body>
</html>