[prev in list] [next in list] [prev in thread] [next in thread]
List: strongswan-users
Subject: [strongSwan] ICMP ping packet drop between eth0 - ipsec
From: r.volkmer () fh-wolfenbuettel ! de (Ruben Volkmer)
Date: 2006-06-29 11:08:28
Message-ID: 18002e181637.18163718002e () fh-wolfenbuettel ! de
[Download RAW message or body]
Hello!
I finally get rid of the pingdrop!
/proc/sys/netipv4/conf/eth0/rp_filter
this had had to be set to 0!
echo 0 > /proc/sys/netipv4/conf/eth0/rp_filter
may eventually solve similar problems.
Regards
Ruben
----- Originalnachricht -----
Von: Ruben Volkmer <r.volkmer@fh-wolfenbuettel.de>
Datum: Mittwoch, Juni 28, 2006 10:41 am
Betreff: Re: Re: [strongSwan] ICMP ping packet drop between eth0 - ipsec
> Thank you Holger,
> but unfortunately it won't work either with the flag set or not.
> After I've done
> # echo "1" > /proc/sys/net/ipv4/conf/ethN/proxy_arp
> I run tcpdump on both Interfaces and Ethereal on WinBox. Again the
> packets are lost between eth0 and ipsec0. I don't have any idea how to
> solve that. I think it has to be a routing problem, but every route I
> try it doesn't change that packets are dropped.
>
> rgds,
> Ruben
>
> My ip route output:
> # ip route
> 192.168.81.1 via 192.168.81.1 dev ipsec0
> 192.168.81.0/24 dev eth0 proto kernel scope link src 192.168.81.2
> 192.168.81.0/24 dev ipsec0 proto kernel scope link src 192.168.81.2
>
> Here again with the tcpdump & ethereal Logs with ARP Req and Response:
>
> Everything ok here ICMP Reply from 192.168.81.1
> ARP Req and Rep also:
> <TCPDump on eth0>=======================================> # tcpdump -i eth0
> tcpdump: listening on eth0
> 10:15:08.788182 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x3d)10:15:08.788554 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x8d) (DF)
> 10:15:09.788268 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x3e)10:15:09.788624 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x8e) (DF)
> 10:15:10.788247 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x3f)10:15:10.788564 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x8f) (DF)
> 10:15:11.788251 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x40)10:15:11.788505 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x90) (DF)
> 10:15:12.788248 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x41)10:15:12.788570 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x91) (DF)
> 10:15:13.788182 arp who-has 192.168.81.1 tell 192.168.81.2
> 10:15:13.788297 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x42)10:15:13.788388 arp reply 192.168.81.1
> is-at 0:d:60:ab:1c:32
> 10:15:13.788510 192.168.81.1 > 192.168.81.2:
> ESP(spi=0x815e0527,seq=0x92) (DF)
> 10:15:14.788248 192.168.81.2 > 192.168.81.1:
> ESP(spi=0x069da467,seq=0x43)10:15:14.788577 192.168.81.1 >
> 192.168.81.2:ESP(spi=0x815e0527,seq=0x93) (DF)
>
>
> And here, who knows why, only the ICMP Req Packets are send out.
> The Reply is lost anywhere between eth0 and ipsec0 Interfaces:
> <TCPdump on
> ipsec0>=============================================================> # tcpdump -i \
> ipsec0
> tcpdump: listening on ipsec0
> 10:15:08.788125 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:09.788224 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:10.788206 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:11.788207 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:12.788207 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:13.788255 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
> 10:15:14.788207 192.168.81.2 > 192.168.81.1: icmp: echo request (DF)
>
>
> To be complete here the Ethereal Log. Both ICMP Req and Rep Listed
> as ESPs:
> No. Time Source Destination
> ProtocolInfo
> 1 0.000000 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 2 0.000280 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 3 0.999901 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 4 1.000068 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 5 1.999696 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 6 1.999851 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 7 2.999516 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 8 2.999675 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 9 3.999336 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 10 3.999515 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 11 4.999078 EpoxComp_57:d1:43 Ibm_ab:1c:32 ARP
>
> Who has 192.168.81.1? Tell 192.168.81.2
> 12 4.999114 Ibm_ab:1c:32 EpoxComp_57:d1:43 ARP
>
> 192.168.81.1 is at 00:0d:60:ab:1c:32
> 13 4.999186 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 14 4.999314 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
> 15 5.998966 192.168.81.2 192.168.81.1 ESP
>
> ESP (SPI=0x069da467)
> 16 5.999110 192.168.81.1 192.168.81.2 ESP
>
> ESP (SPI=0x815e0527)
>
>
>
>
>
>
>
> ----- Originalnachricht -----
> Von: Holger Burde
> Datum: Dienstag, Juni 27, 2006 6:56 pm
> Betreff: Re: [strongSwan] ICMP ping packet drop between eth0 - ipsec
>
> > Hi;
> >
> > Just a quick guess - i often need to set Proxy ARP on the internal
> > Interface in case of Virtual IP Setups. If i don't set Proxy ARP the
> > effect is the same as yours - established IPSEC SA's and no response
> > Packets from remote LAN(s). You may see ARP Requests
> (sniffer@lan) but
> > no response.
> >
> > # LAN Interface
> > # echo "1" > /proc/sys/net/ipv4/conf/ethN/proxy_arp
> >
> > hb
> > Am Dienstag, den 27.06.2006, 15:03 +0200 schrieb Ruben Volkmer:
> > > Hello List,
> > >
> > > First thanks for the good & fast support from Andreas at
> > strongswanorg!>
> > > My Config:
> > >
> > > Debian / Moon - Sun / Windows 2000
> > > 192.168.81.2 - 192.168.81.1
> > > Strongswan - WinIPsecStack
> > >
> > > The Problem is that after succesfully establishment of SA, no
> > ping comes
> > > up to the ipsec0 device. It is on eth0 device visible as ESP.
> > > I have recorded with Etherreal on the Win Box and TCPdump on
> the
> > Linux> Box, see below.
> > >
> > > Could the Problem be the Routing on LinuxBox (there's no
> firewall on
> > > both sides), or with Strongswan Config (see log below)?
> > >
> > > Thanks for your help!
> > > Best regards,
> > > Ruben
> > >
> > >
> > > Here is the output of "route" on Linux:
> > > # route -neCF
> > > Kernel IP Routentabelle
> > > Ziel Router Genmask Flags MSS
> > Fenster irtt
> > > Iface
> > > 192.168.81.1 192.168.81.1 255.255.255.255 UGH 40 0
>
> > 0
> > > ipsec0
> > > 192.168.81.0 0.0.0.0 255.255.255.0 U 40 0
>
> > 0
> > > eth0
> > > 192.168.81.0 0.0.0.0 255.255.255.0 U 40 0
>
> > 0
> > > ipsec0
> > > Kernel IP Routencache
> > > Quelle Ziel Maske Flags MSS
> > Fenster irtt
> > > Iface
> > > 192.168.81.2 192.168.81.255 192.168.81.255 bl 1500 0
>
> > 0
> > > eth0
> > > 127.0.0.1 127.0.0.1 127.0.0.1 l 16436 0
>
> > 5 lo
> > > 127.0.0.1 127.0.0.1 127.0.0.1 l 16436 0
>
> > 0 lo
> > >
> > > <tcpdump eth0>=============================> > > # tcpdump -i eth0
> > > tcpdump: listening on eth0
> > > <..>
> > > 14:17:21.190234 192.168.81.2 > 192.168.81.1:
> > ESP(spi=0x35202b19,seq=0x1)> 14:17:21.190591 192.168.81.1 >
> > 192.168.81.2: ESP(spi=0x0673678f,seq=0xe)
> > > (DF)
> > > 14:17:22.183865 192.168.81.2 > 192.168.81.1:
> > ESP(spi=0x35202b19,seq=0x2)> 14:17:22.184167 192.168.81.1 >
> > 192.168.81.2: ESP(spi=0x0673678f,seq=0xf)
> > > (DF)
> > > 14:17:23.183828 192.168.81.2 > 192.168.81.1:
> > ESP(spi=0x35202b19,seq=0x3)> 14:17:23.184119 192.168.81.1 >
> > 192.168.81.2:> ESP(spi=0x0673678f,seq=0x10) (DF)
> > > 14:17:24.183828 192.168.81.2 > 192.168.81.1:
> > ESP(spi=0x35202b19,seq=0x4)> 14:17:24.184194 192.168.81.1 >
> > 192.168.81.2:> ESP(spi=0x0673678f,seq=0x11) (DF)
> > > <..>
> > > 38 packets received by filter
> > > 0 packets dropped by kernel
> > >
> > >
> > >
> > > <tcpdump ipsec0>=============================> > > # tcpdump -i ipsec0
> > > tcpdump: listening on ipsec0
> > > <..>
> > > 14:17:21.189991 192.168.81.2 > 192.168.81.1: icmp: echo request
> (DF)> > 14:17:22.183821 192.168.81.2 > 192.168.81.1: icmp: echo
> request (DF)
> > > 14:17:23.183784 192.168.81.2 > 192.168.81.1: icmp: echo request
> (DF)> > 14:17:24.183784 192.168.81.2 > 192.168.81.1: icmp: echo
> request (DF)
> > > 14:17:25.183786 192.168.81.2 > 192.168.81.1: icmp: echo request
> (DF)> > <..>
> > > 15 packets received by filter
> > > 0 packets dropped by kernel
> > >
> > >
> > >
> > > <etherreal>=============================> > > No. Time Source \
> > > Destination
> > Protocol> Info
> > > 4 0.002028 192.168.81.2 192.168.81.1
> > ISAKMP
> > > Identity Protection (Main Mode)
> > > 5 0.052704 192.168.81.1 192.168.81.2
> > ISAKMP
> > > Identity Protection (Main Mode)
> > > 6 0.083610 192.168.81.2 192.168.81.1
> > ISAKMP
> > > Identity Protection (Main Mode)
> > > 7 0.110325 192.168.81.1 192.168.81.2
> > ISAKMP
> > > Identity Protection (Main Mode)
> > > 8 0.582022 192.168.81.2 192.168.81.1
> > ISAKMP
> > > Identity Protection (Main Mode)
> > > 9 0.634591 192.168.81.1 192.168.81.2
> > ISAKMP
> > > Quick Mode
> > > 10 0.915528 192.168.81.2 192.168.81.1
> > ISAKMP
> > > Quick Mode
> > > 11 0.934581 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 12 0.934906 192.168.81.1 192.168.81.2
> > ISAKMP
> > > Quick Mode
> > > 13 5.105415 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 14 6.494276 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 15 7.995507 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 16 9.494312 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 17 15.229249 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 18 16.494187 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 19 17.994210 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 20 19.494206 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 21 72.886165 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 22 73.994140 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 23 75.494097 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > > 24 76.994153 192.168.81.1 192.168.81.2
> > ESP
> > > ESP (SPI=0x0673678f)
> > >
> > >
> > >
> > >
> > > <Auth.log>=============================> > > A snap from Auth.log:
> > > <..>
> > > Jun 27 14:15:45 NODEPC pluto[1103]: "rw"[2] 192.168.81.1 #2:
> > responding> to Quick Mode
> > > Jun 27 14:15:45 NODEPC pluto[1103]: |
> > kernel_alg_esp_auth_keylen(auth=1,> sadb_aalg=2): a_keylen
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | install_inbound_ipsec_sa()
> > > checking if we can route
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | route owner of "rw"[2]
> > > 192.168.81.1 unrouted: NULL; eroute owner: NULL
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | add inbound eroute
> > > 192.168.81.1/32:0 -> 192.168.81.2/32:0 => tun.1001@192.168.81.2:0
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | inserting event
> > EVENT_RETRANSMIT,> timeout in 10 seconds for #2
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | next event
> EVENT_RETRANSMIT
> > in 10
> > > seconds for #2
> > > Jun 27 14:15:45 NODEPC pluto[1103]: |
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | *received 52 bytes from
> > > 192.168.81.1:500 on eth0
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | ICOOKIE: 8f 1f db f4 c2
> > 59 84 70
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | RCOOKIE: 9f cd e6 1e 35
> > e4 20 5f
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | peer: c0 a8 51 01
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | state hash entry 14
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | state object #2 found, in
> > > STATE_QUICK_R1
> > > Jun 27 14:15:45 NODEPC pluto[1103]: | install_ipsec_sa() for #2:
> > > outbound only
> > > <..>
> > > outbound only? how to reconfigure that inbound is available too!?
> > >
> > >
> > >
> > >
> > >
> > > <ipsec.conf>=============================> > > # /etc/ipsec.conf - strongSwan \
> > > IPsec configuration file # RCSID $Id: ipsec.conf.in,v 1.7 2006/01/31 13:09:10 \
> > > as Exp $ # Manual: ipsec.conf.5
> > > # Help: http://www.strongswan.org/docs/readme.htm
> > > version 2.0 # conforms to second version of ipsec.conf
> specification> >
> > > # basic configuration
> > > config setup
> > > # Debug-logging controls: "none" for (almost) none, "all" for
> lots.> > plutodebug=control
> > > interfaces="ipsec0=eth0"
> > > # crlcheckinterval`0
> > > # strictcrlpolicy=yes
> > > # cachecrls=yes
> > > nat_traversal=yes
> > >
> > > # Uncomment to activate Opportunistic Encryption (OE)
> > > # include /etc/ipsec.d/examples/oe.conf
> > >
> > > ca strongswan
> > > cacertÊcert.pem
> > > autod
> > >
> > > # Add connections here.
> > >
> > > # WITH THIS ONE SA WAS ESTABLISHED, BUT NO PING GETS THRU
> > > #conn %default
> > > # ikelifetime`m
> > > # keylife m
> > > # rekeymargin=3m
> > > # keyingtries=1
> > > # left2.168.81.2
> > > # leftnexthop=%direct
> > > # leftcert=moon.pem
> > > # #leftfirewall=yes
> > > #
> > > #conn host-host
> > > # right2.168.81.1
> > > # rightid="C̃, ST=MyLand, L=Hometown, O=MyCompany, OU=Sun,
> CN=Sun"> > # pfs=yes
> > > # autod
> > >
> > > # NOW WE TRY THIS ONE BUT SAME PROBLEM
> > > conn %default
> > > keyingtries=1
> > > compress=yes
> > > authby=rsasig
> > > leftrsasigkey=%cert
> > > rightrsasigkey=%cert
> > >
> > > conn rw
> > > left2.168.81.2
> > > leftcert=moon.pem
> > > right=%any
> > > autod
> > > pfs=yes
> > > #firewallupdate=yes
> > >
> > > 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 packetdefualt
> > > auto=ignore
> > >
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users@lists.strongswan.org
> > > https://lists.strongswan.org/mailman/listinfo/users
> > --
> > --- -- -
> > Dipl. Inform. H. Burde
> > EMail : <hburde@t-online.de>| <hburde@uni-bremen.de>
> >
> >
> _______________________________________________
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic