<div dir="ltr">On Tue, Jul 30, 2013 at 7:47 AM, Paul Wouters <span dir="ltr"><<a href="mailto:pwouters@redhat.com" target="_blank">pwouters@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 29 Jul 2013, Mike C wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a recommended approach to run multiple openswan clients behind the same NAT IP? My scenario in particular is multiple 3G<br>
devices behind the same ISP CG-NAT IP (unfortunately).<br>
</blockquote>
<br></div>
"Do not use IPsec transport mode with L2TP".<br>
<br>
Once you stick to tunnel mode with XAUTH (using rightaddresspool=) you<br>
should have no issues with multiple clients behind the same NAT or<br>
multiple clients using the same internal IP behind different NATs.</blockquote><div><br></div><div>I am using tunnel mode already. No L2TP, just routers with 3G dongles providing net-net VPNs between offices. I don't believe XAUTH would help in this case?<br>
</div><div class="im"> <br><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I find that the connection works for both only if I the tunnel for a single router first, then the next. So add @router2 to the server,<br>
connect it, then add @router3 and connect it. If I don't do this, the server tries to associate the packets with the wrong tunnel (logs<br>
for 3.3 libreswan on server showed this, not seeing any debug logs on 3.5 but assume the same).<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the phase 1s (parent SA) aer similar, pluto will pick one of them,<br>
and might switch later. So it might look like it is picking the wrong<br>
one, but it is not.<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
conn routers-12<br>
left=69.x.x.x<br>
leftsubnet=<a href="http://192.168.55.0/24" target="_blank">192.168.55.0/24</a><br>
leftnexthop=%defaultroute<br>
leftsourceip=192.168.55.254<br>
leftid=@router1<br>
right=2.x.x.x<br>
rightsubnet=<a href="http://192.168.22.0/24" target="_blank">192.168.22.0/24</a><br>
rightid=@router2<br>
keyingtries=%forever<br>
forceencaps=yes<br>
nat_keepalive=yes<br>
dpddelay=30<br>
dpdtimeout=120<br>
dpdaction=restart_by_peer<br>
authby=secret<br>
<br>
conn routers-13<br>
left=69.x.x.x<br>
leftsubnet=<a href="http://192.168.55.0/24" target="_blank">192.168.55.0/24</a><br>
leftnexthop=%defaultroute<br>
leftsourceip=192.168.55.254<br>
leftid=@router1<br>
right=2.x.x.x<br>
rightsubnet=<a href="http://192.168.33.0/24" target="_blank">192.168.33.0/24</a><br>
rightid=@router3<br>
keyingtries=%forever<br>
forceencaps=yes<br>
nat_keepalive=yes<br>
dpddelay=30<br>
dpdtimeout=120<br>
dpdaction=restart_by_peer<br>
authby=secret <br>
</blockquote>
<br></div></div>
This configuration might work easier with aggrmode=yes or ikev2=propose.<br>
Then the rightid is sent in the very first packet.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><br>Will give ikev2 a try and failing that aggrmode (would prefer to avoid if possible).<br></div>
<div class="gmail_quote"><div><br>Many thanks,<br><br>Mike<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<br>
Paul<br>
</font></span></blockquote></div><br></div></div>