--- Quoting [EMAIL PROTECTED] on 2005/08/25 at 01:20 +0200:

(can you try wrap your lines at a reasonable 72 chars?)


>   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.

Oops, I should've seen that 3.70 was an ARP entry. It's odd that the
host route for .3.254 is missing through...
 
>    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.

Well which of those ipsec flows above would match packets from 10.0.0.1
to 10.0.0.6? Neither. You need to setup another phase-2 connection for these
hosts/networks.
 
>    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).

I'll be honest, I've never setup a phase-2 connection using a default
route so I've not seen this type of behavior. It seems though that the
icmp reply from .3.254 is matching the ipsec flow 192.168.3/24 -> 0/0
and is therefor being punted to 10.0.0.1. When you ping 10.0.0.6, there
is no matching ipsec flow and so you don't see this behavior.
 


.joel

Reply via email to