On 11/26/06, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:<br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>From man ipsec.conf:<br><br> leftsourceip<br> the
IP address for this host to use when
transmitting a packet<br> to
the other side of this link. Relevant only locally, the other<br> end
need not agree. This option
is used to make the gateway<br> itself use
its internal IP, which is part of the leftsubnet, to<br> communicate
to the rightsubnet or right. Otherwise, it will use<br> its nearest IP address, which
is its public IP address. This<br> option
is mostly used when
defining subnet-subnet connections,<br> so that the gateways
can talk to each other and the subnet at<br> the
other end, without the need to build additional host-subnet,<br> subnet-host and host-host tunnels.</blockquote><div><br>
Thanks for the quote! I searched, but leftsourceip is not
documented in the 2.4.4 man page. Do you know in which release it
was implemented?<br>
So if the VPN gateway has internal IP <a href="http://10.0.0.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.1</a> and is "left", setting
"leftsourceip=<a href="http://10.0.0.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.1</a>" should address the issue. Indeed after
careful rebuilding (--down on both sides first), tracepath gets through:<br>
<div style="margin-left: 40px;">vpn$ tracepath -n <a href="http://192.168.2.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.2.2</a><br>
1?: [LOCALHOST] pmtu 1448<br>
1: <a href="http://10.0.0.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.1</a> 0.057ms pmtu 1418<br>
1: <a href="http://192.168.2.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.2.2</a> 35.004ms reached<br>
Resume: pmtu 1418 hops 1 back 1<br>
</div>
(I had to stop iptables on <a href="http://192.168.2.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.2.2</a> -- gotta sort this out.)<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Your gateway's public ip is not covered in the "subnet-subnet" tunnel, so it
<br>will not get encrypted with IPsec. On top of that, because there is a<br>connection between the two gateways, they will refuse to communicate in the<br>clear, so your packet gets dropped. This is the easiest fix, and makes sure
<br>all your communicatin between subnets and gateways happens encrypted.</blockquote><div><br>
Cool, I keep trying that. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Adding SNAT in the mix makes things a bit more complex. Ensure to operate
<br>the SNAT on an interface before it hits the IPsec server, so that the<br>two don't bite. (or try the ipsec+snat from 2.6.17+ but someone else should<br>write a good description on how to do that, I've never done it myself since
<br>I mostly use klips)<br><br>Paul<br></blockquote></div><br>
Yes, the connection vpn...lithium is avoiding the SNAT to first make sure everything else (particularly routing) works well.<br>
<br>
Thanks again for all your help!<br>
/Christian<br>