ipsec-tools/racoon/ipsec routing problem

[James McDonald]

Bill Campbell wrote:
> I have been trying to get ipsec connecting various CentOS 5.1
> systems, and gotten things working -- almost with some help from
> people on a CentOS mailing list.  The issue I have now is that it
> appears that the tunnel between the systems is complete, and I
> can ping and connect with ssh from one machine to the other, but
> not the other way around.
>
> The /etc/sysconfig/network-scripts/*-ipsec0 files on each
> machine are essentially the same with the SRC and DST values
> reversed and the DST set to point to the public interface of the
> other machine.  The /etc/racoon files look reasonable, as doe the
> output of ``netstat -rn'' or ``ip route list'' with the route to
> the remote LAN pointing the the IP of the private NIC in each.
>
> Both machines have public IP addresses (no NAT), but the machine
> that cannot ping or connect to the other is doing NAT for its
> private network.
>
> I have flushed all rules from iptables to be sure that traffic is
> not being blocked.
>
> It appears to be a routing problem on the machine that cannot
> connect as ping or ssh attempts from it to the other system
> result in ``No route to host'' or ``Network not available'', even
> when I have an ipsec connection from the remote end to that
> machine.
>
> I have compared ``lsmod'' output from the systems, and the only
> thing that looks suspicious are these modules which are found on
> the system that cannot get out to its remote partner.  NAT is not
> active while testing in at least one case, having been turned off
> when flushing the normal iptables rules we use.  This suggests to
> me that some specific iptables rules may be necessary to get the
> outbound routing corrrect.
>
> 	ip_conntrack
> 	ip_nat
> 	ipt_MASQUERADE
> 	ipt_REDIRECT
> 	iptable_mangle
> 	iptable_nat
>
> FWIW, I did one test after making a connection to a machine where
> I ran ``ipdown ipsec0'' on the machine to which the connections
> worked, and could still ping it from the remote even though the
> route had been dropped.  An active ssh connection stopped working
> when the route went down, but worked again after ``ifup ipsec0''
> on the remote.
>
> Can anybody on this august list shed some light on this?
>
> Bill
>   
Bill, I have just been through this whole thing myself. I had to insert 
some nat rules to stop the NAT working for the source and destination 
subnets.

For example.
Your setup perhaps is

10.1.2.0/25>-<10.1.2.254 linux NAT gateway 
220.233.0.9>------internet-----<22.23.24.2 linux gateway 
192.168.13.254>--<LAN 192.168.13.0/24

On the gateway that is doing nat ( the left gateway above) you want to 
tell it that if you are sending to the remote subnet you need to bug out 
of the nat chain if you are sending to the remote LAN _without_ doing 
any nat. Otherwise your packets will be getting porked with the SNAT on 
your external int.

$IPTABLES -t nat -A POSTROUTING -d 192.168.13.0/24 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -d 192.168.13.0/24 -j ACCEPT

I presume you are using the ifcfg-ipsec0 setup so you can do ifup and 
down... which handles the routing / racoon setup...

Ifound the troubleshooting link at http://ipsec-tools.sourceforge.net/ 
helped.

Also a nice graphical centos helper for ipsec setup here ....

http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-ipsec-net2net.html#