<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Two Cipes
From: Manuela Guandalini <guandam,AT,gcs-mbh,DOT,de>
Date: Tue, 31 Oct 2000 12:24:49 +0100
In-reply-to: <E50028F23FC6D3118B7D00609761083F10D8D0@merkur.merlin.cz>

Roskanuk Michal wrote:

> > Roskanuk Michal wrote:
> >
> > > > > >Hi u all,
> > > > > >i've already read the mails about connecting three
> > > > > >internal nets thanks to two CIPE options >files
> > > > > >and tried to make it work. Now i got machine A
> > > > > >connectet to B throu cipcb0 with key0 and port0.
> > > > > >It works great. Machine A should connect to C
> > > > > >throu cipcb1, with key1and port1. This  won't work.
> > > > > >Machine A has a uptodated firewall, which really uses the
> > > > > >same rules for machine B and >C.
> > > > > >Machine B and C have the same old firewall with identical
> > > > > >rules (different ips, of >course :)) ).
> > > > >
> > > > > Are you sure the firewall rules permit the UDP ports
> > > > > used by A<->C?
> > > >
> > > > Yes, the rules A<->C are exactely the same as for A<->B
> > > > (which works), I mean....
> > > > the port0 has the same rules as port1.
> > > > Fothermore: the rules in C and B are identical.
> > >
> > > If u want to be absolutely sure, export/list these rules
> > > (especially on B and C). For ipchains 'ipchains -L'
> > > or 'ipchains-save', for ipfwadm similiar ... already forgot.
> > > u can say i'm paranoid, but who knows.
> > > (BTW u didn't specified your linux.) Also make sure
> > > that there isn't any other fw on the way (i suppose
> > > another comm. between A <-> works well and u've tested it
> > > already).
> >
> > That's what I already did. How else would i know, the rules
> > are identical?
> > Well. Which Linux? Linux SuSE 6.3 (machines B & C) and SuSE 6.4 on A.
> > I really have no idea any more.
> > Wrong portnr.? I tried different ones. I even tried the one i
> > usually use for A<>B  on the connection A<>C. No way. It must
> > be something else.
> >
>
> I ment other services. R u able to connect a->c & c->a via - for
> example - telnet, when u allow it?
>

i can connect via ssh, but only with the external address.

>
> Also check what happens on interfaces (use tcpdump, it's very
> powerfull tool), compare with machine b. Try on ethX, if ok,
> try cipcbX. If u'll see correct in/out traffic, log it at
> corresponding interfaces (via ipchains ... -l) to see what
> happens with these packets, when they arrive.
>

I'm sorry. I'm not able to use tcpdump.
I tried
# tcpdump 'icmp[0]=8 and icmp[0] = 0' -i -w tcdp
# tcpdump -r tcdp
and nothing came out. I guess,  i don't understand, how to use it.

I saw something interesting with iptraf.
Pinging from A to B
****************
iptraf on A shows
ICMP echo request from 10.A.x.x to 10.B.x.x on eth0
UDP from 192.A.A.A:Port0 to 195.B.B.B:Port0 on eth1
UDP from 195.B.B.B:Port0 to 192.A.A.A:Port0 on eth1
ICMP echo reply from 10.B.x.x to 10.A.x.x on eth0
-----------
iptraf on B shows
UDP from 192.A.A.A:Port0 to 195.B.B.B:Port0 on eth1
UDP from 195.B.B.B:Port0 to 192.A.A.A:Port0 on eth1

That's the working tunnel.

But pinging from A to C
*******************
iptraf on A shows
ICMP echo request from 10.A.x.x to 10.C.x.x on eth0
UDP from 192.A.A.A:Port1 to 195.C.C.C:Port1 on eth1
ICMP dest unreach (host) from 195.???.???.??? to 192.A.A.A on eth1
-------------
iptraf on C shows
UDP from 192.A.A.A:Port1 to 195.C.C.C:Port1 on eth1
UDP from 192.A.A.A:Port1 to 10.0.0.0:Port1 on eth1

Machine 195.???.???.??? is part of the ebone connecting C to the internet
and has been cheked out by its sysadm. They mean, they won't block
anything.

The only difference i found between B and C after looking at   e v e r y
/proc- file was in

/proc/sys/net/ip4v/ip_always_defrag (different values)
/proc/sys/kernel   different Versionnr. :)) the B has 2.2.14

the C has 2.2.13

Again
thanks for any new idea.
Read u.
Manu.





<< | Thread Index | >> ]    [ << | Date Index | >> ]