LARTC - Jun 2007 - Using Julian Anastasov''s ''routes'' patches on 2.4 kernel in conjunction with IPSec

Hello,

I use Julian Anastasov ''routes'' (to be more specific:
static_routes,
alt_routes and nf_reroute) patches on a 2.4.32 kernel. On the same host I run 
IPSec. I have discovered after a few hours of networking problems that,
when IPSec is enabled on that patched kernel, inspecting packets with tcpdump 
while arping-ing a host from a network physically connected to this machine, 
the arp requests show up on the ipsecX interface instead of the ethX 
interface. When IPSec isn''t running, Julian''s code works fine.
I suspect it
has something to do with having two interfaces with the same data (ipsecX 
mirroring the configuration from ethX).
Can anyone give me a hint on how could I solve this problem? I''ve
googled a
long time to no avail and I don''t have the necessary skills to debug
the
networking code from kernel.

Cheers,
Seba.

I had the same problem. Had to disable ipsec interfaces to make things
work. Though the routing rules were in correct order, packets went to
ipsec interface.
Finally, I removed the patch.
> -----Original Message-----
> From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl]
> On Behalf Of Seba Tiponut
> Sent: Monday, June 25, 2007 7:48 PM
> To: lartc@mailman.ds9a.nl
> Subject: [LARTC] Using Julian Anastasov''s
''routes'' patches on 2.4
kernel
> inconjunction with IPSec
> 
> Hello,
> 
> I use Julian Anastasov ''routes'' (to be more specific:
static_routes,
> alt_routes and nf_reroute) patches on a 2.4.32 kernel. On the same
host I
> run
> IPSec. I have discovered after a few hours of networking problems
that,
> when IPSec is enabled on that patched kernel, inspecting packets with
> tcpdump
> while arping-ing a host from a network physically connected to this
> machine,
> the arp requests show up on the ipsecX interface instead of the ethX
> interface. When IPSec isn''t running, Julian''s code works
fine. I
suspect
> it
> has something to do with having two interfaces with the same data
(ipsecX
> mirroring the configuration from ethX).
> Can anyone give me a hint on how could I solve this problem? I''ve
googled
> a
> long time to no avail and I don''t have the necessary skills to
debug
the
> networking code from kernel.
> 
> Cheers,
> Seba.
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Hello,

On Mon, 25 Jun 2007, Seba Tiponut wrote:
> I use Julian Anastasov ''routes'' (to be more specific:
static_routes,
> alt_routes and nf_reroute) patches on a 2.4.32 kernel. On the same host I
run
> IPSec. I have discovered after a few hours of networking problems that,
> when IPSec is enabled on that patched kernel, inspecting packets with
tcpdump
> while arping-ing a host from a network physically connected to this
machine,
> the arp requests show up on the ipsecX interface instead of the ethX 
> interface. When IPSec isn''t running, Julian''s code works
fine. I suspect it
> has something to do with having two interfaces with the same data (ipsecX 
> mirroring the configuration from ethX).
> Can anyone give me a hint on how could I solve this problem? I''ve
googled a
> long time to no avail and I don''t have the necessary skills to
debug the
> networking code from kernel.
	May be you have to replace your _updown script with one that
supports "ip route" and "ip rule" commands instead of the
old "route"
tool. By this way you can use "ip rule ... from LNET to RNET"
to properly route traffic for the negotiated subnets. If I remember
correctly, the default _updown script does not consider negotiated
LNET at all. As for routes patch, it will prefer NOARP devices when
the neighbours on ARP device are not marked as reachable in ARP cache.
So, it is risky to rely on wrong routes, especially after routes patch
is applied.

Regards

--
Julian Anastasov <ja@ssi.bg>

On Tuesday 26 June 2007 00:40, Julian Anastasov wrote:
> 	May be you have to replace your _updown script with one that
> supports "ip route" and "ip rule" commands instead of
the old "route"
> tool. By this way you can use "ip rule ... from LNET to RNET"
> to properly route traffic for the negotiated subnets. If I remember
> correctly, the default _updown script does not consider negotiated
> LNET at all. As for routes patch, it will prefer NOARP devices when
> the neighbours on ARP device are not marked as reachable in ARP cache.
> So, it is risky to rely on wrong routes, especially after routes patch
> is applied.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
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? 
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?

Cheers,
Seba.

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@ssi.bg>