Community discussions

MikroTik App
 
marix
just joined
Topic Author
Posts: 6
Joined: Fri Sep 21, 2012 3:23 pm

IPSEC DST address 0.0.0.0/0 with hub/spokes and interconnect

Wed Feb 12, 2014 12:02 pm

I have an issue with IPSEC.
We have started replacing older routers running OpenBSD for Routerboard RB750GL.
Smaller, neater, less that can break.
But one of the things when using OpenBSD on all nodes, was that is more or less just worked as intended, without much hassle.

I have simplified the setup below, there are many many more nodes in reality.

VPN GW
----------
OpenBSD
WAN: 1.1.1.1
LAN: 192.168.0.1

VPN Node 1
----------
OpenBSD
WAN: 2.2.2.2
LAN: 192.168.1.1

VPN Node 2
----------
RouterBoard RB750GL
WAN: 3.3.3.3
LAN: 192.168.2.1

Each Node is connected to the GW.

Node 1 <-> GW <-> Node 2
The SRC. Address of each node is its Lan/24, and the DST. Adress is 0.0.0.0/0, so everything is routed thru the IPSEC.
The issue is that when there where no Routerboards There was also another link.
Node 1 <-> Node 2
So traffic between 192.168.1.0/24 <-> 192.168.2.0/24 used this link, and did not go over the GW.
Easing the load when branches speak.

But with multiple Policies and require/uniqe configuration on the policies, different priorites, the second connection for the inter node connection is never established.
Since of course 0.0.0.0/0 covers the address space, why should it.

And even if I used 192.168.0.0/16 instead of 0.0.0.0/0 the same problem would be true.

Each Policy/peer/proposal on its own, workes as intended. But togehter only the connection to the GW is used.

Tehre are also NAT rules to bypass Masquerade for each policy.

Any ideas / sugestions?

For testing purposes I have setup Two RB750GL connected to a OpenBSD GW, to test solutions on, I have attached a compact export of these.
External IPs Redacted, but the PSK is in there, if you want to go hunting ;)
You do not have the required permissions to view the files attached to this post.
Last edited by marix on Wed Feb 12, 2014 2:22 pm, edited 1 time in total.
 
User avatar
tomaskir
Trainer
Trainer
Posts: 1162
Joined: Sat Sep 24, 2011 2:32 pm
Location: Slovakia

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and itnercon

Wed Feb 12, 2014 1:51 pm

It seems you are hitting a routing issue more than an IPSec issue.

IPSec in tunnel mode (how you are using it), does not route traffic, it only encrypts traffic based on a set of policies.
How traffic is distributed is handled by the routing engine. IPSec only looks at the traffic, and encrypts based on the policies.
 
marix
just joined
Topic Author
Posts: 6
Joined: Fri Sep 21, 2012 3:23 pm

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and intercon

Wed Feb 12, 2014 2:26 pm

Yes, that might be true. But currently the only route for 0.0.0.0 is the default gw, so that does not direct the traffic into the tunnel either.
So what would the route be to force some traffic to a different ipsec?
I know for instance some Zyxel USG stuff supports selecting ipsec tunnels in its routing setup.
Should it just be the other ends .1 as gateway for that /24 ?

In Openbsd all routing is setup by the ipsec..
 
JJCinAZ
Member
Member
Posts: 475
Joined: Fri Oct 22, 2004 8:03 am
Location: Tucson, AZ

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and intercon

Wed Feb 12, 2014 3:44 pm

You could try using GRE tunnels with IPSec transport mode protecting the GRE traffic. Then you could use routing as you expect. You can even use ospf to automatically manage your routes.
 
User avatar
tomaskir
Trainer
Trainer
Posts: 1162
Joined: Sat Sep 24, 2011 2:32 pm
Location: Slovakia

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and intercon

Wed Feb 12, 2014 3:48 pm

In your particular setup, there is no need to run a tunneling protocol.
You will just need to setup the routing table right.

Just add routes to the /24s into the routing table, with the GW as the IP of the outside interface of the router terminating that /24.
Or, use OSPF to take care of all the routing.

If you want more exact help, can you give us a more detailed topology, with a drawing if possible?
 
marix
just joined
Topic Author
Posts: 6
Joined: Fri Sep 21, 2012 3:23 pm

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and intercon

Wed Feb 12, 2014 6:26 pm

Heres a quick sketch.

Image

Purple, Blu & Red are IPSEC.
Green is exit from all connected networks to 0.0.0.0/0

Purple and Blue works as intended.
Red will not connect to get direct traffic between Node 1 and 2 without going tru GW.

And yes, there needs to be a tunnel, otherwise routing between two private networks with the Internet between them is a bit hard. And no, that tunnel does not need to be encrypted, but a tunnel is a tunnel, with or without it :).
 
marix
just joined
Topic Author
Posts: 6
Joined: Fri Sep 21, 2012 3:23 pm

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and intercon

Mon Feb 17, 2014 6:43 am

Guessing that didnt help anything.
 
vinay05
just joined
Posts: 2
Joined: Thu Sep 16, 2021 5:41 am

Re: IPSEC DST address 0.0.0.0/0 with hub/spokes and interconnect

Thu Sep 16, 2021 6:22 pm

Hello,

I have following architecture:

On-premise (172.17.0.0/16) MicrkroTik router <-------- IPSEC Tunnel (BGP based)-------> CISCO CSRv in a PublicCloud (192,168.0.0/16)

In order to establish BGP session and end to end connectivity I have add ed following two policies:

====================
Policy 1 for BGP peers :

add dst-address=169.254.22.78/32 level=unique peer=peer1 proposal=Cloud-proposal \
src-address=169.254.22.77/32 tunnel=yes


Policy 2 for end to end connectivity:

add dst-address=192.168.0.0/16 level=unique peer=peer1 proposal=Cloud-proposal \
src-address=172.16.0.0/24 tunnel=yes
====================

NOW THE ISSUE HERE IS :

- On PublicCloud side it's a route based tunnel so, IPSec policy is limited to single security association so, it is causing connectivity issues. For some reason we can not modify anything on Cloud side of the tunnel.

- When I am propose following single policy (which covers both BGP peer ranges and on-premiise & Cloud network ranges) tunnel works perfectly fine but it is causing some internal routing issues on on-premise side.

add dst-address=0.0.0.0/0 level=unique peer=peer1 proposal=Cloud-proposal \
src-address=0.0.0.0/0 tunnel=yes

ASK:

- Could you please advice me how to avoid internal routing issues without removing ipsec policy with 0.0.0.0/0 and without changing BGP peer ranges.

Thank you

Who is online

Users browsing this forum: JDF, johnson73, ramirez and 71 guests