> --- Quoting [EMAIL PROTECTED] on 2005/08/25 at 01:20 +0200: > > (can you try wrap your lines at a reasonable 72 chars?)
Yup! Sorry...... > > > 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. > I am *really* scratching my head now. There must be something going on with my setup. Now, if I reboot PC_B and simply run a tcpdump on rl0, rl1 or enc0--you name it--even without running isakmpd on either PC_A or PC_B, I get nothing. I mean, nothing at all, just the usual tcpdump: listening on rl0, link-type EN10MB Nothing in /var/log/messages, nothing in dmesg. Oh, between one of my several reboots, I ran isakmpd and then stopped the process on both PC_A and PC_B and flushed the SA's. Then, everytime I tried to tcpdump on any interface, I got a "Failed to open bpf device for ..." error mesassge. Tried searching the 'net without results. Had to reboot again. Have you got any clue to what is happening here? --- LAST MINUTE UPDATE: in despair, I tried a PTP reboot (Pull The Plug). As soon as the machine rebooted, I tried (successfully, this time) to tcpdump on an interface. Then I tried the other interface, but nothing. So I tried the first interface again. Again, nothing. It seems tcpdump is behaving as a one-time command on my system. Weird thing, tcpdump isn't working, but I can access the Internet from my Client1 machine without problems. Later I'll try changing the cards. Perhaps half of my initial problem is actually a hardware issue, what do you think? Perhaps I should post the dmesg and start a new thread? --- MORE UPDATES: I took a break, since the connection was shaky and I wasn't able to send this message before. So I tried another thing. On PC_A, I re-enabled the line in pf that NATs the 10.0.0.0/29 network (between PC_A and PC_B, as you might recall). I can't believe what I'm seeing: as soon as I re-enable NAT, tcpdump starts working again. I disable NAT (again, only on 10.0.0.0, not on the 192.168.3.0/24--that's always on) and no more tcpdumps. What I can't figure out is what NAT has to do with this: i mean, my Client1 machine was merrily pinging all the time, so obviously something is going through the rl0 and rl1 interfaces, but it is not displayed. ... Rob ____________________________________________________________ Libero Flat, sempre a 4 Mega a 19,95 euro al mese! Abbonati subito su http://www.libero.it
