[Openswan Users] routing issues

[Harald Scharf]

Hello, List!

 

I had posted this issue some days ago:

If you set the defaultroute to your VPN (for example: leftsubnet=0.0.0.0/0), any local routing is ignored.

 

This setup is not unusual, and it becomes more important in future, because 

when you have a central site, many admins want to have ONE point for internet access (and not on any vpn box in their environment).

 

So, they have to route all the unknown traffic through the tunnel.

And this is the point: UNKNOWN Traffic.

Why does OpenSwan (Netkey) ignore ANY local routing?

When the default gw is set to ipsec

a)       the local interfaces on the VPN box are no longer reachable

b)       local attached subnets are no longer routed (for example a DMZ on the VPN box)

c)       any other local routes (host / network routes with external gateways) are simply ignored

 

Well, I got this working, but with really ugly stuff:

ip xfrm policies (10 for only two interfaces)

 

 # used to reach the local private interfaces1, after the tunnel with 0/0 comes up

 ip xfrm policy add dir in src subnet1 dst subnet1

 ip xfrm policy add dir out src subnet1 dst subnet1

 

# used to reach the local private interfaces2, after the tunnel with 0/0 comes up

 ip xfrm policy add dir in src subnet2 dst subnet2

 ip xfrm policy add dir out src subnet2 dst subnet2

 

# used to get traffic passed from subnet1 to subnet2 and reverse

 ip xfrm policy add dir in src subnet1 dst subnet2

 ip xfrm policy add dir out src subnet1 dst subnet2

 ip xfrm policy add dir in src subnet2 dst subnet1

 ip xfrm policy add dir out src subnet2 dst subnet1

 ip xfrm policy add dir fwd src subnet1 dst subnet2

 ip xfrm policy add dir fwd src subnet2 dst subnet1

 

This did work only for local routes (with the interface on the VPN Box)

If routing is needed for "external" routes, only the iptables ROUTE patch did help:

 

 Iptables -I PREROUTING -t mangle -j ROUTE -s mysubnet1 -d myremotesubnet -oif interface to subnet with router

 

Only the combination of this two workarounds made the vpn system route correctly (what I can say at the moment).

 

In other discussions, the type=passthrough policy was mentioned.

I tried with several combinations, but the result was the same on every try: This policy did not do anything.

 

So, what I want to know:

Has anyone out there implemented a netkey system with a really large routing table and the default route to the VPN?

In my opinion, this can not be handled reliable at the moment.

 

Why does the netkey stack put an ipsec policy on any interface? 

This issue does not appear under klips, because of the interfaces="ipsec0=ethX" parameter, right?

 

Isn´t it possible, to leave the private interfaces policy free? This should completely eliminate such issues (does it?)

Is it possible, to remove the created polices after ipsec has been started?

 

Any suggestions will be highly appreciated.

 

 

King regards

 

Harald

 

 


NESTEC - Die IT Security & Messaging Distribution mit Persönlichkeit
GFi Software - BitDefender - NOD32 - BRICKS ISS - pdfMachine
2X Terminal & ThinClient Solutions -Accunetix
Besuchen sie uns: www.nestec.at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070425/11f2e4cc/attachment-0001.html