LAN masquerading or SNAT rewrite IPs or just a stupid plan?

Installing and Using OpenWrt Network and Wireless Configuration
1

I did configure this picture before with static IPs and also tried dhcp on VPNMiddleware LAN giving IP to WR1043nd WAN.
But I was lost.

There are three routers: r7800vpn and WR1043nd and Main Network, the others are servers.

You might get the purpose. the R7800vpn is VPN stuff only, separated from something called Main Network.
Screenshot_20181103_235241

Problem:
I am stuck here: https://bugs.openwrt.org/index.php?do=details&task_id=1334&string=archer+forwarding&advancedsearch=on&search_name=&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc

VPNMiddleware is doing http requests through (port forward) WR1043nd to Oceandigits. But there is no response.
I solved the issue with Masquerading LAN (according to https://oldwiki.archive.openwrt.org/doc/uci/firewall
Masquerading on lan) on WR1043nd (only for 192.168.100) but it had a (too) bad impact on the green network. (Too bad means it broke requests from other servers (within the green network) to oceandigits, which I did not understand)

Is there any other intelligent way to get the responses from Oceandigits back to WR1043ND if the according request comes from there? Something like setting the "default gateway" on Oceandigits depending on the origin of the incoming connections?

2

My fear is that your setup is not going to work. You cannot specify two default gateways, unless you have dual wan router. I have changed the network topology, so it can work for you. The TL-WR1043ND when running Openwrt is capable of Multi wan interfaces. You can setup mwan3 package - dual wan with either ethernet ports or a wireless client.

bd78dd50da69ac73f424047b3710a88ed9c5005a

If you can make extroot on TL-WR1043ND, you can install openvpn aside of the mwan3 and run either openvpn client or server and save the raspberry pi for later:

bd78dd50da69ac73f424047b3710a88ed9c5005a%20(m%C3%A1solat)

Sorry for the bad images, but I think you may get my idea anyway.

3

Thank you for the response. I am afraid that the outlook is that bad. Maybe I need to step back and rethink the whole idea.
The overall goal of WR1043ND was to use it as a hardware firewall between the VPN inbound network and the internal network. Is this possible in general? Should I set up the firewall WAN as unmanaged and do it totally different? I wanted to treat the VPN inbound network as a WAN zone, like an internet zone and separate it completely secure from the internal network.

4

You will have the wan - lan separation in both cases. The lan will be your Oceandigits Server.

5

Maybe I'm missing something, but this seems to be a "straightforward" routing/firewall application.

Only NAT when packets leave your control and need to cross the open Internet (assuming you don't need to "hide" your own hosts' IP addresses from each other, as you can control cross-subnet connectivity with firewall rules at the routers). From your diagram, that is the r7800vpn unit.

Within connected networks under your control (looks like everything in that diagram), route between subnets and control access with firewalls.

NAT is not a firewall! (Even though some people use it as one.)

Basically, in what looks to be a "tree" topology, you need to provide static routes on every router for "deeper" networks and a default route by the "upstream" router.

As I understand your diagram:

  • r7800vpn
    • Default route assumed to be over the VPN
    • Implicit route to 192.168.5.0/24 through configuration of WLAN interface
    • Needs static routes via 192.168.5.101 for
      • 192.168.44.0/24
      • 192.168.4.0/24
      • 192.168.1.0/24
  • Raspi
    • Default route via 192.168.5.1
    • Implicit route to 192.168.5.0/24 through configuration of WLAN interface
    • Implicit route to 192.168.44.0/24 through configuration of LAN interface
    • Needs static routes via 192.168.44.4 for
      • 192.168.4.0/24
      • 192.168.1.0/24
  • Wr1043nd
    • Default route via 192.168.44.100
    • Implicit route to 192.168.44.0/24 through configuration of WAN interface
    • Implicit route to 192.168.4.0/24 through configuration of WLAN interface
    • Needs static routes via 192.168.4.100 (as pointed out by @Frood42) for
      • 192.168.1.0/24
  • Oceandigits
    • Default route via 192.168.4.1
    • Implicit route to 192.168.4.0/24 through configuration of WLAN interface
    • Implicit route to 192.168.1.0/24 through configuration of LAN interface

Control "who can talk to whom" with firewall rules at each router.

6

Thank you very much for taking the time to review the architecture and your proposal! I will give it a try.

It should be 192.168.4.100 right?

Oceandigits is connected to Main Network (another R7800 :slight_smile: for regular internet connection) - with 192.168.0.1

7

Yes, next-hop should have been 192.168.4.100 from the Wr1043nd to the Oceandigits.

(Now that dangling "00" makes sense)

8

It doesnt work :frowning: My smoke test is on Raspi 192.168.5.101 do wget 192.168.44.4:8086
Port forward on WR1043nd is established:

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '8086'
	option dest_ip '192.168.4.100'
	option dest_port '8086'
	option name 'influxdbocean'

config rule
	option enabled '1'
	option target 'ACCEPT'
	option src 'wan'
	option name 'Allow8086fromWAN'
	option dest_ip '192.168.4.100'
	option dest_port '8086'
	option src_ip '192.168.44.100'
	option dest 'lan'

Current routings are:
R7800

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         62.xxx.yy.zz    0.0.0.0         UG    0      0        0 pppoe-wan
62.214.63.98    0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
192.168.1.0     192.168.5.101   255.255.255.0   UG    0      0        0 br-lan
192.168.4.0     192.168.5.101   255.255.255.0   UG    0      0        0 br-lan
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.44.0    192.168.5.101   255.255.255.0   UG    0      0        0 br-lan
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

Raspi

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.44.4    0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.5.1     0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     192.168.44.4    255.255.255.0   UG    0      0        0 eth0
192.168.4.0     192.168.44.4    255.255.255.0   UG    0      0        0 eth0
192.168.5.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0
192.168.44.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0

WR1043nd

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.44.100  0.0.0.0         UG    0      0        0 eth0.2
192.168.1.0     192.168.4.100   255.255.255.0   UG    0      0        0 br-lan
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.44.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0.2

Oceandigits

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.4.1     0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.4.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0
9

So now you'll need to figure out the "rules" for what the Oceandigits is going to do with outgoing packets. Now that you've got two routes to all "rest of world" addresses, things get complicated. Often this is resolved by having a "single" gateway (in quotes as it is often implemented with two or more devices that are aware of each other's state and can provide redundancy). Without knowledge of the state of through which gateway the packet came from, with NAT and a VPN in play, it's a rather challenging problem.

1.2.3.4 sends a packet to one of your two public interfaces. It makes it to some host somewhere. That host then sends a return packet based on the 1.2.3.4 address. There's just not enough information there for that host, or any of your routers, to know which path to take. Even if you rigged up something at your border that said, "If this isn't an established connection, send it to the other router", you've still got to figure out how to deal with new connections outbound from your hosts. Easier for TCP than for other protocols, but quite a challenge to keep the packet from bouncing from border router to border router until it times out.

Then again, if it doesn't matter that packets that came in over VPN return over VPN and vice versa, there is nothing that says that a packet has to take the same path on return.

If your VPN is a "pipe" to a known subnet (such as office-to-office connectivity), as opposed to the general Internet, then you probably can use the destination to properly select the gateway.

10

yes, yesterday, I re-imaged everything and set it up freshly and separated another issue:

It is related to non VPN and VPN connections which stop working as soon as 192.168.44.4 gets connected to Raspi VPN middleware.

It breaks my head... I really need to get this setup working.
With LAN masquerading on r7800vpn it starts working, but it breaks the existing home network...
I think I need to try the SNAT IP rewrite, but this is double head breaking...

11

And even worse to "fix" a year from now when it breaks. IP rewriting, at least as far as I'm concerned, is to be avoided in most every situation that it can be.

I'd take some time to figure out your subnets, all of them, and the transport you want between them and between them and the rest of the world. At least from here it seems like you've thrown hardware at a problem for which the objective isn't completely clear in all its details.

Routing, taken on a step-by-step basis is very straightforward, especially as it works on a step-by-step basis.

12

This goes beyond my imagination, but it works - on WR1043ND LAN
If it is totally restricted to the two neighbor subnets - it should not break the other subnets. Especially not the Main Network --> Oceandigits, which is the heart control center of this home. Lets see...
LAN_masq

13

Haha! Doing the LAN masquerading on both, R7800 and WR1043ND makes the setup working.
The change / clean solution today ist your routing rules, that do make much more sense now.

Thank you!
Hopefully it stays stable.

https://oldwiki.archive.openwrt.org/doc/uci/firewall
Masquerading on lan

14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.