[Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
Peter McGill
petermcgill at goco.net
Thu Jan 8 12:14:36 EST 2009
TC,
It looks like you've encountered the following bug:
http://bugs.xelerance.com/view.php?id=985
Options:
Switch from klips to netkey (you won't have ipsec0).
Drop to a pre 2.6.24 kernel.
Wait for the bug to be fixed.
Paul,
Is it normal for newer openswan's to include a route to the lan on ipsec0 or is that part of the bug?
+ _________________________ netstat-rn
+ netstat -nr
+ head -n 100
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.23.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.23.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 ***************
82.79.83.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
82.79.83.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 82.79.83.1 0.0.0.0 UG 0 0 0 eth0
Peter McGill
IT Systems Analyst
Gra Ham Energy Limited
> -----Original Message-----
> From: TC [mailto:tonisaco at gmail.com]
> Sent: January 8, 2009 1:48 AM
> To: petermcgill at goco.net
> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on
> k.2.6.24.7
>
> Hi Peter,
>
> I think is something strange with the routeing table:
>
> the table from point A:
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric
> Ref Use Iface
> 82.79.77.64 0.0.0.0 255.255.255.224 U 0
> 0 0 eth0
> 82.79.77.64 0.0.0.0 255.255.255.224 U 0
> 0 0 ipsec0
> 192.168.23.0 82.79.77.65 255.255.255.0 UG 0
> 0 0 ipsec0
> 192.168.10.0 0.0.0.0 255.255.255.0 U 0
> 0 0 eth1
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0
> 0 0 lo
> 0.0.0.0 82.79.77.65 0.0.0.0 UG 1
> 0 0 eth0
>
>
> the table from B:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric
> Ref Use Iface
> 192.168.23.0 0.0.0.0 255.255.255.0 U 0
> 0 0 eth1
> 192.168.23.0 0.0.0.0 255.255.255.0 U 0
> 0 0 ipsec0
> 82.79.83.0 0.0.0.0 255.255.255.0 U 0
> 0 0 eth0
> 82.79.83.0 0.0.0.0 255.255.255.0 U 0
> 0 0 ipsec0
> 192.168.10.0 0.0.0.0 255.255.255.0 U 0
> 0 0 ipsec0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0
> 0 0 lo
> 0.0.0.0 82.79.83.1 0.0.0.0 UG 1
> 0 0 eth0
>
>
>
> On Thu, Jan 8, 2009 at 12:28 AM, Peter McGill
> <petermcgill at goco.net> wrote:
>
>
> TC,
>
> Your config, status and logs look good.
>
>
> > on both sides firewall is down. iptables -F
>
> -F doesn't necessarily completely disable the firewall.
>
> ipsec0 Link encap:Ethernet HWaddr 00:d0:b7:52:8c:a1
> inet addr:82.79.83.23 Mask:255.255.255.0
> UP RUNNING NOARP MTU:16260 Metric:1
> RX packets:51 errors:0 dropped:51 overruns:0 frame:0
> TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Something is causing packets to be dropped.
>
> Could you double-check firewall for me with:
> iptables -t filter -n -L -v
> iptables -t nat -n -L -v
> iptables -t mangle -n -L -v
> It didn't show in the barf.
>
> Can you try ping/traceroute to/from different hosts, ie
> 192.168.23.2 & 192.168.10.253?
>
> You have a strange route in your table.
> + _________________________ netstat-rn
> + netstat -nr
> + head -n 100
> Kernel IP routing table
> Destination Gateway Genmask Flags
> MSS Window irtt Iface
> 192.168.23.0 0.0.0.0 255.255.255.0 U
> 0 0 0 eth1
> ***
> 192.168.23.0 0.0.0.0 255.255.255.0 U
> 0 0 0 ipsec0
> The above route looks wrong/strange to me, not sure why
> it's there.
> ***
> 82.79.83.0 0.0.0.0 255.255.255.0 U
> 0 0 0 eth0
> 82.79.83.0 0.0.0.0 255.255.255.0 U
> 0 0 0 ipsec0
> 192.168.10.0 0.0.0.0 255.255.255.0 U
> 0 0 0 ipsec0
> 127.0.0.0 0.0.0.0 255.0.0.0 U
> 0 0 0 lo
> 0.0.0.0 82.79.83.1 0.0.0.0 UG
> 0 0 0 eth0
> Not sure what effect this might have.
> Perhaps someone else on the list has seen this before?
>
> You also have some netkey code still built as modules,
> you should stick with either klips or netkey.
> + _________________________ usr/src/linux/.config
> + test -f /proc/config.gz
> ++ uname -r
> + test -f /lib/modules/2.6.24.7/build/.config
> ++ uname -r
> + egrep
> 'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_I
> P|CONFIG_HW_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'
> + cat /lib/modules/2.6.24.7/build/.config
> CONFIG_XFRM=y <http://2.6.24.7/build/.configCONFIG_XFRM=y>
> # CONFIG_XFRM_USER is not set
> *** CONFIG_NET_KEY=m disable this ***
> CONFIG_INET=y
> # CONFIG_INET_AH is not set
> # CONFIG_INET_ESP is not set
> # CONFIG_INET_IPCOMP is not set
> # CONFIG_INET_XFRM_TUNNEL is not set
> CONFIG_INET_TUNNEL=m
> # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> # CONFIG_INET_XFRM_MODE_TUNNEL is not set
> # CONFIG_INET_XFRM_MODE_BEET is not set
> # CONFIG_INET_LRO is not set
> CONFIG_INET_DIAG=y
> CONFIG_INET_TCP_DIAG=y
> CONFIG_KLIPS=y
> CONFIG_KLIPS_ESP=y
> CONFIG_KLIPS_AH=y
> CONFIG_KLIPS_AUTH_HMAC_MD5=y
> CONFIG_KLIPS_AUTH_HMAC_SHA1=y
> CONFIG_KLIPS_ALG=y
> # CONFIG_KLIPS_ENC_CRYPTOAPI is not set
> CONFIG_KLIPS_ENC_3DES=y
> CONFIG_KLIPS_ENC_AES=y
> CONFIG_KLIPS_IPCOMP=y
> # CONFIG_KLIPS_OCF is not set
> CONFIG_KLIPS_DEBUG=y
> CONFIG_KLIPS_IF_MAX=64
>
>
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited
>
> > -----Original Message-----
> > From: TC [mailto:tonisaco at gmail.com]
>
> > Sent: January 7, 2009 4:07 PM
> > To: petermcgill at goco.net
>
> > Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on
> > k.2.6.24.7
> >
> > hi peter,
> > and thank you for your time
> >
> > here is my ipsec_barf
> > i've made the ping test
> >
> > ping 192.168.10.254 -I eth1
> > PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1:
> > 56(84) bytes of data.
> > >From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> > From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> > From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> >
> > ping 192.168.23.1 -I eth1
> > PING 192.168.23.1 (192.168.83.1) from 192.168.10.254 eth1:
> > 56(84) bytes of data.
> > >From 192.168.10.254 icmp_seq=1 Destination Host Unreachable
> > From 192.168.10.254 icmp_seq=2 Destination Host Unreachable
> > From 192.168.10.254 icmp_seq=3 Destination Host Unreachable
> >
> > --- 192.168.83.1 ping statistics ---
> > 4 packets transmitted, 0 received, +3 errors, 100% packet
> > loss, time 3012ms
> > , pipe 3
> >
> > with tcpdump on other side but no packets are arriveing
> >
> >
> > On Wed, Jan 7, 2009 at 10:43 PM, Peter McGill
> > <petermcgill at goco.net> wrote:
> >
> >
> > I also run slackware.
> > Your logs indicate the tunnel is up and working.
> > Have you enabled forwarding on your openswan hosts?
> > cat /proc/sys/net/ipv4/ip_forward
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> > Have you tested the tunnel by pinging from a
> host in one subnet
> > to a host in the other subnet. Instead of
> server to server?
> > Have you done a tcpdump during a test to see
> what's happening?
> > What is the output of ipsec verify?
> > Can you send an ipsec barf? It will contain useful
> > debugging info,
> > that will speed up the troubleshooting process.
> > ipsec barf > ipsec_barf.txt
> > Note a barf will contain the status of
> ip_forward, ipsec logs
> > and ipsec verify, ipsec.conf and network info,
> so if you send a
> > barf, you don't need to repeat the other
> information. Barf will
> > contain your ip addresses and a checksum of
> your keys to verify
> > they match, but not your actual keys. A barf is
> very large so
> > please send it privately, not on the list.
> > Barf does not do a tcpdump or ping tests so
> doing those is still
> > usefull.
> >
> >
> > Peter McGill
> > IT Systems Analyst
> > Gra Ham Energy Limited
> >
> > > -----Original Message-----
> >
> > > From: TC [mailto:tonisaco at gmail.com]
> > > Sent: January 7, 2009 3:15 PM
> > > To: petermcgill at goco.net
> > > Cc: users at openswan.org
> > > Subject: Re: [Openswan Users] net-to-net -
> openswan 2.6.18 on
> > > k.2.6.24.7
> > >
> > > Hi,
> > >
> > > on both sides run pc based routers with slackware 12.1
> > > on both sides firewall is down. iptables -F
> > > I added leftsource and rightsource but same result.
> > > here is the ipsec auto --status output:
> > >
> > > root at vpn:/usr/src/linux# ipsec auto --status
> > > 000 using kernel interface: klips
> > > 000 interface ipsec0/eth0 82.79.77.xy
> > > 000 %myid = (none)
> > > 000 debug none
> > > 000
> > > 000 algorithm ESP encrypt: id=3,
> name=ESP_3DES, ivlen=64,
> > > keysizemin=192, keysizemax=192
> > > 000 algorithm ESP encrypt: id=12,
> name=ESP_AES, ivlen=128,
> > > keysizemin=128, keysizemax=256
> > > 000 algorithm ESP auth attr: id=1,
> > > name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128,
> keysizemax=128
> > > 000 algorithm ESP auth attr: id=2,
> > > name=AUTH_ALGORITHM_HMAC_SHA1,
> keysizemin=160, keysizemax=160
> > > 000 algorithm ESP auth attr: id=9,
> > > name=AUTH_ALGORITHM_AES_CBC, keysizemin=128,
> keysizemax=128
> > > 000
> > > 000 algorithm IKE encrypt: id=3,
> name=OAKLEY_BLOWFISH_CBC,
> > > blocksize=8, keydeflen=128
> > > 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC,
> > > blocksize=8, keydeflen=192
> > > 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC,
> > > blocksize=16, keydeflen=128
> > > 000 algorithm IKE encrypt: id=65004,
> name=OAKLEY_SERPENT_CBC,
> > > blocksize=16, keydeflen=128
> > > 000 algorithm IKE encrypt: id=65005,
> name=OAKLEY_TWOFISH_CBC,
> > > blocksize=16, keydeflen=128
> > > 000 algorithm IKE encrypt: id=65289,
> > > name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16,
> keydeflen=128
> > > 000 algorithm IKE hash: id=1,
> name=OAKLEY_MD5, hashsize=16
> > > 000 algorithm IKE hash: id=2,
> name=OAKLEY_SHA1, hashsize=20
> > > 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256,
> > hashsize=32
> > > 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512,
> > hashsize=64
> > > 000 algorithm IKE dh group: id=2,
> name=OAKLEY_GROUP_MODP1024,
> > > bits=1024
> > > 000 algorithm IKE dh group: id=5,
> name=OAKLEY_GROUP_MODP1536,
> > > bits=1536
> > > 000 algorithm IKE dh group: id=14,
> > > name=OAKLEY_GROUP_MODP2048, bits=2048
> > > 000 algorithm IKE dh group: id=15,
> > > name=OAKLEY_GROUP_MODP3072, bits=3072
> > > 000 algorithm IKE dh group: id=16,
> > > name=OAKLEY_GROUP_MODP4096, bits=4096
> > > 000 algorithm IKE dh group: id=17,
> > > name=OAKLEY_GROUP_MODP6144, bits=6144
> > > 000 algorithm IKE dh group: id=18,
> > > name=OAKLEY_GROUP_MODP8192, bits=8192
> > > 000
> > > 000 stats db_ops: {curr_cnt, total_cnt, maxsz}
> > > :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> > > 000
> > > 000 "baiamare-negresti":
> > >
> 192.168.10.0/24===82.79.77.xy<82.79.77.xy>[+S=C]---82.79.77.65
> > >
> ...82.79.83.1---82.79.83.nm<82.79.83.nm>[+S=C]===192.168.23.0/
> > > 24; erouted; eroute owner: #4
> > > 000 "baiamare-negresti": myip=192.168.10.254;
> > hisip=192.168.23.1;
> > > 000 "baiamare-negresti": ike_life: 3600s;
> ipsec_life:
> > > 28800s; rekey_margin: 540s; rekey_fuzz: 100%;
> keyingtries: 3
> > > 000 "baiamare-negresti": policy:
> > > RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW; prio: 24,24;
> > interface: eth0;
> > > 000 "baiamare-negresti": newest ISAKMP SA: #3;
> > newest IPsec SA: #4;
> > > 000 "baiamare-negresti": IKE algorithm newest:
> > > AES_CBC_128-SHA1-MODP2048
> > > 000
> > > 000 #4: "baiamare-negresti":500
> STATE_QUICK_R2 (IPsec SA
> > > established); EVENT_SA_REPLACE in 28205s;
> newest IPSEC;
> > > eroute owner; isakmp#3; idle; import:not set
> > > 000 #4: "baiamare-negresti" esp.572de5cb at 82.79.83.nm
> > > esp.f718f73e at 82.79.77.xy tun.1004 at 82.79.83.nm
> > > tun.1003 at 82.79.77.xy ref=13 refhim=9
> > > 000 #3: "baiamare-negresti":500 STATE_MAIN_R3
> (sent MR3,
> > > ISAKMP SA established); EVENT_SA_REPLACE in
> 3005s; newest
> > > ISAKMP; lastdpd=-1s(seq in:0 out:0); idle;
> import:not set
> > > 000 #2: "baiamare-negresti":500
> STATE_QUICK_I2 (sent QI2,
> > > IPsec SA established); EVENT_SA_REPLACE in
> 27647s; isakmp#1;
> > > idle; import:admin initiate
> > > 000 #2: "baiamare-negresti" esp.f7140fdc at 82.79.83.nm
> > > esp.f718f73d at 82.79.77.xy tun.1001 at 82.79.83.nm
> > > tun.1002 at 82.79.77.xy ref=11 refhim=9
> > > 000 #1: "baiamare-negresti":500 STATE_MAIN_I4
> (ISAKMP SA
> > > established); EVENT_SA_REPLACE in 2555s;
> lastdpd=-1s(seq in:0
> > > out:0); idle; import:admin initiate
> > >
> > >
> > >
> > > On Wed, Jan 7, 2009 at 9:13 PM, Peter McGill
> > > <petermcgill at goco.net> wrote:
> > >
> > >
> > > This is not uncommon, -I doesn't always
> work, try
> > > adding the following to your conf.
> > > leftsourceip=192.168.10.254
> > > rightsourceip=192.168.23.1
> > > Also check that your firewall isn't blocking
> > tunnel traffic.
> > > You need to allow communication between
> 192.168.10.0/24
> > > and 192.168.23.0/24 on ipsec0.
> > > Not sure what that Delete SA message is
> about, what
> > > ipsec device is on the other end of tunnel?
> > >
> > > Peter McGill
> > > IT Systems Analyst
> > > Gra Ham Energy Limited
> > >
> > >
> > > > -----Original Message-----
> > > > From: users-bounces at openswan.org
> > > > [mailto:users-bounces at openswan.org]
> On Behalf Of TC
> > > > Sent: January 7, 2009 12:20 PM
> > > > To: users at openswan.org
> > > > Subject: [Openswan Users] net-to-net
> - openswan
> > > 2.6.18 on k.2.6.24.7
> > > >
> > > > Hi all,
> > > >
> > > > I have installed kernel 2.6.24.7 +
> klips patch +
> > > openswan 2.6.18
> > > > I have made a net-to-net config. The
> connection start
> > > but I cannot
> > > > ping the end of the tunnel.
> > > >
> > > > ping 192.168.23.1 -I eth1 not working
> > > > ping 192.168.10.254 -I eth1 not working
> > > >
> > > > ping 192.168.10.254 -I eth1
> > > > PING 192.168.10.254 (192.168.10.254) from
> > 192.168.23.1 eth1:
> > > > 56(84) bytes of data.
> > > > From 192.168.23.1 icmp_seq=2 Destination Host
> > Unreachable
> > > > >From 192.168.23.1 icmp_seq=3 Destination
> > Host Unreachable
> > > > From 192.168.23.1 icmp_seq=4 Destination Host
> > Unreachable
> > > >
> > > >
> > > > A config(and same config to B but different
> > ipsec.secrets)
> > > >
> > > > version 2.0
> > > >
> > > > config setup
> > > > interfaces="ipsec0=eth0"
> > > > protostack=klips
> > > >
> > > > conn block
> > > > auto=ignore
> > > >
> > > > conn private
> > > > auto=ignore
> > > >
> > > > conn private-or-clear
> > > > auto=ignore
> > > >
> > > > conn clear-or-private
> > > > auto=ignore
> > > >
> > > > conn clear
> > > > auto=ignore
> > > >
> > > > conn packetdefault
> > > > auto=ignore
> > > >
> > > > conn A-B
> > > > left=WAN_IP_FROM_A
> > > > leftnexthop=GATEWAY_FROM_A
> > > > leftsubnet=192.168.10.0/24
> > > > right=WAN_IP_FROM_B
> > > > rightnexthop=GATEWAY_FROM_B
> > > > rightsubnet=192.168.23.0/24
> > > > type=tunnel
> > > > auth=esp
> > > > leftrsasigkey=0sAQOY...
> > > > rightrsasigkey=0sAQNqB...
> > > > auto=start
> > > >
> > > > in /var/log/syslog I have:
> > > > Jan 7 19:13:12 vpn ipsec_setup:
> Starting Openswan
> > > IPsec 2.6.18...
> > > > Jan 7 19:13:12 vpn ipsec__plutorun: 002
> > added connection
> > > > description "A-B"
> > > > Jan 7 19:13:12 vpn
> ipsec__plutorun: 104 "A-B" #1:
> > > > STATE_MAIN_I1: initiate
> > > >
> > > > in /var/log.secure I have:
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > STATE_MAIN_I2:
> > > > sent MI2, expecting MR2
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > transition from
> > > > state STATE_MAIN_I2 to state STATE_MAIN_I3
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > STATE_MAIN_I3:
> > > > sent MI3, expecting MR3
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > received Vendor
> > > > ID payload [CAN-IKEv2]
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > Main mode peer ID
> > > > is ID_IPV4_ADDR: '82.79.83.23'
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > transition from
> > > > state STATE_MAIN_I3 to state STATE_MAIN_I4
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #1:
> > STATE_MAIN_I4:
> > > > ISAKMP SA established {auth=OAKLEY_RSA_SIG
> > cipher=aes_128
> > > > prf=oakley_sha group=modp2048}
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #2:
> > initiating Quick
> > > > Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW
> > {using isakmp#1
> > > > msgid:beed36ed proposal=defaults
> > > pfsgroup=OAKLEY_GROUP_MODP2048}
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #2:
> > transition from
> > > > state STATE_QUICK_I1 to state STATE_QUICK_I2
> > > > Jan 7 19:15:57 vpn pluto[10094]: "A-B" #2:
> > STATE_QUICK_I2:
> > > > sent QI2, IPsec SA established tunnel mode
> > {ESP=>0x45d84918
> > > > <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none
> > > NATD=none DPD=none}
> > > > Jan 7 19:16:16 vpn pluto[10094]: "A-B" #1:
> > ignoring Delete
> > > > SA payload: PROTO_IPSEC_ESP
> SA(0x45d84917) not found
> > > (maybe expired)
> > > > Jan 7 19:16:16 vpn pluto[10094]: "A-B" #1:
> > received and
> > > > ignored informational message
> > > >
> > > >
> > > > Thx for Help.
> > > >
> > > > --
> > > > TC
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > --
> > > TC
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> > --
> > TC
> >
> >
>
>
>
>
>
>
> --
> --
> TC
>
>
More information about the Users
mailing list