[Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
Peter McGill
petermcgill at goco.net
Wed Jan 7 17:28:01 EST 2009
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_IP|CONFIG_HW_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'
+ cat /lib/modules/2.6.24.7/build/.config
CONFIG_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
>
>
More information about the Users
mailing list