From: Administrator <ad...@di...> - 2007-06-29 19:03:53
|
> On Fri, 29 Jun 2007, Administrator might have said: > > > > > > Currently all my boxes on GREEN actuall use a default > route that > > > > > goes to a Cisco PIX. I am trying to change these default > > > routes to > > > > > IPCop, then have IPCop forward the packets to the > PIX. I have > > > > > an iptables rule that will accept anything from my internal > > > > > network > > > > > (10.1.2.x) destined for my VPN network on the PIX > > > (10.1.3.x) and I > > > > > have a route statement that sends all packets for 10.1.3.x to > > > > > the internal IP address of the Cisco PIX. > > > > > > > > > > I see some packets are registered in iptables (iptables > > > -vL | grep > > > > > 10.1.3), but no packets reach my PIX. > > > > > > > > > > Has someone already done this and how? Can someone > help me setup > > > > > this up? Can someone help me diagnose why my setup is > not working? > > > > > > > > > > Mike > > > > > > > > Oops... > > > > > > > > IPCop 1.4.11 > > > > > > > > Connecting to the PIX from an external device using VPN > I can ping > > > > those boxes in GREEN that I have already changed the > > > default route to > > > > IPCop. I cannot telnet to those boxes (telnet $HOST 22). > > > > > > > > Mike > > > > > > Another thought... maybe a picture will help? > > > > > > +----------+ +-----+ +-------+ +---------------+ > > > | internet |<>| PIX |->| GREEN |->|internal server| > > > +----------+ +-----+ +-------+ +---------------+ > > > ^ | > > > | V > > > +-------+ +-------+ | > > > | IPCop |<-| GREEN |----<---+ > > > +-------+ +-------+ > > > > > > The internet to the PIX, over GREEN to an internal server. > > > The default route on the internal server sends packets to IPCop, > > > then I want IPCop to forward those packets back to the > PIX and the > > > originating user. > > > > Two questions: > > > > 1) are the two Green's the same? Are they both networks? If not, > > what are they and what's the difference? > > > > 2) what is the difference between what the IPCop does and > what the PIX does? > > Are they both doing the same thing? How does having 2 devices in > > parallel make the configuration better or more secure? > > > > As a final point, how do you expect either the PIX or IPCop > to be able > > to do it's job? The PIX will see packets which originate from the > > server appearing with the IPCop device's IP address and so > won't know > > they relate to (are part of the same connection as) other packets > > which earlier went to the server. IPCop will never see half the > > packets (e.g. incoming requests and responses to outgoing requests) > > and so will never know if the outgoing packets relate to > connections > > have been established or to new connections, or are just spurious. > > > > I think (but I'm not a networking expert) that it'll never > fly! Maybe > > someone else can correct me? > > > > David > > > > > > There is no difference in the two GREENs above, they're both > the same, just labeled twice. The PIX is there for using > Cisco VPN (a requirement). > IPCop handles the different security zones, traffic shaping, > intrusion detection, etc. Have you tried a simple straight line? Internet <-> PIX <-> IPCop <-> Green With possibly the server hanging off IPCop on an Orange subnet? > Soon I'll have a T1 for the IPCop and the PIX will stay on a > fractional > T1 from a different carrier (for now they're on the same carrier). IPCop has a problem with two independent RED connections. You'll find lots of conversations about it in the mailing list history and some suggestions about how to cope with it. There have been some suggestions this may change in future. > The PIX should see all the packets. The packets the PIX sends > out and the replys that are forwarded back to the PIX from IPCop. The PIX does see all the packets, but the packets back from IPCop have a different source address as IPCop uses NAT, so as far as the PIX is concerned they aren't related. It sounds to me as if you are complicating the present by trying to prepare for the future change. It's beyond my simple understanding of networks and routing. I'd suggest a day or two of a networking expert may be cheaper than trial and error ... David |