IPv6 readyNote: This archive passes through spamassassin. Every mail marked with the subject "*****SPAM*****" has exceed a certain threshold of spam-like behaviour.

[Users] Cant ping-Problem

From: Thomas Wiesner (ThWiesner_at_t-online.de)
Date: Tue May 07 2002 - 17:13:17 CEST


Hello together,

hope I place here no FAQ, but all references, Doku's and list archives
could not help me. It concerns a Subnet Subnet connection. All
indicators for the setting up look good, but the appropriate "Ping
test" of the host a Subnets to the host of the other Subnet's does not
fold. Here some important configuration info's:

Expenditures of "ipsec auto -- status"

000 interface ipsec0/ppp0 217.84.22.18
000
000 "CarstenTom":
192.168.60.0/24===217.84.xx.xx[@frankfurt]---217.5.98.7...217.5.98.47---80.133.xx.xxx[@arakasi]===192.168.11.0/24
000 "CarstenTom": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "CarstenTom": policy:
RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; erouted
000 "CarstenTom": newest ISAKMP SA: #1; newest IPsec SA: #2; eroute
owner: #2
000
000 #2: "CarstenTom" STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 28500s; newest IPSEC; eroute owner
000 #2: "CarstenTom" esp.92a4c23b_at_80.133.14.162
esp.7a2bc193_at_217.84.22.18 tun.1002_at_80.133.14.162 tun.1001_at_217.84.22.18
000 #1: "CarstenTom" STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3299s; newest ISAKMP

arakasi:/ # ipsec auto --up CarstenTom
104 "CarstenTom" #1: STATE_MAIN_I1: initiate
106 "CarstenTom" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "CarstenTom" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "CarstenTom" #1: STATE_MAIN_I4: ISAKMP SA established
112 "CarstenTom" #2: STATE_QUICK_I1: initiate
004 "CarstenTom" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
arakasi:/ # ipsec auto --status
000 interface ipsec0/ppp0 80.133.14.162
000
000 "CarstenTom":
192.168.11.0/24===80.133.14.162[@arakasi]---217.5.98.47...217.5.98.7---217.84.22.18[@frankfurt]===192.168.60.0/24
000 "CarstenTom": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "CarstenTom": policy:
RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; erouted
000 "CarstenTom": newest ISAKMP SA: #1; newest IPsec SA: #2; eroute
owner: #2
000
000 #2: "CarstenTom" STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 28224s; newest IPSEC; eroute owner
000 #2: "CarstenTom" esp.7a2bc193_at_217.84.22.18
esp.92a4c23b_at_80.133.14.162 tun.1002_at_217.84.22.18 tun.1001_at_80.133.14.162
000 #1: "CarstenTom" STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 2767s; newest ISAKMP

IPSec.conf... on both sides directly!

# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# More elaborate and more varied sample configurations can be found
# in FreeS/WAN's doc/examples file.

# basic configuration
config setup
        # THIS SETTING MUST BE CORRECT or almost nothing will work;
        # %defaultroute is okay for most simple cases.
        interfaces=%defaultroute
        # Debug-logging controls: "none" for (almost) none, "all" for
lots.
        klipsdebug=none
        plutodebug=all
        # Use auto= parameters in conn descriptions to control startup
actions.
        plutoload=%search
        plutostart=%search
        # Close down old connection when new one using same ID shows up.
        uniqueids=yes

# defaults for subsequent connection descriptions
conn %default
        # How persistent to be in (re)keying negotiations (0 means
very).
        keyingtries=0
        # Parameters for manual-keying testing (DON'T USE
OPERATIONALLY).
        # Note: only one test connection at a time can use these
parameters!
        #spi=0x200
        #esp=3des-md5-96
        
#espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
        #espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf
        # RSA authentication with keys from DNS.
        authby=rsasig
        leftrsasigkey=0sAQNnXlP......
        rightrsasigkey=0x0103e19.....

# sample connection
conn CarstenTom
        # Left security gateway, subnet behind it, next hop toward
right.
        left=217.84.xx.xx
        leftsubnet=192.168.60.0/255.255.255.0
        leftnexthop=217.5.98.7
        # Right security gateway, subnet behind it, next hop toward
left.
        right=80.133.xx.xxx
        rightsubnet=192.168.11.0/255.255.255.0
        rightnexthop=217.5.98.47
        # To authorize this connection, but not actually start it, at
startup,
        # uncomment this.
        auto=add
        leftid=@frankfurt
        rightid=@arakasi

If I now with above configuration of my host 192,168,11,10 to
192.168.60.80 in the other Subnet "pinge", shows me "tcpdump" the
following:

Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on ipsec0
20:33:27.664322 192.168.11.10 > 192.168.60.80: icmp: echo request (DF)
20:33:28.664322 192.168.11.10 > 192.168.60.80: icmp: echo request (DF)
20:33:29.664322 192.168.11.10 > 192.168.60.80: icmp: echo request (DF)

The expenditures tcpdump on the other gateway I do not have any more in
the History, but they indicated the detailed ping's and also the
Reply's the GW "Frankfurt" distant from 192.168.60.80 on the ipsec0 of.
On my GW "arakasi" therefore the Replys was not to be seen and arrived
also not with 192.168.11.10 on the ipsec0 (s.o). To the completeness
still the filter rules in addition, those on both GW's directly exactly
turned around the forward rules.

arakasi:/ # iptables -v -n -L
Chain INPUT (policy ACCEPT 68735 packets, 10428892 bytes)
 pkts bytes target prot opt in out source
destination
    0 0 ACCEPT esp -- ppp0 * 217.84.xx.xx
80.133.xx.xxx
    0 0 ACCEPT ah -- ppp0 * 217.84.xx.xx
80.133.xx.xxx
   44 11040 ACCEPT udp -- ppp0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:500

Chain FORWARD (policy ACCEPT 1693930 packets, 700654081 bytes)
 pkts bytes target prot opt in out source
destination
  284 35216 ACCEPT all -- eth0 ipsec0 192.168.11.0/24
192.168.60.0/24
    0 0 ACCEPT all -- ipsec0 eth0 192.168.60.0/24
192.168.11.0/24

Chain OUTPUT (policy ACCEPT 51133 packets, 11141953 bytes)
 pkts bytes target prot opt in out source
destination
    0 0 ACCEPT esp -- * ppp0 80.133.xx.xxx
217.84.xx.xx
    0 0 ACCEPT ah -- * ppp0 80.133.xx.xxx
217.84.xx.xx
  501 103K ACCEPT udp -- * ppp0 0.0.0.0/0
0.0.0.0/0 udp spt:500

Naturally I read myself by the FreeSwan Doku and their examples, without
I would not have come until here, have also in mailing list archives
for the problem looked, unfortunately still no crucial reference
found....hoffe possibly here; -)

Many greetings Thomas Wiesner
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users



This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:57 CEST