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. I have gone through the documentation on the centos web site, and have the machines to the point where the /var/log/messages show ``IPsec-SA established'' on both machines after runnig ``ifup ipsec0'' (same ipsec0 on each machine).
IP forwarding is configured in /etc/sysctl.conf and in the proper /proc ``file''.
``netstat -rn'' shows a reasonable looking route on each machine with the gateway as the private IP for the internal LAN.
The iptables on each machine are totally clear with no filters.
Attempting to ping the private interface on the remote machine results in this where the xx.xx... is the IP address of the public LAN.
From xx.xx.xxx.xxx icmp_seq=2 Destination Host Unreachable
Running tcpdump on another Linux box on the remote network that is our main connection to the internet so sits between the remote machine and our T1 does not show any packets from the machine attempting to ping the remote or attempting to make an ssh connection to the remote machine's private IP.
At this point I'm at a loss as what to try to debug this. My previous IPsec experience was with Freeswan on an older SuSE box which is quite different in the system setup. The centos/rh documentation is not totally clear what IP is meant by SRCGW, but looking at the ifcfg-ipsec script, it assigns the private IP of the internal network NIC if SRCGW is not set.
I expected to see an ``ipsec0'' device from ``ifconfig'', as was done with freeswan, but either that's not the case with ipsec-tools or I have something hosed.
Bill
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
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.
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
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 hope this helps.
--Tim
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
Following up on my own post with some new information and puzzler:
On Thu, Jul 17, 2008, Bill Campbell wrote:
On Thu, Jul 17, 2008, Timothy Selivanow wrote:
...
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.
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).
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.
The Kansas City machine is running kernel 2.6.18-53.1.14.el5 SMP, x86_64.
The M.I. machine is running 2.6.18-53.1.21.el5PAE SMP i686...
The M.I. machine hosts several VMware virtual machines so both its NICs are in promiscuous mode.
I tried setting up a different machine here on M.I. to connect, changed the remote IP on the Kansas City machine, and am able to create a tunnel, ping, and ssh from M.I. to K.C., but cannot do any of these from K.C. to M.I.
There are *NO* iptables rules on either machine at present. To the best of my knowledge there are no IP filters between the Internet and these machines. The one in K.C. is a DSL modem on a /29 net block while the connection here is via an Integra/Eschelon Adtran channel bank to a T1 to our 192.136.111.0/24 block.
I cannot understand how a connection works one way, but not the other on what is supposed to be symmetric.
Bill
-
Bill Campbell -
Timothy Selivanow