<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style>
<!--
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
@font-face
{font-family:Consolas}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black}
span.HTMLPreformattedChar
{font-family:Consolas;
color:black}
span.BalloonTextChar
{font-family:"Tahoma","sans-serif";
color:black}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{margin-right:0in;
margin-left:0in;
font-size:10.0pt;
font-family:"Times New Roman","serif";
color:black}
span.htmlpreformattedchar0
{font-family:Consolas;
color:black}
span.balloontextchar0
{font-family:"Tahoma","sans-serif";
color:black}
span.htmlpreformattedchar00
{font-family:Consolas;
color:black}
span.emailstyle19
{font-family:"Calibri","sans-serif";
color:#1F497D}
span.balloontextchar00
{font-family:"Tahoma","sans-serif";
color:black}
span.emailstyle26
{font-family:"Calibri","sans-serif";
color:#1F497D}
span.moz-smiley-s2
{}
span.EmailStyle29
{font-family:"Calibri","sans-serif";
color:#1F497D}
.MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
{}
-->
</style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">I don’t really need it for anything and I can always unblock it if I do, but the more pressing point is ANY traffic will fail to pass in the current state
unless I permit it through the AWS firewall. My understanding of how this should work is I should only need to allow udp500, udp4500 and maybe one or two other ports into openswan from the Internet, but that’s not the case currently. There has to be a misconfiguration
somewhere, but I just can’t seem to find it.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext">From:</span></b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext"> Nick Howitt [mailto:n1ck.h0w1tt@gmail.com]
<br>
<b>Sent:</b> Wednesday, November 20, 2013 5:08 PM<br>
<b>To:</b> Fred Weston; neal.p.murphy@alum.wpi.edu; users@openswan.org<br>
<b>Subject:</b> Re: [Openswan Users] Firewall rules for openswan behind NAT</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Ultimately, why bother blocking ICMP?</p>
<div>
<p class="MsoNormal">On 20/11/2013 22:05, Fred Weston wrote:</p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Yes, exactly that. I am confused for the same reason. It also applies to other traffic types i.e. smb, rdp, etc. If I don’t permit it into openswan then
it doesn’t work and that makes absolutely no sense to me.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext">From:</span></b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext"> Nick Howitt [<a href="mailto:n1ck.h0w1tt@gmail.com">mailto:n1ck.h0w1tt@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, November 20, 2013 5:03 PM<br>
<b>To:</b> Fred Weston; <a href="mailto:neal.p.murphy@alum.wpi.edu">neal.p.murphy@alum.wpi.edu</a>;
<a href="mailto:users@openswan.org">users@openswan.org</a><br>
<b>Subject:</b> Re: [Openswan Users] Firewall rules for openswan behind NAT</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Both traceroutes are going through the tunnel (no WAN IP hops). I don't understand why blocking ICMP at the gateway blocks these. Totally confused.
<span class="moz-smiley-s2">:-( </span>What about other traffic?</p>
<div>
<p class="MsoNormal">On 20/11/2013 21:49, Fred Weston wrote:</p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Sorry, I didn’t see your request for traceroutes.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Here are traceroutes from a host behind openswan in site 1 to a host behind openswan in site 2 and vice versa. They look like I expect them to work, however
they only work when I allow ICMP into openswan from the Internet.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Tracing route to aws-useast-sp1.lpgaoffice.local [10.0.0.146]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">over a maximum of 30 hops:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 1 <1 ms <1 ms <1 ms aws-uswest-nat.lpgaoffice.local [10.1.0.67]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 2 85 ms 84 ms 99 ms aws-useast-nat.lpgaoffice.local [10.0.0.82]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 3 84 ms 84 ms 84 ms AWS-USEAST-SP1 [10.0.0.146]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Trace complete.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Tracing route to aws-uswest-sp1.lpgaoffice.local [10.1.0.38]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">over a maximum of 30 hops:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 1 1 ms <1 ms <1 ms aws-useast-nat.lpgaoffice.local [10.0.0.82]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 2 84 ms 84 ms 84 ms aws-uswest-nat.lpgaoffice.local [10.1.0.67]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> 3 84 ms 84 ms 84 ms sprestore.lpga.com [10.1.0.38]</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Trace complete.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext">From:</span></b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"; color:windowtext">
<a href="mailto:users-bounces@lists.openswan.org">users-bounces@lists.openswan.org</a> [<a href="mailto:users-bounces@lists.openswan.org">mailto:users-bounces@lists.openswan.org</a>]
<b>On Behalf Of </b>Nick Howitt<br>
<b>Sent:</b> Wednesday, November 20, 2013 4:20 PM<br>
<b>To:</b> <a href="mailto:neal.p.murphy@alum.wpi.edu">neal.p.murphy@alum.wpi.edu</a>;
<a href="mailto:users@openswan.org">users@openswan.org</a><br>
<b>Subject:</b> Re: [Openswan Users] Firewall rules for openswan behind NAT</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12.0pt">As I said before, tunnel status is almost impossible to obtain.<br>
<br>
You can see the encryption being used in /var/log/secure. You are using AES128, modp2048 and SHA1 which is OK<br>
<br>
Your conns look absolutely fine and your tunnel is up. You have not explicitly defined the encryption so it has chosen a reasonable one (similar in strength to 3des but uses 1/3 cpu cycles). You don't need virtual_private with your set up and you don't need
protocols 50 and 51 through the firewall as ipsec with NAT-T is working.<br>
<br>
Neal's summary was pretty much spot on.<br>
<br>
Can you confirm you don't have a blank line after conn ...... and before type=tunnel in your conf files?<br>
<br>
Can you do the traceroutes/tracerts I asked for?<br>
<br>
Nick</p>
<div>
<p class="MsoNormal">On 20/11/2013 20:07, Neal Murphy wrote:</p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<pre>On Wednesday, November 20, 2013 02:48:11 PM Fred Weston wrote:</pre>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<pre>All of this makes sense to me and I believe I have crossed everything you</pre>
<pre>listed off my troubleshooting list.</pre>
<pre> </pre>
<pre>Is there a way to see the status of the tunnel and what crypto is being</pre>
<pre>used to transmit packets between LANs?</pre>
</blockquote>
<pre> </pre>
<pre>If openswan is running on GNU/Linux and you are using KLIPS,</pre>
<pre> cd /proc/net</pre>
<pre> for i in ipsec_*; do</pre>
<pre> echo $i</pre>
<pre> sed -e 's/^/ /' $i</pre>
<pre> done</pre>
<pre>And peruse /proc/net/ipsec/.</pre>
<pre> </pre>
<pre>To obtain a deluge of info, '/usr/sbin/ipsec barf'.</pre>
<pre> </pre>
<pre> </pre>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<pre> </pre>
<pre>-----Original Message-----</pre>
<pre>From: <a href="mailto:users-bounces@lists.openswan.org">users-bounces@lists.openswan.org</a></pre>
<pre>[<a href="mailto:users-bounces@lists.openswan.org">mailto:users-bounces@lists.openswan.org</a>] On Behalf Of Neal Murphy Sent:</pre>
<pre>Wednesday, November 20, 2013 2:12 PM</pre>
<pre>To: <a href="mailto:users@openswan.org">users@openswan.org</a></pre>
<pre>Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre>You've addressed some or most of what's in the following bird's-eye view;</pre>
<pre>it shouldn't hurt to review in case you've overlooked something.</pre>
<pre> </pre>
<pre>You need to forward UDP ports 500 and 4500 on each firewall to the local</pre>
<pre>openswan box (limit it to coming from the remote IP/openswan box for added</pre>
<pre>security), and allow UDP ports 500 and 4500 out from the local openswan</pre>
<pre>box (preferably limit it to going to the remote openswan box for added</pre>
<pre>security). This will allow either end to start the VPN. Each firewall</pre>
<pre>should drop packets destined for the remote LAN(s) since they don't know</pre>
<pre>how to reach them. Logging them with a specific prefix would make it easy</pre>
<pre>to discover malconfigured nodes.</pre>
<pre> </pre>
<pre>I don't believe protocols 50 and 51 are used when NAT-T is used.</pre>
<pre> </pre>
<pre>Each internal node must have an explicit route to the remote LAN via the</pre>
<pre>local openswan box's IP.</pre>
<pre> </pre>
<pre>Each openswan box needs route(s) to the local internal LAN(s) and a default</pre>
<pre>route via the local firewall's internal IP address. Openswan takes care of</pre>
<pre>adding/removing routes to remote LANs when it brings VPNs up and down.</pre>
<pre> </pre>
<pre>Do you have a 'config setup' in each ipsec.conf, possibly similar to:</pre>
<pre> protostack=klips # or netkey or mast</pre>
<pre> interfaces=%defaultroute</pre>
<pre> klipsdebug=none</pre>
<pre> plutodebug=none</pre>
<pre> plutowait=no</pre>
<pre> uniqueids=yes</pre>
<pre> nat_traversal=yes</pre>
<pre>You might need a virtual_private declaration describing your internal LANs,</pre>
<pre>but probably not, since you aren't using a road warrior setup.</pre>
<pre> </pre>
<pre>In each conn spec, you may need to specify ike= and esp=; that is, tell</pre>
<pre>openswan which encrytpion to use. I don't know what happens if you don't</pre>
<pre>specify any encryption methods. (Does openswan then transmit in the</pre>
<pre>clear?)</pre>
<pre> </pre>
<pre>I haven't played with NAT Traversal lately; I forget how to configure a</pre>
<pre>conn to make NAT-T work.</pre>
<pre> </pre>
<pre>N</pre>
<pre> </pre>
<pre>On Wednesday, November 20, 2013 12:28:35 PM Fred Weston wrote:</pre>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<pre>I cannot ping LAN-LAN without the tunnel.</pre>
<pre> </pre>
<pre>In site A I have 10.0.0.0/16 and in site B I have 10.1.0.0/16. In</pre>
<pre>each site the routing table has an entry for the opposite site’s IP</pre>
<pre>space which is pointed at the local openswan box.</pre>
<pre> </pre>
<pre>I think we are confusing firewall and tunnel terminology. The</pre>
<pre>firewall I am speaking of is builtin to AWS and controls ingress and</pre>
<pre>egress traffic from the openswan boxes. It is something that is part</pre>
<pre>of the AWS network stack and the only thing I can do to it is change its</pre>
<pre>ruleset.</pre>
<pre> </pre>
<pre>The traffic between sites is traversing the openswan tunnel, however</pre>
<pre>when it’s doing so it isn’t being encrypted, so for instance when I</pre>
<pre>send RDP traffic across the tunnel, the AWS firewall sees RDP traffic</pre>
<pre>and doesn’t let it through. If the tunnel were encrypting traffic,</pre>
<pre>all the AWS firewall should see is UDP traffic coming into port 500</pre>
<pre>and it should have no idea what that traffic is, but it’ll allow it</pre>
<pre>because I’ve told it to permit udp/500 inbound.</pre>
<pre> </pre>
<pre>In the diagram below I’ve notated where the AWS firewall at each site</pre>
<pre>is inspecting traffic. The issue is that the traffic coming across</pre>
<pre>the tunnel is in the clear.</pre>
<pre> </pre>
<pre>[<a href="cid:image002.jpg@01CEE5EC.06F0A5C0">cid:image002.jpg@01CEE5EC.06F0A5C0</a>]</pre>
<pre> </pre>
<pre>From: Nick Howitt [<a href="mailto:n1ck.h0w1tt@gmail.com">mailto:n1ck.h0w1tt@gmail.com</a>]</pre>
<pre>Sent: Wednesday, November 20, 2013 3:36 AM</pre>
<pre>To: Fred Weston</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a></pre>
<pre>Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre> </pre>
<pre>I am curious that your are even pinging LAN-LAN outside the tunnel.</pre>
<pre>You have private subnets and the internet would not know where to find</pre>
<pre>a 10.x.y.z address. Can you do a tracert/traceroute end to end with</pre>
<pre>and without the firewall?</pre>
<pre> </pre>
<pre>On your gateways to you have routes set up to your far LAN's via your</pre>
<pre>Openswan devices?</pre>
<pre> </pre>
<pre>Can you ping from 10.0.0.82 to 10.1.0.67 or vice-versa with the</pre>
<pre>firewall up and down?</pre>
<pre> </pre>
<pre>On 2013-11-19 17:14, Fred Weston wrote:</pre>
<pre>The tunnel comes up either way but I can't ping unless I permit icmp</pre>
<pre>from the Internet into openswan. I'm pinging from another device</pre>
<pre>behind openswan.</pre>
<pre> </pre>
<pre>Thanks ,</pre>
<pre>FW</pre>
<pre> </pre>
<pre>On Nov 19, 2013, at 11:40 AM, "Nick Howitt"</pre>
<pre><<a href="mailto:n1ck.h0w1tt@gmail.com">n1ck.h0w1tt@gmail.com</a><a href="mailto:n1ck.h0w1tt@gmail.com"><mailto:n1ck.h0w1tt@gmail.com></a>> wrote:</pre>
<pre> </pre>
<pre>OK that shows the tunnel is up. Is that with or without the firewall</pre>
<pre>(and btw it is using NAT-T so you should not need protocols 50 and 51</pre>
<pre>through your firewall).</pre>
<pre> </pre>
<pre>When you are pinging end to end, is that from the openswan device or</pre>
<pre>from another LAN device?</pre>
<pre> </pre>
<pre>On 2013-11-19 14:03, Fred Weston wrote:</pre>
<pre>This is what I see in the log; it looks like it’s encrypting traffic</pre>
<pre>but that doesn’t seem to be the case based upon the behavior I’m</pre>
<pre>seeing. If it is encrypting then the firewall in front of openswan</pre>
<pre>should have no effect on the traffic I can pass over the tunnel as</pre>
<pre>long as the tunnel is up.</pre>
<pre> </pre>
<pre>Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1:</pre>
<pre>NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed</pre>
<pre>Nov</pre>
<pre>19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1: transition</pre>
<pre>from state STATE_MAIN_I2 to state STATE_MAIN_I3 Nov 19 14:00:55</pre>
<pre>ip-10-0-0-82</pre>
<pre>pluto[12517]: "vpc1-to-vpc2" #1: STATE_MAIN_I3: sent MI3, expecting</pre>
<pre>MR3 Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1:</pre>
<pre>received Vendor ID payload [CAN-IKEv2] Nov 19 14:00:55 ip-10-0-0-82</pre>
<pre>pluto[12517]: "vpc1-to-vpc2" #1: Main mode peer ID is ID_IPV4_ADDR:</pre>
<pre>'50.18.211.121' Nov</pre>
<pre>19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1: transition</pre>
<pre>from state STATE_MAIN_I3 to state STATE_MAIN_I4 Nov 19 14:00:55</pre>
<pre>ip-10-0-0-82</pre>
<pre>pluto[12517]: "vpc1-to-vpc2" #1: STATE_MAIN_I4: ISAKMP SA established</pre>
<pre>{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha</pre>
<pre>group=modp2048} Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]:</pre>
<pre>"vpc1-to-vpc2" #2: initiating Quick Mode</pre>
<pre>PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1</pre>
<pre>msgid:463435ec proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048} Nov</pre>
<pre>19</pre>
<pre>14:00:56 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #2: transition from</pre>
<pre>state STATE_QUICK_I1 to state STATE_QUICK_I2 Nov 19 14:00:56</pre>
<pre>ip-10-0-0-82</pre>
<pre>pluto[12517]: "vpc1-to-vpc2" #2: STATE_QUICK_I2: sent QI2, IPsec SA</pre>
<pre>established tunnel mode {ESP=>0x54dd12fe <0x2bb3e074</pre>
<pre>xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=50.18.211.121:4500 DPD=none}</pre>
<pre> </pre>
<pre>From: Nick Howitt [<a href="mailto:n1ck.h0w1tt@gmail.com">mailto:n1ck.h0w1tt@gmail.com</a>]</pre>
<pre>Sent: Tuesday, November 19, 2013 8:21 AM</pre>
<pre>To: Fred Weston</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a><a href="mailto:users@lists.openswan.org"><mailto:users@lists.openswan.org></a></pre>
<pre>Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre> </pre>
<pre>What are you getting in /var/log/secure - just the bit where the</pre>
<pre>tunnel is negotiating, not the bit where ipsec loads?</pre>
<pre> </pre>
<pre>Also what do you have in the "config setup" sections of your conf files?</pre>
<pre> </pre>
<pre>On 2013-11-19 13:14, Fred Weston wrote:</pre>
<pre>So here’s something interesting…this morning just for the heck of it,</pre>
<pre>I added ICMP to the permit list and that immediately got ping working.</pre>
<pre> </pre>
<pre>Since the tunnel shouldn’t require ICMP, that got me thinking that the</pre>
<pre>traffic isn’t actually being encrypted. I verified that by trying to</pre>
<pre>remote desktop to a host on the far side of the tunnel. It didn’t</pre>
<pre>work when I have the firewall rules set to only allow the few</pre>
<pre>ports/protocols the tunnel should need, but as soon as I changed the</pre>
<pre>ruleset to permit all traffic RDP worked, so it seems the problem is</pre>
<pre>actually that the tunnel isn’t encrypting the traffic.</pre>
<pre> </pre>
<pre>I’m not quite sure why this is.</pre>
<pre> </pre>
<pre>Here are the configs from each side, can someone comment as to what I</pre>
<pre>need to add to get the traffic to be encrypted?</pre>
<pre> </pre>
<pre>conn vpc1-to-vpc2</pre>
<pre> </pre>
<pre> type=tunnel</pre>
<pre> authby=secret</pre>
<pre> left=%defaultroute</pre>
<pre> leftid=107.21.17.86</pre>
<pre> leftnexthop=%defaultroute</pre>
<pre> leftsubnet=10.0.0.0/16</pre>
<pre> leftsourceip=10.0.0.82</pre>
<pre> right=50.18.211.121</pre>
<pre> rightsubnet=10.1.0.0/16</pre>
<pre> pfs=yes</pre>
<pre> auto=start</pre>
<pre> phase2=esp</pre>
<pre> </pre>
<pre>conn vpc2-to-vpc1</pre>
<pre> </pre>
<pre> type=tunnel</pre>
<pre> authby=secret</pre>
<pre> left=%defaultroute</pre>
<pre> leftid=50.18.211.121</pre>
<pre> leftnexthop=%defaultroute</pre>
<pre> leftsubnet=10.1.0.0/16</pre>
<pre> leftsourceip=10.1.0.67</pre>
<pre> right=107.21.17.86</pre>
<pre> rightsubnet=10.0.0.0/16</pre>
<pre> pfs=yes</pre>
<pre> auto=start</pre>
<pre> phase2=esp</pre>
<pre> </pre>
<pre>From: Nick Howitt [<a href="mailto:n1ck.h0w1tt@gmail.com">mailto:n1ck.h0w1tt@gmail.com</a>]</pre>
<pre>Sent: Tuesday, November 19, 2013 5:19 AM</pre>
<pre>To: Fred Weston</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a><a href="mailto:users@lists.openswan.org"><mailto:users@lists.openswan.org></a></pre>
<pre>Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre> </pre>
<pre>Yes, I was picturing firewalling in the hosts.</pre>
<pre> </pre>
<pre>Have a look in the logs and see if Openswan is connecting with or</pre>
<pre>without NAT-T when your firewall is not up. Then, with your</pre>
<pre>firewalling, try forceencaps=yes in the conn and nat_traversal=yes in</pre>
<pre>config setup.</pre>
<pre> </pre>
<pre>For minor tunnel info I use "service ipsec status", but it depends on</pre>
<pre>your distro and the information is almost useless. You can also have a</pre>
<pre>look at "ip xfrm" and "ip route".</pre>
<pre> </pre>
<pre>Nick</pre>
<pre> </pre>
<pre>On 2013-11-19 10:03, Fred Weston wrote:</pre>
<pre>I think you’re picturing the firewalling taking place on the openswan</pre>
<pre>hosts, which isn’t the case. There isn’t a firewall on either</pre>
<pre>openswan box (other than any standard firewall that may be enabled by</pre>
<pre>default). The firewall rules I am manipulating are in the network / NAT</pre>
<pre>device in front of openswan. Since the tunnel works when I permit all</pre>
<pre>traffic to openswan, that would seem to discount the possibility of</pre>
<pre>any firewall issues on the hosts themselves.</pre>
<pre> </pre>
<pre>I’ll take a look at the logs to see if they show anything interesting.</pre>
<pre>Is there a utility that will show tunnel status?</pre>
<pre> </pre>
<pre>From: Nick Howitt [<a href="mailto:n1ck.h0w1tt@gmail.com">mailto:n1ck.h0w1tt@gmail.com</a>]</pre>
<pre>Sent: Tuesday, November 19, 2013 3:44 AM</pre>
<pre>To: Fred Weston</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a><a href="mailto:users@lists.openswan.org"><mailto:users@lists.openswan.org></a></pre>
<pre>Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre> </pre>
<pre>For your rules, I was hoping for something like the output to</pre>
<pre>"iptables -L -n -v" and "iptables -t nat -L -n -v" rather than a</pre>
<pre>description of the rules.</pre>
<pre> </pre>
<pre>Forceencaps is unlikely but can be useful</pre>
<pre> </pre>
<pre>Openswan/ipsec logs are typically found in /var/log/secure depending</pre>
<pre>on your system. If you have dpd enabled you should see constant tunnel</pre>
<pre>renegotiation if the tunnel has gone down. You'll see nothing odd if</pre>
<pre>the tunnel is up but no traffic is passing. When the tunnel is up you</pre>
<pre>should see in the logs something like "IPSec SA Established".</pre>
<pre>Available status information is not particulrly helpful.</pre>
<pre> </pre>
<pre>Can you also try adding a firewall rule something like:</pre>
<pre> </pre>
<pre>iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j</pre>
<pre>ACCEPT</pre>
<pre> </pre>
<pre>Either that or somthing in the post routing chain which allows traffic</pre>
<pre>between the local and remote subnets, but this rule is more flexible</pre>
<pre>as you don't need to specify the subnets.</pre>
<pre> </pre>
<pre>Nick</pre>
<pre> </pre>
<pre>On 2013-11-18 23:28, Fred Weston wrote:</pre>
<pre> </pre>
<pre>From:</pre>
<pre><a href="mailto:users-bounces@lists.openswan.org">users-bounces@lists.openswan.org</a><a href="mailto:users-bounces@lists.openswan.org"><mailto:users-bounces@lists.openswan.o</a></pre>
<pre><span class="MsoHyperlink"><a href="mailto:users-bounces@lists.openswan.org">rg></a></span> [<a href="mailto:users-bounces@lists.openswan.org">mailto:users-bounces@lists.openswan.org</a>] On Behalf Of Nick Howitt</pre>
<pre> </pre>
<pre>Can you post the exact rules you are using?</pre>
<pre> </pre>
<pre>I included those in my original message.</pre>
<pre>*:* > UDP 500</pre>
<pre>*:* > UDP 4500</pre>
<pre>* > IP Protocol 50</pre>
<pre>* > IP Protocol 51</pre>
<pre> </pre>
<pre>Also have you tried forcing encapsulation with forceencaps=yes in your</pre>
<pre>conns?</pre>
<pre> </pre>
<pre>No, I haven’t tried that.</pre>
<pre> </pre>
<pre>When you say "things stop working" does the tunnel come down, or does</pre>
<pre>traffic just fail to pass?</pre>
<pre> </pre>
<pre>I’m not sure how to tell the difference, my test methodology was to</pre>
<pre>ping a host on the far side of the tunnel and when I change the</pre>
<pre>firewall rules from wide open to those above the ping starts timing</pre>
<pre>out. How can I tell what state the tunnel is in?</pre>
<pre> </pre>
<pre>Regards,</pre>
<pre> </pre>
<pre>Nick</pre>
<pre> </pre>
<pre>On 2013-11-17 17:13, Fred Weston wrote:</pre>
<pre>Does anyone else have any suggestions? I would like to implement this</pre>
<pre>in production but I am hesitant to do so when the only way I can get</pre>
<pre>it to work is permit all traffic from the Internet into the openswan</pre>
<pre>boxes.</pre>
<pre> </pre>
<pre>From:</pre>
<pre><a href="mailto:users-bounces@lists.openswan.org">users-bounces@lists.openswan.org</a><a href="mailto:users-bounces@lists.openswan.org"><mailto:users-bounces@lists.openswan.o</a></pre>
<pre><span class="MsoHyperlink"><a href="mailto:users-bounces@lists.openswan.org">rg></a></span> [<a href="mailto:users-bounces@lists.openswan.org">mailto:users-bounces@lists.openswan.org</a>] On Behalf Of Fred Weston</pre>
<pre>Sent:</pre>
<pre>Wednesday, November 13, 2013 11:49 AM</pre>
<pre>To: Leto</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a><a href="mailto:users@lists.openswan.org"><mailto:users@lists.openswan.org></a></pre>
<pre>Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre>Let me clarify – when I reference ports/protocols that I’m allowing</pre>
<pre>inbound, I’m allowing it from the opposite host and not specifying a</pre>
<pre>source port.</pre>
<pre> </pre>
<pre>Thanks,</pre>
<pre>FW</pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre>From: Leto [<a href="mailto:letoams@gmail.com">mailto:letoams@gmail.com</a>]</pre>
<pre>Sent: Wednesday, November 13, 2013 11:27 AM</pre>
<pre>To: Fred Weston</pre>
<pre>Cc: <a href="mailto:users@lists.openswan.org">users@lists.openswan.org</a><a href="mailto:users@lists.openswan.org"><mailto:users@lists.openswan.org></a></pre>
<pre>Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT</pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre>sent from a tiny device</pre>
<pre> </pre>
<pre>On 2013-11-13, at 10:44, Fred Weston</pre>
<pre><<a href="mailto:fred.weston@lpga.com">fred.weston@lpga.com</a><a href="mailto:fred.weston@lpga.com"><mailto:fred.weston@lpga.com></a>> wrote: Hello All,</pre>
<pre> </pre>
<pre>I’m using OpenSwan with AWS to link two private VPC networks in</pre>
<pre>different regions.</pre>
<pre> </pre>
<pre>I’m having trouble getting my firewall ACLs right. Everything works</pre>
<pre>if I permit all traffic to the OpenSwan boxes, however when I try to</pre>
<pre>get more restrictive and permit only the necessary ports things stop</pre>
<pre>working.</pre>
<pre> </pre>
<pre>One side has all traffic permitted inbound for the time being and I’m</pre>
<pre>making ACL changes trying to restrict traffic to certain</pre>
<pre>ports/protocols on the other side.</pre>
<pre> </pre>
<pre>Both endpoints are behind 1:1 NAT. Everything is permitted outbound</pre>
<pre>on both sides.</pre>
<pre> </pre>
<pre>From reading online, I understand that the following ports and</pre>
<pre>protocols should be all I need:</pre>
<pre> </pre>
<pre>UDP 500</pre>
<pre>UDP 4500</pre>
<pre>IP Protocol 50</pre>
<pre>IP Protocol 51</pre>
<pre> </pre>
<pre>I tried the above and had no luck. As soon as I change from</pre>
<pre>permitting all inbound to permitting only the above list the tunnel comes</pre>
<pre>down.</pre>
<pre> </pre>
<pre>You should really allow icmp.</pre>
<pre> </pre>
<pre>Note that you need to accept from a random high port to dest udp 4500,</pre>
<pre>not just 4500 <-> 4500. Same for 500</pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre> </pre>
<pre>I also tried permitting tcp/1721 and tcp/1723 and IP Protocol 47.</pre>
<pre> </pre>
<pre>I am using AWS ‘security groups’ to control filtering and according to</pre>
<pre>the docs (and my observations) security groups are stateful, so I am</pre>
<pre>not sure why this isn’t working.</pre>
<pre> </pre>
<pre>Can anyone offer any suggestions?</pre>
</blockquote>
</blockquote>
<pre>_______________________________________________</pre>
<pre><a href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a></pre>
<pre><a href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a></pre>
<pre>Micropayments: <a href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a></pre>
<pre>Building and Integrating Virtual Private Networks with Openswan:</pre>
<pre><a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a></pre>
</blockquote>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">The information transmitted in this message (including any attachments) is intended only for the use of the individual(s) and/or entity(ies) to which it is addressed and may contain confidential business information which should not be
disclosed. If you are not the intended recipient, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error, please notify the sender and immediately destroy and delete this
email from your system without disseminating it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this message. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the LPGA and/or its affiliates. No employee is authorized
to conclude any binding agreement on behalf of LPGA and/or its affiliates with another party by e-mail. All agreements shall be contained in a separate writing executed by an authorized LPGA signatory. Thank You.
</p>
</blockquote>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">The information transmitted in this message (including any attachments) is intended only for the use of the individual(s) and/or entity(ies) to which it is addressed and may contain confidential business information which should not be
disclosed. If you are not the intended recipient, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error, please notify the sender and immediately destroy and delete this
email from your system without disseminating it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this message. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the LPGA and/or its affiliates. No employee is authorized
to conclude any binding agreement on behalf of LPGA and/or its affiliates with another party by e-mail. All agreements shall be contained in a separate writing executed by an authorized LPGA signatory. Thank You.
</p>
</blockquote>
<p class="MsoNormal"> </p>
</div>
The information transmitted in this message (including any attachments) is intended only for the use of the individual(s) and/or entity(ies) to which it is addressed and may contain confidential business information which should not be disclosed. If you are
not the intended recipient, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error, please notify the sender and immediately destroy and delete this email from your system
without disseminating it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for
any errors or omissions in the contents of this message. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the LPGA and/or its affiliates. No employee is authorized to conclude any binding
agreement on behalf of LPGA and/or its affiliates with another party by e-mail. All agreements shall be contained in a separate writing executed by an authorized LPGA signatory. Thank You.
</body>
</html>