[Openswan Users] Second IP network through a tunnel
Alex Petcu
alex.petcu at sipstatus.com
Thu Oct 8 09:08:10 EDT 2015
Hi guys,
I have a tunnel already running fine, and I tried to add a second network on my side (to send traffic to the same IP on the other side).
The ipsec.conf part looks like this:
conn verizon
authby=secret
auto=start
ike=3des-md5;modp1024!
phase2alg=3des-md5;modp1024
#phase2alg=aes128-sha1
ikelifetime=8h
keylife=1h
dpddelay=30
dpdtimeout=120
dpdaction=restart
left=37.58.73.98
# leftsubnet=5.153.18.208/30
leftsubnets={5.153.18.208/30,5.153.31.8/29}
# nexthop is automatically discovered
#leftnexthop=37.58.73.97
pfs=yes
right=193.99.34.196
rightsubnet=193.99.34.0/27
5.153.18.208 is the class that was already working, and 5.153.31.8/29 is the new one.
It looks like both are coming up ok:
000 "verizon/1x0": myip=unset; hisip=unset;
000 "verizon/1x0": ike_life: 28800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "verizon/1x0": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 30,27; interface: bond1;
000 "verizon/1x0": dpd: action:restart; delay:30; timeout:120;
000 "verizon/1x0": newest ISAKMP SA: #0; newest IPsec SA: #2;
000 "verizon/1x0": aliases: verizon
000 "verizon/1x0": IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)_000-MODP1024(2); flags=strict
000 "verizon/1x0": IKE algorithms found: 3DES_CBC(5)_192-MD5(1)_128-MODP1024(2)
000 "verizon/1x0": ESP algorithms wanted: 3DES(3)_000-MD5(1)_000; pfsgroup=MODP1024(2); flags=-strict
000 "verizon/1x0": ESP algorithms loaded: 3DES(3)_192-MD5(1)_128
000 "verizon/1x0": ESP algorithm newest: 3DES_000-HMAC_MD5; pfsgroup=MODP1024
000 "verizon/2x0": 5.153.31.8/29===37.58.73.98<37.58.73.98>[+S=C]...193.99.34.196<193.99.34.196>[+S=C]===193.99.34.0/27; erouted; eroute owner: #3
000 "verizon/2x0": myip=unset; hisip=unset;
000 "verizon/2x0": ike_life: 28800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "verizon/2x0": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 29,27; interface: bond1;
000 "verizon/2x0": dpd: action:restart; delay:30; timeout:120;
000 "verizon/2x0": newest ISAKMP SA: #1; newest IPsec SA: #3;
000 "verizon/2x0": aliases: verizon
000 "verizon/2x0": IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)_000-MODP1024(2); flags=strict
000 "verizon/2x0": IKE algorithms found: 3DES_CBC(5)_192-MD5(1)_128-MODP1024(2)
000 "verizon/2x0": IKE algorithm newest: 3DES_CBC_192-MD5-MODP1024
000 "verizon/2x0": ESP algorithms wanted: 3DES(3)_000-MD5(1)_000; pfsgroup=MODP1024(2); flags=-strict
000 "verizon/2x0": ESP algorithms loaded: 3DES(3)_192-MD5(1)_128
000 "verizon/2x0": ESP algorithm newest: 3DES_000-HMAC_MD5; pfsgroup=MODP1024
000
000 #2: "verizon/1x0":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2840s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "verizon/1x0" esp.d2d989e at 193.99.34.196 esp.ffb5d820 at 37.58.73.98 tun.0 at 193.99.34.196 tun.0 at 37.58.73.98 ref=0 refhim=4294901761
000 #3: "verizon/2x0":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2945s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #3: "verizon/2x0" esp.d2d989f at 193.99.34.196 esp.11ec4529 at 37.58.73.98 tun.0 at 193.99.34.196 tun.0 at 37.58.73.98 ref=0 refhim=4294901761
000 #1: "verizon/2x0":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 28150s; newest ISAKMP; lastdpd=3s(seq in:26598 out:0); idle; import:admin initiate
000
ip xfrm policy
src 5.153.31.8/29 dst 193.99.34.0/27
dir out priority 2181 ptype main
tmpl src 37.58.73.98 dst 193.99.34.196
proto esp reqid 16389 mode tunnel
src 193.99.34.0/27 dst 5.153.31.8/29
dir fwd priority 2181 ptype main
tmpl src 193.99.34.196 dst 37.58.73.98
proto esp reqid 16389 mode tunnel
src 193.99.34.0/27 dst 5.153.31.8/29
dir in priority 2181 ptype main
tmpl src 193.99.34.196 dst 37.58.73.98
proto esp reqid 16389 mode tunnel
src 5.153.18.208/30 dst 193.99.34.0/27
dir out priority 2149 ptype main
tmpl src 37.58.73.98 dst 193.99.34.196
proto esp reqid 16385 mode tunnel
src 193.99.34.0/27 dst 5.153.18.208/30
dir fwd priority 2149 ptype main
tmpl src 193.99.34.196 dst 37.58.73.98
proto esp reqid 16385 mode tunnel
src 193.99.34.0/27 dst 5.153.18.208/30
dir in priority 2149 ptype main
tmpl src 193.99.34.196 dst 37.58.73.98
proto esp reqid 16385 mode tunnel
But when I source traffic from 5.153.31.10 nothing is sent through the tunnel.
Traffic sourced from 5.153.18.210 flows just fine.
Any idea what might be causing this?
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20151008/9e004828/attachment.html>
More information about the Users
mailing list