> --- Quoting [EMAIL PROTECTED] on 2005/08/24 at 18:35 +0200:
> > 1) From Client1, I cannot ping its default gateway (.3.254) anymore. No
> > ping replies. ssh connection is frozen.
>
> What machine and interface is .3.254 on? From the information below it does
> not look like it's on PC_B. PC_B is .3.70.
>
No, the rl0 gateway (PC_B) is 192.168.3.254. Client1 is .3.70, PC_B's
internal network is, of course, 192.168.3.0/24.
sis0 --- ADSL MODEM
|
*PC_A* sis2 --- AP <- WiFi -> AP --- rl1 *PC_B* rl0 --- Client1
|
sis1 --- 192.168.0.0/24 LAN
I should have written it more clearly, sorry about that.
> > 2) If I run a tcpdump -i rl1, I see that the pings from Client1 to PC_B are
> > *routed* to PC_A!! Of course, PC_A doesn't know what to do with them;
> > something is getting back, however (encrypted) :
> > # tcpdump -i rl1
> > 17:54:15.803747 esp 10.0.0.6 > 10.0.0.1 spi 0x1F3A4307 seq 70 len 132 (DF)
> > 17:54:15.810208 esp 10.0.0.1 > 10.0.0.6 spi 0x8A4C7C72 seq 58 len 132 (DF)
>
> Doubtful. You have no idea what packets are encapsulated here. Do your
> sniffing on enc0 instead.
>
I will certainly try that and let you know. However, I'm quite confident that
what I'm seeing going out of 10.0.0.6 and back from 10.0.0.1 are the pings
originating from Client1 (192.168.3.70) to PC_B's internal interface (.3.254).
I say this because 1) Client1 os the only machine behind PC_B 2) traffic to
and fro 10.0.0.1 starts when I start pinging and stops accordingly and 3) I
booted Client1 off DSL (Damn Small Linux, not the digital line!) instead of
Winxxx. At least this way Client1 should behave the way I want it to instead of
sending packets more or less at random.
Also keep in mind that .3.254 doesn't reply to the pings when isakmpd is
running.
> > 6) Not all of PC_B 's traffic is going through the tunnel; for example, DNS
> > queries are still in clear:
>
> netstat -rnf encap is your friend. You are not building a phase-2
> connection that includes 10.0.0.x so no encryption for you. Same
> reasoning applies to your ping from 10.0.0.1 to .6.
>
Mmmmh... I'm getting lost. I am re-posting the netstat from my original
message (they were buried at the very end, together with other infos):
On PC_A (when isakmpd is running, of course):
# netstat -r -f encap
Routing tables
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
192.168.3/24 0 0/0 0 0 10.0.0.6/50/use/in
0/0 0 192.168.3/24 0 0 10.0.0.6/50/require/out
On PC_B:
# netstat -r -f encap
Routing tables
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
0/0 0 192.168.3/24 0 0 10.0.0.1/50/use/in
192.168.3/24 0 0/0 0 0 10.0.0.1/50/require/out
Does it look OK or am I missing something here?
So, you are telling me what I need is actually a Phase 2 connection, so
*everything* going through 10.0.0.1 <-> 10.0.0.6 gets encrypted? Let me go
through some documentation first, in case I'll come back to you for this one.
Concerning issues 1) and 2), it seems as if, as soon as I start isakmpd, the
192.168.3.254 interface starts behaving like a bridge, since instead of
replying itself it just passes on the packet to 10.0.0.6. Perhaps the routing
gets screwed up, and it won't behave just by killing isakmpd and a "ipsecadm
flush", you also need to flush the routing table (although I couldn't find any
suspect entry that would account for this behaviour).
Do you thing the 1)-2) and the 6) issues are somehow related?
---
Rob
____________________________________________________________
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it
