<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Times New Roman, Times, serif">Thanks a lot for your help.</font><br>
<br>
Paul Wouters wrote:
<blockquote
cite="mid:alpine.LFD.1.10.0811052213000.1776@newtla.xelerance.com"
type="cite">On Wed, 5 Nov 2008, James Northcott / Chief Systems wrote:
<br>
<br>
<blockquote type="cite">I'm having trouble getting locally-generated
traffic to pass through the
<br>
IPSEC tunnel.
<br>
</blockquote>
<br>
Add the appropriate leftsourceip= and rightsourceip= options to the
conn.
<br>
</blockquote>
These options didn't change anything for me. I actually didn't know
they even existed, though - they are not documented in the man page for
ipsec.conf.<br>
<blockquote
cite="mid:alpine.LFD.1.10.0811052213000.1776@newtla.xelerance.com"
type="cite"><br>
<blockquote type="cite">I'm not sure why the first tcpdump command
doesn't show packets from 0.10
<br>
to 3.102, but things work when this is the case.
<br>
</blockquote>
<br>
Linux kernel design issue with NETKEY.
<br>
</blockquote>
I am almost convinced to drop NETKEY and go with KLIPS - it seems a
better design to me to make the ipsec interfaces explicit.<br>
<br>
The magic incantation that worked for me was:<br>
<br>
iptables -t nat -I POSTROUTING 1 -d 192.168.0.0/16 -j SNAT --to
192.168.0.10<br>
<br>
<br>
This rule rewrites the source address of all packets destined for the
secure tunnels to the local IP of the OpenSWAN machine. This seems to
force the packets through the tunnel. I'm still not sure why Asterisk
wasn't choosing the correct source IP in the first place, and I think
this rule may be too broad, but it hasn't broken anything yet, and my
tunnels all work again.<br>
<br>
Thanks again for your help.<br>
</body>
</html>