<div dir="ltr">Hi,<div> This is what I have in my ipsec.conf. This is the config that allowed me to go pass phase 2 of ike. I've tried other config like setting nat-traversal on both client and server, but it never did complete phase2.</div>
<div><br></div><div>Client:</div><div><div># basic configuration</div><div>config setup</div><div> # which IPsec stack to use, "netkey" (the default), "klips" or "mast".</div><div> # For MacOSX use "bsd"</div>
<div> protostack=netkey</div><div> #</div><div> # The interfaces= line is only required for the klips/mast stack</div><div> #interfaces="%defaultroute"</div><div> #interfaces="ipsec0=eth0 ipsec1=ppp0"</div>
<div> #</div><div> # If you want to limit listening on a single IP - not required for</div><div> # normal operation</div><div> #listen=127.0.0.1</div><div> #</div><div> # Do not set debug options to debug configuration issues!</div>
<div> #</div><div> # plutodebug / klipsdebug = "all", "none" or a combation from below:</div><div> # "raw crypt parsing emitting control kernel pfkey natt x509 dpd</div><div>
# private".</div>
<div> # Note: "crypt" is not included with "all", as it can show confidential</div><div> # information. It must be specifically specified</div><div> # examples:</div><div> # plutodebug="control parsing"</div>
<div> # plutodebug="all crypt"</div><div> # Again: only enable plutodebug or klipsdebug when asked by a developer</div><div> #plutodebug=none</div><div> #klipsdebug=none</div><div> #</div>
<div> # Normally, pluto logs via syslog. If you want to log to a file,</div><div> # specify below or to disable logging, eg for embedded systems, use</div><div> # the file name /dev/null</div><div> # Note: SElinux policies might prevent pluto writing to a log file at</div>
<div> # an unusual location.</div><div> #plutostderrlog=/var/log/pluto.log</div><div> #</div><div> # Enable core dumps (might require system changes, like ulimit -C)</div><div> # This is required for abrtd to work properly</div>
<div> # Note: SElinux policies might prevent pluto writing the core at</div><div> # unusual locations</div><div> dumpdir=/var/run/pluto/</div><div> #</div><div> # NAT-TRAVERSAL support</div>
<div> # exclude networks used on server side by adding %v4:!a.b.c.0/24</div><div> # It seems that T-Mobile in the US and Rogers/Fido in Canada are</div><div> # using 25/8 as "private" address space on their wireless networks.</div>
<div> # This range has not been announced via BGP (at least upto 2010-12-21)</div><div> nat_traversal=yes</div><div> virtual_private=%v4:<a href="http://20.20.0.0/16,%v4:!10.0.0.0/8" target="_blank">20.20.0.0/16,%v4:!10.0.0.0/8</a></div>
</div><div><div>conn sample-connection-for-illustration</div><div> authby=secret</div><div> auto=start</div><div> type=transport</div><div> left=10.10.0.10</div><div> leftsubnet=<a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a></div>
<div> right=20.20.20.150</div><div> rightsubnet=<a href="http://20.20.0.0/16" target="_blank">20.20.0.0/16</a></div><div> ike=aes256-sha1;modp2048</div><div> phase2=esp</div><div> phase2alg=aes256-sha1;modp2048</div>
</div><div><br></div><div><br></div><div>Server:</div><div><div>config setup</div><div> # which IPsec stack to use, "netkey" (the default), "klips" or "mast".</div><div> # For MacOSX use "bsd"</div>
<div> protostack=netkey</div><div> #</div><div> # The interfaces= line is only required for the klips/mast stack</div><div> #interfaces="%defaultroute"</div><div> #interfaces="ipsec0=eth0 ipsec1=ppp0"</div>
<div> #</div><div> # If you want to limit listening on a single IP - not required for</div><div> # normal operation</div><div> #listen=127.0.0.1</div><div> #</div><div> # Do not set debug options to debug configuration issues!</div>
<div> #</div><div> # plutodebug / klipsdebug = "all", "none" or a combation from below:</div><div> # "raw crypt parsing emitting control kernel pfkey natt x509 dpd</div><div>
# private".</div>
<div> # Note: "crypt" is not included with "all", as it can show confidential</div><div> # information. It must be specifically specified</div><div> # examples:</div><div> # plutodebug="control parsing"</div>
<div> # plutodebug="all crypt"</div><div> # Again: only enable plutodebug or klipsdebug when asked by a developer</div><div> #plutodebug=none</div><div> #klipsdebug=none</div><div> #</div>
<div> # Normally, pluto logs via syslog. If you want to log to a file,</div><div> # specify below or to disable logging, eg for embedded systems, use</div><div> # the file name /dev/null</div><div> # Note: SElinux policies might prevent pluto writing to a log file at</div>
<div> # an unusual location.</div><div> #plutostderrlog=/var/log/pluto.log</div><div> #</div><div> # Enable core dumps (might require system changes, like ulimit -C)</div><div> # This is required for abrtd to work properly</div>
<div> # Note: SElinux policies might prevent pluto writing the core at</div><div> # unusual locations</div><div> dumpdir=/var/run/pluto/</div><div> #</div><div> # NAT-TRAVERSAL support</div>
<div> # exclude networks used on server side by adding %v4:!a.b.c.0/24</div><div> # It seems that T-Mobile in the US and Rogers/Fido in Canada are</div><div> # using 25/8 as "private" address space on their wireless networks.</div>
<div> # This range has not been announced via BGP (at least upto 2010-12-21)</div><div> #nat_traversal=yes</div><div> #virtual_private=%v4:<a href="http://10.10.0.0/16,%v4:!20.20.20.0/24" target="_blank">10.10.0.0/16,%v4:!20.20.20.0/24</a></div>
</div><div><br></div><div><div>conn sample-connection-for-illustration</div><div> authby=secret</div><div> auto=start</div><div> type=transport</div><div> left=20.20.20.150</div><div> leftsubnet=<a href="http://20.20.0.0/16" target="_blank">20.20.0.0/16</a></div>
<div> right=10.10.0.10</div><div> rightsubnet=<a href="http://10.10.0.0/16" target="_blank">10.10.0.0/16</a></div><div> ike=aes256-sha1;modp2048</div><div> phase2=esp</div><div> phase2alg=aes256-sha1;modp2048</div>
</div><div><br></div><div>Thanks,</div><div>Michael </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 12:40 PM, Neal Murphy <span dir="ltr"><<a href="mailto:neal.p.murphy@alum.wpi.edu" target="_blank">neal.p.murphy@alum.wpi.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, October 09, 2013 02:29:06 PM Michael Chan wrote:<br>
> Hi,<br>
> I'm trying to setup a vpn connection from my client to server through a<br>
> NAT router, but I'm not getting the connection up. My topology looks like<br>
> this:<br>
<br>
</div>Generally speaking, both sides need to speak NAT_TRAVERSAL and your firewall<br>
must allow UDP port 4500--and maybe port 500--out.<br>
<br>
During testing, I have forwarded ports 500 and 4500 to an internal host; this<br>
allowed an external host to initiate a VPN with my internal (NATted) host. But<br>
typically (without such port forwards), the NATted host must initiate the VPN<br>
because the remote cannot.<br>
<br>
Post your ipsec.conf if still you have no joy.<br>
<br>
N<br>
_______________________________________________<br>
<a href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a><br>
<a href="https://lists.openswan.org/mailman/listinfo/users" target="_blank">https://lists.openswan.org/mailman/listinfo/users</a><br>
Micropayments: <a href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy" target="_blank">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a><br>
Building and Integrating Virtual Private Networks with Openswan:<br>
<a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155" target="_blank">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a><br>
</blockquote></div><br></div>