[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