Ipsec routing

tdi

Current setup:

(10/8)
box A –--------------- box C -----LAN 10.2/24
| (10.2/16)
box b |
(10.1/16) OPT1
----|---- 10.2.1/24
| |
LAN OPT1
10.1/24 10.1.1/24

box A local net is 10/8 since it should connect to other pf boxes (box C 10.2/16),
box B has 10.1/16 with LAN on 10.1.0.1/24 and OPT1 on 10.1.1.1/24.

Problem:
As soon as ipsec goes up it is not possible to reach subnets from other interfaces on the same box.
From LAN it is not possible to connect to hosts on OPT1 and vice versa. This goes for both A and C.
I guess traffic destined for the other network gets tunneled to box A?

How to make this scenario work (box B 10.1/16 <-> box A 10/8 <-> box C 10.2/16) ?

Thanks.

hoba

You have to use either bigger subnetmasks for the tunnels to sum up the networks or use parallel tunnels. This has been answered in oother threads before. Please search.

tdi

Thanks for your reply Hoba,
sorry for posting same stuff again, I did search before but apparently don't get it.
Maybe I did not explain very well…

Box B sums its networks as well as box C since both LAN/24 and OPT/24 networks are part of what B/C advertise as its local end of ipsec tunnel.
Tunnels between A and B/C are local: 10/8, remote: 10.x/16 and this works fine.

Traffic is tunneled between A <-> B <-> C, but not between LAN and OPT interfaces on the same box (B/C).
Hosts from LAN network on B cannot contact hosts from OPT network on B. Same goes for C.

Could you please explain bigger masks for the tunnels or provide simple working example?
Do I have to use only one network behind B (10.x/22)?

Thank You

hoba

simple example:

local subnet at A
192.168.1.0/24

local subnet at B
doesn't matter

local subnet at C
192.168.2.0/24

now create tunnels between A-B:
A 192.168.1.0/24 - B 192.168.2.0/24 (note that this is not the local subnet at B but the one of C)

tunnel between B-C:
B 192.168.1.0/24 - C 192.168.2.0/24 (note that B uses the local subnet of A for it's end of the tunnel)

This way you can route traffic from A to C via B.

Even easier:

A-B:
A 192.168.1.0/24 - B 192.168.0.0/16

B-C:
B 192.168.0.0/16 - C 192.168.2.0/24

sounds like a conflict but will work just fine. Now B acts as concentrator for all 192.168.x.x subnets. I have a setup like this with 14 locations by now where all traffic gets routed through one central location.

tdi

Hey, thanks for a quick answer.
However, I don't think you really understood my problem.

There is no problem in contacting remote hosts in subnets at the other end of the tunnel(s), so tunnels do their job just fine and traffic is routed just as you said.

Problem is marked in red.
Once the tunnel is up between B and A, hosts from LAN subnet on B cannot contact hosts from OPT1 subnet on B (and vice versa).

So, bringing the tunnel up enables me to contact hosts on the other ends of the tunnels, but at the same time disables "local" traffic between two interfaces on the same box.

Could it be that it is sent to box A because of the ipsec "remote network" and if so, what can be done to make this setup work?

Thanks again!

hoba

I think locally attached subnets should have priority. Maybe try a smaller subnetmask at the remote end to exclude the two local subnets. A Traceroute should show you where the traffic gets send while the tunnel is up.

tdi

@hoba:

I think locally attached subnets should have priority…

So did I, but it seems that ipsec takes over as soon as the tunnel is up. Is it possible to change this behavior so that locally attached subnets indeed have priority regardless of ipsec tunnel rules? I am not sure if this qualifies as a feature request or bug?

kamik

No matter of priority between IPSEC and local atached network (it seems that IPSEC gets over locals). I think U have to play more with subneting/superneting techniques.

The problem is that 10/8 on A you have to use eg 10.2.0.0/15 which includes 10.2/24 and 10.3/24 networks:

(10.2/15)
box A <–-(tun A-C)---> ipsec to other networks, works fine
A
|
(tun A-B)
|
V
box B
(10.1/16)
----|----
| |
LAN OPT1
10.1/24 10.1.1/24