Re: Using Julian Anastasov's 'routes' patches on 2.4 kernel in conjunction with IPSec

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	Hello,

On Thu, 28 Jun 2007, Seba Tiponut wrote:

> The _updown script is only called when a tunnel is brough up or down, but the 
> problem I am having is not related to a tunnel, but to routing before any 
> tunnel gets established.
> I mean that even a configuration with only one tunnel that is listening is 
> creating problems because both StrongSWAN and OpenSWAN add IP addresses on 
> the ipsecN interface that are identical to the ones on the real interface 
> (ethN). I think the problem is related to the presence of the ipsecN 
> interface in KLIPS (linux-2.4). On 2.6 kernels there is no such interface and 
> consequently there is no "conflict". Is there any real solution to this 
> problem? 

	Long time ago it was in _startklips. I used something like this:

ip link set ipsec0 down
ip addr flush dev ipsec0
# It is safe to add all local GW IPs here, always with /32
ip addr add LOCAL_GW_IP/32 dev ipsec0 scope host label ipsecXXX
ip link set ipsec0 up

or 

ifconfig ipsec0 0.0.0.0 up

should be enough. I.e. you still need some IP on ipsec devices but
don't duplicate eth networks there.

> On the other hand, my understanding of the solution you gave me (inserting a 
> rule "from LNET to RNET") is that it can be applied once the tunnel is up. 
> However, would you care to elaborate more on this case as well?

	Well, I found something in my sent-mail archives:

	You need 2 ip rules and one routing table for all ipsec devices, eg:

# The traffic between gateways is not via ipsec device, i.e.
# NORMAL_TABLE can be "main"
ip rule add prio 100 from LOCAL_GW to REMOTE_GW1 table NORMAL_TABLE

# Negotiated lnet-rnet goes via ipsec device
ip rule add prio 200 from LNET1 to RNET1 table IPSEC_TABLE
ip route add RNET1 dev ipsec0 table IPSEC_TABLE
# There is no "via LOCAL_GW" in the route

# Another tunnel:
ip rule add prio 100 from LOCAL_GW to REMOTE_GW2 table NORMAL_TABLE
ip rule add prio 200 from LNET2 to RNET2 table IPSEC_TABLE
ip route add RNET2 dev ipsec1 table IPSEC_TABLE

So, you have:

- exception rules that route the ESP traffic via its normal routing
table (ethXXX)

- negotiated nets go via ipsec devices where we do not have
gateways, plain device route

- all routes to RNETs can be in same table where all ipsec devices
are used in routes but it can be changed to have different
tables per each ipsec device (in case same RNET is negotiated
via different ipsec devices)

        There is a benefit: if the LGW box has local IP from LNET
then it can reach the RNET via ipsec device. You do this by
specifying "src LNET_IP" for all routes via ipsec devices
if you really have local IP from this lnet (which is common),
so it is better to always have "src lnet_IP" in all routes
in table IPSEC_TABLE. As result, you have all possible data
to give the right information to the routing:

- LGW are not routed via ipsec devices
- RNET sees valid lnet_IP when your gateway talks to RNET via
ipsec (allowing even masquerade for LNET boxes to be used when
talking with RNET).

	Hope that helps!

> Cheers,
> Seba.

Regards

--
Julian Anastasov <ja@xxxxxx>
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux