<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
well , my suggestion is adding a new record to you route table to
point out where will those ipsec packet go for the next hop .<br>
all you unknow ip address will exit from interface eth1 using
primary address as source.<br>
from the exhibit , <br>
the command should look like this:<br>
<font color="#ff0000">ip route add to xxx.xxx.xxx.21/32 dev eth1 src
xxx.xxx.xxx.92<br>
<br>
</font>
<div class="moz-cite-prefix">On 04/10/2015 05:01 PM, Lennart Regner
wrote:<br>
</div>
<blockquote
cite="mid:5c31e00d87ac41e28a2a05b5706934ba@Fseprod.fse.wan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Can you use leftsourceip/rightsourceip to tell openswan which IP to use for that conn?
</pre>
</blockquote>
<pre wrap="">
I already tried that, but it changes nothing I'm afraid.
But I observed that even pings sent to the IP leave the server with the wrong source IP, even if I add -I eth1:ipsec...
On Friday, April 10, 2015 03:05:43 AM Lennart Regner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi there,
I'm running a Debian 7.8 openswan 1:2.6.37-3+deb7u1 server with one
external interface, but many different aliases : inet
xxx.xxx.xxx.94/24 brd xxx.xxx.xxx.255 scope global eth1 inet
xxx.xxx.xxx.93/29 brd xxx.xxx.xxx.95 scope global eth1:ovpn inet
xxx.xxx.xxx.35/27 brd xxx.xxx.xxx.63 scope global eth1:mail1 inet
xxx.xxx.xxx.75/29 brd xxx.xxx.xxx.79 scope global eth1:mail2 inet
xxx.xxx.xxx.10/27 brd xxx.xxx.xxx.31 scope global eth1:web1 inet
xxx.xxx.xxx.82/29 brd xxx.xxx.xxx.87 scope global eth1:ipsec2 inet
xxx.xxx.xxx.36/27 brd xxx.xxx.xxx.63 scope global secondary eth1:web2
inet xxx.xxx.xxx.76/29 brd xxx.xxx.xxx.79 scope global secondary
eth1:web3 inet xxx.xxx.xxx.3/27 brd xxx.xxx.xxx.31 scope global
secondary eth1:gate1 inet xxx.xxx.xxx.34/27 brd xxx.xxx.xxx.63 scope
global secondary eth1:gate2 inet xxx.xxx.xxx.5/27 brd xxx.xxx.xxx.31
scope global secondary eth1:mail inet xxx.xxx.xxx.92/29 brd
xxx.xxx.xxx.95 scope global secondary eth1:ipsec My "main"-connections
use xxx.xxx.xxx.94, but only one has to use xxx.xxx.xxx.92. If at my
server I start up the connection using .92, all packets exit the
interface with the .94 IP, of course getting NO_PROPOSAL_CHOSEN
msgid=00000000 at phase 1. I also found, that all my other IPSec
servers (creating tunnels to .94) sometimes receive ESP packets from
.92, despite there being not a single connection using this IP to
them. If the other side initiates the connection to .92 the server
responds with the correct IP and the tunnel is established. Here is an
excerpt from my ipsec.conf: uniqueids=yes
nhelpers=0
interfaces="ipsec0=eth1"
conn site2site
authby=secret
right=xxx.xxx.xxx.92
rightsubnet=192.168.0.0/24
rightnexthop=xxx.xxx.xxx.91
left=xxx.xxx.xxx.21
leftid="xxx.xxx.xxx.21"
ikelifetime=480m
keylife=3600s
rekeymargin=5m
keyingtries=0
auto=start
ike=3des-sha1;modp1024
esp=3des-sha1;modp1024
conn site2site-1
leftsubnet=172.16.0.0/12
also=site2site
conn site2site-2
leftsubnet=10.182.0.0/15
also=site2site
I tried adding an iptables rule to SNAT the packets src: .94 dst: .21
to source .92, but to no avail, they keep leaving from the wrong interface:
iptables -t nat -A POSTROUTING -s xxx.xxx.xxx.94 -d xxx.xxx.xxx.21 -j
SNAT --to-source xxx.xxx.xxx.92 Anyone got some better idea or want to
point me in the right direction here?
</pre>
</blockquote>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a>
Micropayments: <a class="moz-txt-link-freetext" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a>
Building and Integrating Virtual Private Networks with Openswan:
<a class="moz-txt-link-freetext" 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>
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a>
Micropayments: <a class="moz-txt-link-freetext" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a>
Building and Integrating Virtual Private Networks with Openswan:
<a class="moz-txt-link-freetext" 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>
<br>
</body>
</html>