I have a fairly standard OSPF setup in my lab that I am trying to get my head around and I need someone to explain to me what is possible without adding static routes.

Here is my current setup.
OSPF testing over wireless using NBMA

R1 (ASBR)
Gateway to internet
Default backbone OSPF
RID 10.255.255.1
Loopback: 10.255.255.1
eth0-gateway: 111.111.111.123
eth5-to-tower: 10.23.23.1/24
Area 0.0.0.0 contains networks 10.23.23.0/24 & 10.255.255.0/24
Redistribute Default Route as Type 2

R2(ABR)
Gateway to internet
Default backbone OSPF
RID 10.255.255.4
Loopback: 10.255.255.4
eth0-to-core: 10.23.23.2/24
eth5-to-client: 172.16.3.1/24
Area 0.0.0.0 contains networks 10.23.23.0/24 & 10.255.255.0/24
Area 0.0.0.1 type nssa contains networks 172.16.3.0/24
Redistribute Connected routes as Type 1

R3
Gateway to internet
Default backbone OSPF
RID 10.255.255.254
eth0-to-tower: 172.16.3.2/24
eth5-to-SOHO: 123.23.111.5/30
Area 0.0.0.1 type nssa contains networks 172.16.3.0/24 & 10.255.255.0/24 + 123.23.111.4/30
Redistribute Connected routes as Type 1

R4 (non OSPF client router)
SOHO Router running NAT
eth0-gateway 123.23.111.6/30
eth4-LAN 10.0.0.1

My goal with this setup is to get the least amount of routes possible on R3 while still pushing through any and all connected routes from R3 to R1.
What I had trouble with was getting the route for network 123.23.111.4/30 to appear in the routing table of R1
I found I had to add it into the OSPF area 0.0.0.1 for this to work when it is not really part of the OSPF network so this seems wrong to me.
If I leave it out of the Area network R1 never gets the route for 123.23.111.4/30 and I have to set a static on R1 to point to R2 for network 123.23.111.4/30. I want to see if I can avoid adding any static routes if it's possible.

I experimented with stub also but that didn't seem to achieve what I wanted either.
In this current configuration in order to make 123.23.111.4/30 work, I either have to add a static route in R1 or include 123.23.111.4/30 in R3's Area network configuration.

This seems feasible.
One thing I noticed on R2 (I think) you put 10.255.255.0/24 into both areas, which is a no-no...

NSSA is the correct area type for what you want - there cannot be an ASBR in stub area because they do not send/receive type 5 (external 1&2) LSA. NSSA uses type 7 LSA inside the area, and the ABR converts them into type 5 as they leave the area and enter area 0.

If your "soho" customers' addresses all come from a pool of addresses on R3, then you don't need every single customer's /30 WAN prefix in your routing table. R3 could advertise 123.23.111.0/24 and not need to redistribute each and every customer into the table. Of course, if a customer moves their connection off of R3, then they can't keep the same IP (unless you don't mind a /30 coming from the 'wrong place' in your routing table)

It is strange that R1 doesn't see the /30 route because on on R3 you're adding it two ways - as a native-to-OSPF network, AND as a redistribute connected. I'm surprised that neither shows up in your OSPF.
Does R2 see it?

FIrstly thanks for your reply.

One thing I noticed on R2 (I think) you put 10.255.255.0/24 into both areas, which is a no-no...

EDIT******
Just noticed this was a typo, in my lab I have 10.255.255.0/24 only in Area 0.0.0.0 on R2.
Will update the first post to reflect this

there cannot be an ASBR in stub area because they do not send/receive type 5 (external 1&2) LSA. NSSA uses type 7 LSA inside the area, and the ABR converts them into type 5 as they leave the area and enter area 0.

Well that all makes sense to me except that in my mind the ASBR is not in the sub area but in the backbone area, so even if my NSSA was a stub area the ASBR would still not be in that area. But regardless I found NSSA seems to do what I want and you said it is the correct type for what I am trying to achieve so no problems here

If your "soho" customers' addresses all come from a pool of addresses on R3, then you don't need every single customer's /30 WAN prefix in your routing table. R3 could advertise 123.23.111.0/24 and not need to redistribute each and every customer into the table. Of course, if a customer moves their connection off of R3, then they can't keep the same IP (unless you don't mind a /30 coming from the 'wrong place' in your routing table)

Well I will be splitting the subnet 123.23.111.0/24 up all over my network so this is not really an option, but it doesn't make any difference as I would still need to get 123.23.111.0/24 or 123.23.111.5/30 into the routing table of R1

t is strange that R1 doesn't see the /30 route because on on R3 you're adding it two ways - as a native-to-OSPF network, AND as a redistribute connected. I'm surprised that neither shows up in your OSPF.
Does R2 see it?

R1 does see it, perhaps I didn't explain clearly. R1 only gets the route IF I put the network "native-to-OSPF network" as you said. (this is fine and works but just seems wrong to me which is why I made this thread to ask for advice)
If I don't add it to the OSPF area networks for the NSSA then yes R2 gets it, but R1 never gets it. Even if I select "Redistribute other OSPF routes" on R2, R1 still does not get the 123.23.111.5/30 route.
So for my configuration to work I either have to add a static route on R1 pointing 123.23.111.5/30 to R2 or I add 123.23.111.5/30 to the OSPF area 0.0.0.1 network

So for my configuration to work I either have to add a static route on R1 pointing 123.23.111.5/30 to R2 or I add 123.23.111.5/30 to the OSPF area 0.0.0.1 network

Hmmm - I just saw something interesting on my own router.
I went to add an NSSA area. According to the documentation, Translator Role defaults to "translate candidate" where OSPF chooses which router is responsible to translate type 7 LSA (redistributed routes inside the NSSA) into type 5 LSA (external routes outside of the NSSA). This is crucial, otherwise it's just a stub area by another name.

My router, though, defaulted to translate never. (v6.27)
It didn't change even after I made it an ABR.

Check your area configuration on R2 and try setting it to candidate or even to always.

That should fix it, and if it does, you should send a bug report.

Ok I just tested by changing to translate "candidate" and Voila

Working as expected!!

Thank you ZeroByte this is awesome, kinda expected it to be something simple I had missed.

One final question.

Should I be redistributing connected as Type 1 or Type 2 in this example?

Should I be redistributing connected as Type 1 or Type 2 in this example?

That depends on your network design.
Normal routes add cost for each link traversed in calculations.
Type 1 externals start with whatever metric they're redistributed with, and then add internal costs also.
(like - cost to reach GW plus the "outside ospf cost")

Type 2 means "really far past OSPF border" - so no internal cost adds. If metric is 20, it is 20 everywhere. If 2 equal routes with type 2 have the same metric, then the route to the closer of the two origins wins.

Internal route always chosen over external.
Type 1 External always chosen before 2.

I usually use 1 for redistributed customer routes, and 2 for default GW.
(I think these are the defaults anyway)

Thanks again