I’m currently experimenting with running OSPF over GRE/IPsec
IKE Phase 1 between 2 routers (R1 & R2) public IP addresses, PPPoE client interface - established
IKE Phase 2 IPSec (R1) 10.5.0.0/16 ↔ (R2) 10.0.0.0/16 - established (this works fine and has done for some time)
GRE Tunnel established:
(R1) interface address 192.168.10.1/30 tunnel local: 10.5.0.254 remote: 10.0.0.254
(R2) interface address 192.168.10.2/30 tunnel local: 10.0.0.254 remote: 10.5.0.254
OSPF peer-to-peer link established between (R1) 192.168.10.1 & (R2) 192.168.10.2
OSPF connected routes (with filters) exchanged between routers:
172.25.5.0/24 - connected route on R1, OSPF route via 192.168.10.2 reachable via GRE interface on R2
172.25.0.0/24 - connected route on R2, OSPF route via 192.168.10.1 reachable via GRE interface on R1
Tried to ping dst: 172.25.0.254 from src: 10.5.1.5
Using Torch on both R1 & R2, I see OSPF passing over the GRE interface, but I do not see the ICMP traffic from 10.5.1.5 on either router.
If I check the VLAN interface for 10.5.0.0/16, I see the traffic arriving on R1.
Any ideas? Am I missing something? Trying to achieve the impossible?
P.S. I have successfully established routing over OSPF between a direct physical Ethernet connection of R1 & R3..
R1: 192.168.32.1/30
R3: 192.168.32.2/30
10.5.0.0/16 on R1 has two way traffic flow with 192.168.100.0/24 on R3, connected routes exchanged both ways (with filters) between R1 & R3. R1 also advertising default route to R3 which is working.
So it seems I can manage OSPF over a direct connection, but when I try to add a tunnel into the mix, I’m failing…
The path I was trying to use for source and destination had asymmetric routing. The ICMP echo-request packets would pass over the GRE tunnel as expected, but the echo-reply responses would have gone through the existing Phase 2 definition on the IPSec tunnel.
Tested using source and destination subnets not associated with the existing Phase 2 and it’s now working as expected.
That’s late nights on a weekend after a long work week for you!
Hello! I would like to do the same. This is my configuration: https://pastebin.com/QRAhCLT2
When i redistribute routes from one side the GRE tunnel disconnects.
What can be wrong ? Thank you for any help in advanced:)
You need to add route filters so that the local and remote addresses for the gre tunnel at both ends are not advertised out/received in as an OSPF route. You want them connected routes on each end only.
I think that’s correct - in mine I do not specify protocol=OSPF but I’m sure thats fine. I’m reading your post/config from my phone so a little hard to follow.
Let me take a look again at your config when in front of the PC and I’ll post back. I think my GRE tunnel might have a slightly different configuration to yours.
First things first, I’m making the assumption here that your IPsec Phase 1/2 policy is working and you can ping between the two? Although I would note you seem to have a mis-match between a /30 and /32 mask. You really want the GRE tunnel interface on each side to have no smaller than a /30.
I think you may have a couple of different issues here…
I would suggest setting up a Bridge with no member ports and assigning an IP address to this (replicates a loopback interface on, for example, a Cisco router) - you should in theory be able to use a /32 mask for this. Use this for the local and remote IP addresses for the GRE tunnel on each side. It appears that you haven’t configured the local address and the remote address is obfuscated in your output, therefore I’m assuming this isn’t a private address running over the IPsec tunnel.
You need to filter out the Bridge IPs you are using for the GRE tunnel from OSPF. It’s also worth filtering out the default route and your WAN next hop address.
See some relevant portions of my config from one side below - hopefully gives you something to go on:
/ip ipsec policy
add dst-address=192.168.255.4/30 peer=xxx proposal=xxx sa-dst-address=
xx.xxx.xxx.xx sa-src-address=xx.xxx.xxx.xxx src-address=192.168.255.0/30
tunnel=yes
/interface bridge
add name=GRE_for_OSPF
/ip address
add address=192.168.255.1/30 interface=GRE_for_OSPF network=192.168.255.0
add address=192.168.10.1/30 interface=ospf_gre network=192.168.10.0
/interface gre
add local-address=192.168.255.1 name=ospf_gre remote-address=192.168.255.5
/routing ospf instance
set [ find default=yes ] distribute-default=if-installed-as-type-1 in-filter=
xxx-In name=xxx out-filter=xxx-Out redistribute-connected=as-type-1
redistribute-other-ospf=as-type-1 router-id=192.168.10.1
/routing ospf network
add area=backbone network=192.168.10.0/30
/routing filter
add action=discard chain=xxx-In prefix=0.0.0.0/0 (default route from remote router)
add action=discard chain=xxx-In prefix=xx.xx.xxx.xxx (PPPoE client WAN interface remote/default route next hop address on remote router)
add action=discard chain=xxx-In prefix=192.168.2.0/24 (DSLmodem management eth1 remote router)
add action=discard chain=xxx-In prefix=192.168.88.0/24 (Default MT IP on default bridge - remote router)
add action=discard chain=xxx-In prefix=192.168.255.4/30 (Bridge for GRE on remote router)
add action=discard chain=xxx-In prefix=xxx.xxx.xxx.xx/29 (public IPs on remote router)
add action=discard chain=xxx-Out prefix=0.0.0.0/0 (default route from local router)
add action=discard chain=xxx-Out prefix=xx.xx.xxx.xxx (PPPoE client WAN interface remote/default route next hop address on local router)
add action=discard chain=xxx-Out prefix=192.168.2.0/24 (DSL modem management eth1 on local router)
add action=discard chain=xxx-Out prefix=192.168.88.0/24 (Default MT IP on default bridge - local router)
add action=discard chain=xxx-Out prefix=192.168.255.0/30 (Bridge for GRE on local router)
add action=discard chain=xxx-Out prefix=xx.xxx.xxx.xxx/29 (public IPs on local router)
/ip firewal filter
add action=accept chain=input comment=OSPF dst-address-list=OSPF protocol=
icmp src-address-list=OSPF
add action=accept chain=forward dst-address-list=OSPF protocol=icmp
src-address-list=OSPF
add action=accept chain=output dst-address-list=OSPF protocol=icmp
src-address-list=OSPF
add action=accept chain=input dst-address-list=OSPF protocol=ospf
src-address-list=OSPF
add action=accept chain=forward dst-address-list=OSPF protocol=ospf
src-address-list=OSPF
add action=accept chain=output dst-address-list=OSPF protocol=ospf
src-address-list=OSPF
add action=accept chain=input dst-address-list=OSPF protocol=igmp
src-address-list=OSPF
add action=accept chain=forward dst-address-list=OSPF protocol=igmp
src-address-list=OSPF
add action=accept chain=output dst-address-list=OSPF protocol=igmp
src-address-list=OSPF
/ip firewall address-list
add address=224.0.0.1 list=OSPF
add address=224.0.0.5 list=OSPF
add address=224.0.0.6 list=OSPF
add address=192.168.10.0/30 list=OSPF
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.255.4/30 src-address=
192.168.255.0/30
add action=accept chain=srcnat out-interface=ospf_gre
Based on my experience until I got it right, it feels likely to be an issue on your route filters allowing a particular connected route to be advertised to the neighbour upsetting the GRE tunnel.
When the tunnel drops, so does OSPF so the routing is restored… GRE comes up, route is advertised…and repeat!
Are you using a RFC1918 private address of some form for the local and remote addeess of the GRE tunnel? Your pastebin upload didn’t specify a local address and you had edited out the remote address…
If you don’t have any conflicting subnets, try using exactly the addressing in my config and see if it works for you…then track back from there through your config until you get your desired addresses working.
So you want the “loopback” bridge addresses to be on different subnets on each router. The addresses assigned to the tunnel itself can be on the same /30
You want the bridge addresses to be filtered out of OSPF on both sides.
So in my config…
Router 1: 192.168.255.1/30 - bridge
Router 1: 192.168.10.1/30 - GRE
Router 2: 192.168.255.5/30 - bridge
Router 2: 192.168.10.2/30 - GRE
Route filters..
Router 1
In discard 192.168.255.4/30
Out discard 192.168.255.0/30
Router 2
In discard 192.168.255.0/30
Out discard 192.168.255.4/30
If you have more than one instance you can have more than one chain of rules - check you are applying the correct one.
I checked them. There is a next hop 10.0.0.1 on the HEX side, when i filter with:
/routing filter
add action=discard chain=GRE_OSPF_IN prefix=10.0.0.1 ( This works perfectly )
add action=discard chain=GRE_OSPF_IN prefix=172.16.1.0/30 ( It does not work )
add action=discard chain=GRE_OSPF_OUT prefix=172.16.1.0/30 ( It does not work )
There’s quite a few variables here that could be tripping you up and it’s hard to spot the issue without being able to look at both router configs side by side at the same time..
Can you post full configs from both sides, redacting any sensitive info such as passwords, shared keys, public IPs etc? Try not to redact any internal private addressing if you can.
OK, I think your problem is the IP you have assigned to the bridge on each side is from the same subnet (172.16.1.0/30). It needs to be on a different subnet on each router.
You can keep the same IPs but you’d need to make the addresses /32 masks. If that doesn’t work, use 172.16.1.0/30 and 172.16.1.4/30 networks with IPs of 172.16.1.1 and 172.16.1.5
Update the IP assigned to the bridges, then your IPsec policies, route filters and the local/remote address for the GRE tunnel on each side
