<div dir="ltr">Klaus,<div><br></div><div style>You're welcome. </div><div style><br></div><div style>I think AH is only needed if you intend to support that mode. ESP should be good enough for the case you described.</div>
<div style><br></div><div style>As to NAT-T, yes, if both sides play well -- which seems to be the case in your case -- use it alleviates the firewall issues you might otherwise face.</div><div style><br></div><div style>
Thanks,</div><div style>Bharath Kumar </div><div style><br></div><div style><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 28, 2012 at 11:11 AM, Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</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"><br>
<br>
On <a href="tel:28.12.2012%2016" value="+12812201216" target="_blank">28.12.2012 16</a>:34, Bharath Kumar wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Klaus,<br>
<br>
The firewall on either end could be blocking ESP traffic (IP Protocol =<br>
50) and that's where forcing NAT-T would help.<br>
</blockquote>
<br></div>
Indeed, I was blocking ESP on the server side. I allowed now ESP and it works fine now.<br>
<br>
Btw: do I also have to allow AH (ip proto 51)? If I understand correctly, IPsec tunnel mode only requires ESP.<div class="im"><br>
<br>
> Have you tried setting<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this in ipsec.conf?<br>
forceencaps=true<br>
</blockquote>
<br></div>
This also helped.<br>
<br>
I think I will stay with "force NAT traversal" to avoid problems with ESP blocking firewalls on the client side.<br>
<br>
<br>
Thanks for the fast response,<br>
Klaus<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
The traffic in the log file seems to be for Dead Peer Detection.<br>
<br>
Thanks,<br>
Bharath Kumar<br>
<br>
On Friday, December 28, 2012, Klaus Darilion wrote:<br>
<br>
Hi!<br>
<br>
I have setup strongSwan 5.0.1 with certificate authentication. The<br>
tunnel creation works fine, and if the iPhone is behind NAT,<br>
strongSwan detects the NAT, uses port 4500 and everything works fine.<br>
<br>
But if the iPhone is not behind NAT, the tunnel creation works fine,<br>
but then, if I want to surf on the iPhone it does not work. Attached<br>
is the output of "tail -f /var/log/syslog|grep charon" multiplexed<br>
with "tcpdump -i any -n port 500 or 4500 or host 192.168.102.2":<br>
<br>
There is some traffic after the tunnel is created, but what kind of<br>
traffic is this? "real" traffic or some "keep alive" traffic?<br>
<br>
Any ideas why it does not work when the client uses a public IP address?<br>
<br>
Is it possible to force "NAT" behavior also if clients are not<br>
behind NAT?<br>
<br>
Any hints are appreciated.<br>
<br>
Thanks<br>
Klaus<br>
<br>
<br>
# ipsec.conf - strongSwan IPsec configuration file<br></div>
##############################<u></u>__####################<div class="im"><br>
config setup<br>
charondebug=all<br>
<br>
conn RoadWarrior-CiscoIPsec-klaus<br>
type=tunnel<br>
dpdaction=clear<br>
dpddelay=60<br>
dpdtimeout=60<br>
keyexchange=ikev1<br>
authby=xauthrsasig<br>
xauth=server<br>
left=%defaultroute<br></div>
leftsubnet=<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <<a href="http://0.0.0.0/0" target="_blank">http://0.0.0.0/0</a>><div class="im"><br>
leftfirewall=yes<br>
leftcert=serverCert.pem<br>
right=%any<br>
rightsourceip=192.168.102.2<br>
rightcert=clientCert.pem<br>
auto=add<br>
<br>
<br>
# strongswan.conf - strongSwan configuration file<br></div>
##############################<u></u>__###################<div class="im"><br>
charon {<br>
threads = 16<br>
dns1=192.168.99.1<br>
}<br>
<br>
<br>
</div></blockquote>
</blockquote></div><br></div></div>