[Openswan Users] openswan initiating from wrong IP, but answers with the right one

[MichaelLeung]

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 .
all you unknow ip address will exit from interface eth1 using primary 
address as source.
from the exhibit ,
the command should look like this:
ip route add to xxx.xxx.xxx.21/32 dev eth1 src xxx.xxx.xxx.92

On 04/10/2015 05:01 PM, Lennart Regner wrote:
>> Can you use leftsourceip/rightsourceip to tell openswan which IP to use for that conn?
> 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:
>> 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?
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150412/0ed8c696/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbcbooksmj.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20150412/0ed8c696/attachment.vcf>