I have a similar problem with Double NAT. Only my providers router does not support creating manual routes. So the solution of disabling Masquerading and creating a route on the upstream router is not possible for me.
Would it be possible to put both routers in the same subnet?
I'm not sure why the routes aren't showing up.
Do you have a spare OpenWrt device? You can use that to experiment with all of this stuff without taking any of your primary systems offline.
But, I still don't really think it makes sense to be worrying about static routes except for the academic element here (given your CG-NAT situation).
@SnackExtra - your question is considerably different than the OP's, so a new thread would really be best.
But to answer your question -- If you cannot put static routes on the upstream router, your options are a) double NAT, or b) dumb AP (this puts the OpenWrt router on the same subnet as your main router, and doesn't use any of the routing/firewall features of your OpenWrt device).
If I set the source IP from auto to either of the options given (WAN IP or LAN IP) then the route shows up. So I think it's maybe a setting I'm missing?
Also isn't that active route 0.0.0.0/0 to ISP gateway problematic?
@SnackExtra what about bridge mode? This seems to solve a lot of problems but isn't easy / recommended to set up in OpenWrt apparently. I used this for ages with my Huwaei B818-263 which I should sell now.
No, this is the default route. 0.0.0.0/0 means all IP addresses. Except for those with static routes defined.
just call your isp, i had this same problem, tell them to give you a public ip address
my internet is also LTE. nothing would help the double nat you’ll still show as moderate in online games unless you call them
@trendy any clue why these entries:
config route
option target '192.168.1.0/24'
option gateway '192.168.0.2'
option table 'default'
option interface 'lan'
config route
option target '192.168.2.0/24'
option gateway '192.168.0.2'
option table 'default'
option interface 'lan'
don't result in me being able to ping downstream router (192.168.1.1) from my upstream router (192.168.0.1), which has assigned static IP to downstream router as 192.168.0.2?
Use defaults, table main and unicast type of packets for a start.
Thanks that worked! Actually seems like everything works now, albeit I need to do some more testing.
Why does unspecified leaving the table unspecified and the type as anycast not work? It seems to show up as expected on my routing table when I do that, but maybe I'm missing something.
I don't follow you, the defaults are main (254) table and unicast type. This covers most of the cases needed for static routes. I didn't read the whole thread to understand why were anycast and some other table suggested, but they were strikingly wrong for such a simple use case.
@trendy I am interested too about this - why is specifying the interface, main table and not default table, and unicast rather than multicast appropriate?
@psherman, I am extremely grateful for your insight and persistence in helping me in this thread. Further to @mk24's well-written outline, your insights concerning masquerading were a key part of the jigsaw for me, and especially this post below (which I have marked as the solution for this thread):
@trendy - feel free to send me a PM if this is better discussed separately (don't want to clutter this thread)...
I realize that the anycast option isn't necessary, but does it cause problems (vs unicast)?
I see this added to the main table when I add the following:
config route
option target '192.168.2.0/24'
option gateway '10.0.22.10'
But the table is unspecified in the Advanced Settings tab for the LuCI interface and obviously this is not included in the code snippet (I could add option table 'main', but it seems it is not required on my config)
... so my question is why does the table need to be specified in @Lynx 's case, whereas when I implement it on my device it is not required?
Regarding main vs default routing tables, the answer is in the output of ip rule ls and that default table is usually empty.
The anycast option is a special type to be used in case of anycast address, as described in the wiki.
To be able to see it in routing table, you need to add it properly:
network.@route[10]=route
network.@route[10].interface='lan'
network.@route[10].target='172.18.19.1'
network.@route[10].type='anycast'
network.@route[10].table='local'
...
root@barracuda:[~]#ip -4 ro list table local
...
anycast 172.18.19.1 dev br-lan proto static scope link metric 11
When I create a new route, the main routing table and unicast type are preselected.
It is correct from my testing that an unspecified routing table will add the route in main routing table.
An anycast type cannot be in main routing table, nor can be used in the way you are trying to use it.
Ok.... thanks. I guess I thought that anycast would include unicast and that it could be included in the main routing table. Thanks for clarifying.
Expanding on this a little though, can't an item just go in default rather than main and give the same effect and if not why not?
Main usually has the default route, so it will catch everything.
This is a long thread that I haven't really read fully as there's a lot of stuff here, but just in case my personal setup's configuration may help someone (not neccessarily the OP but someone in a similar position) here it is.
I have two physical networks, Network A is 192.168.0.0 and Network B is 192.168.1.0. Network A has NAT internet access via an ISP router gateway on 192.168.0.1. An OpenWrt box is connected to both Networks A & B via two ethernet ports. On A its IP is 192.168.0.2 on B it's 192.168.1.1. On OpenWrt netowkr A is the WAN and network B is the LAN. Clients connect to network B and are assigned IPs from 192.168.1.0/24 by OpenWrt's DHCP and are given 192.168.1.1 as the gateway. Unfortunately, the ISP router has no facility to enter a static route and so is unable to forward packets in the regular sense.
The solution.
Set the ISP router's netmask from 255.255.255.0 to 255.255.0.0. (Note, the OpenWrt's 192.168.0.2 address is still a netmask of 255.255.255.0) This then makes the ISP router search for IPs in 192.168.1.0 range on its regular interface. OpenWrt is then setup with parprouted causing it to respond to ARP requests from the ISP router forcing the ISP router to believe the OpenWrt box is the holder of the destination address, the packet is then sent to OpenWrt which then forwards it onto the LAN interface. This approach avoids the need for a double NAT.
@psherman and @trendy I have a question for you about my new dual router setup, which all works perfectly now. Concerning DNS, I have the following arrangement for both guest network and main network:
At the moment my downstream router is handling the DNS queries, but I'm not sure which way round makes sense now.
I have two questions really:
Which out of the upstream and downstream router should handle DNS queries?
Is there perhaps a clever way of doing this to maximise DNS caching, e.g. have downstream router pass all DNS queries to my upstream router and cache those, and upstream router select the appropriate destination (CleanBrowsing through stubby or Cloudflare)?
I don't think it makes too much sense to forward from one router to the other. You can use them both as nameservers and forward to the cloudflare or the other provider.
Or you can have nameserver running only on the first router and have the clients of the second router use the first as nameserver.