On Thu, Jul 17, 2008, Timothy Selivanow wrote:
>On Thu, 2008-07-17 at 00:03 -0700, Bill Campbell wrote:
>> I am attempting to create an ipsec tunnel between two CentOS 5.1
>> systems, network-to-network with two different 192.168.xxx.0/24
>> LAN segments.
><snipped>
>
>As someone who has a similar setup to what you are wanting, it sounds
>like either the route, or a problem with the SRCGW/DSTGW. If your two
>networks are 192.168.100.0/24 and 192.168.200.0/24 for sites A and B,
>respectively, with public IPs 1.1.1.1 and 2.2.2.2 (respectively, again),
>then you will want something like the following:
>
>Site A ifcfg-ipsec0:
>TYPE=IPSEC
>SRCGW=192.168.100.1
>DSTGW=192.168.200.1
>SRCNET=192.168.100.0/24
>DSTNET=192.168.200.0/24
>DST=2.2.2.2
>
>Site B ifcfg-ipsec0:
>TYPE=IPSEC
>SRCGW=192.168.200.1
>DSTGW=192.168.100.1
>SRCNET=192.168.200.0/24
>DSTNET=192.168.100.0/24
>DST=1.1.1.1
These are the same as what I have with the appropriate IP and
CIDR blocks.
>You will want to make sure that no NAT'ing is occurring for traffic that
>wants to flow from site A to B (and vice-versa). I also have a static
>route set up, as I was having some problems with it automatically
>setting when the ipsec "interface" was set up. For this example, I'm
>assuming that both Site A and B have two physical interfaces, eth0 and
>eth1, that have the public and private addresses.
It each case these are machines that are directly connected to
the Internet with no NAT.
>Site A interfaces:
>eth0: 1.1.1.1
>eth1: 192.168.100.1
>
>Site B interfaces:
>eth0: 2.2.2.2
>eth1: 192.168.200.1
>
>Site A route-eth1:
>192.168.200.0/24 via 192.168.100.1
>
>Site B route-eth1:
>192.168.100.0/24 via 192.168.200.1
>
These are equivalent.
It appears to me that the ``ifup ipsec0'' command primarily wakes
racoon up to modify the /etc/racoon/racoon.conf file with the
appropriate include and to set the route, and ``ifdown'' mostly
removes the route.
>On a closing note, you are correct in observing that there is no longer
>an "ipsec0" or similar interface. I started to explain why...but it got
>too long. If you would like a crash course on kernel IPSec behaviour,
>let me know and I'll write up a short one with some further reading
>linked.
I would be very interested in this.
After letting things sit overnight, and seeing ``IPsec-SA
expired'' messages in /var/log/messages, I tried again this
afternoon. without success. There are some things that seem
noteworthy to me.
1. There was no traffic between the machines until I started ``tcpdump''
on one, at which time it initiated the handshaking with the machine
here (one machine is here on M.I. the other in Kansas City).
2. When racoon starts, there is a message in /var/log/messages,
``racoon: ERROR: racoon: MLS support is not enabled''. I haven't
been able to figure out what that means.
3. The Kansas City machine is running kernel 2.6.18-53.1.14.el5 SMP,
x86_64.
4. The M.I. machine is running 2.6.18-53.1.21.el5PAE SMP i686...
5. The M.I. machine hosts several VMware virtual machines so both its
NICs are in promiscuous mode.
Bill
--
INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
Perhaps, when committing your first federal crime, it would be unwise to
slap your name and address on it and mail it to 10,000 people. --Dogbert