[solved] Mwan3 dedicate wan and wanb to services instead of failover

Installing and Using OpenWrt Network and Wireless Configuration
1

my setup includes a working mwan3 - balancing or only_wan/only_wanb from lan to the outside is performing well.

for now, the wan interface with the higher metric is the default one, unplugging immediately makes use of wanb. By that I mean my port forwardings, services are reached via a public ip on wan, except on failover, then like I earlier told, wanb's public ip is the winner.
having a higher metric on interface wanb, leads as well to the redirects to the services.

At the moment, with working wan (default), I reach local webservers... and via wanb's public IP, my browser call is firewalled, timing out... My understanding of mwan3 is that with policies and rules each wan interface can be used for reaching services from lan machines, right?

I need help here, can someone describe how to set this up?

2

Policy-based routing will do this.

  • You make network routes on another routing table - configured to use WAN2
  • You make network rules for selected IP/Interfaces (and WAN2) to use the new routes located on the new routing table

I've never used the web GUI app; but I surmise it's likely easier to tell you about the app - than to show you command line examples.

Hope this helps.

3

Thank you! I just installed the packages and I only can opt the wan interface, wanb isn't listed. nor can it be used be editing the policy config. reload --verbose errors with "no-interface wanb" :frowning:
the hint looked promising... I would appreciate your examples and config files

4

OK, cool.

This example causes devices 192.168.1.x and 192.168.1.y to use a default route on Table 2 - for reaching 8.8.8.8 on wanb.

In /etc/config/network -

config rule
	option src '192.168.1.x/32'
	option dest '8.8.8.8/32'
	option priority '3'
	option lookup '2'

config rule
	option src '192.168.1.y/32'
	option dest '8.8.8.8/32'
	option priority '4'
	option lookup '2'

config route                
	option interface 'wanb'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option table '2'
1 Like
5

I see! Thank you. I might be a bit confused, but it seems that I need the opposite direction:

WanA-->LanMachineA..C and/or WanB-->LanMachineD..F
Having a Mailserver responding on mail.server.de (public IP WanA)
and a Webserver responding on web.server.de (public IP WanB)

2 different Public IPs/Domainnames incoming should be routed to different Localservers, for now only one (higher Metric, mwan3 package running) Wan Interface only can be redirected/port forwarded to the Lan. Except I pull the plug :D, then the failover is immediately.

6

:thinking:

I think you should describe exactly how you want this to work. Things can and probably should work differently for connections originating on your LAN vs connections incoming from WAN.

7

So far, thanks for the input! I see your effort!

Untitled%20Diagram
Untitled Diagram.jpg554×738 45 KB

Currently, ISP3 (high metric on WanB) serve fine via all forwardings. Failover to Wan takes place on mwan3's network down event from WanB.

Adjusting which interface to the outside world is being used by my lan clients is ok.
Port/IP based - everything fine from balancing to xxx_only.

Still the goal is to dedicate incoming requests/connections to different machines in LEDE's LAN. For the failover I do have no clue, but it would make sense to then route to the active wan and rewriting DNS records by api.

8

An incoming request is just that... Incoming. It will only come in on whatever IP was used by the remote client.

Are you saying that mwan3 is interfering with the ability of your LAN host to reply to the incoming request? Or are you just having difficulty setting up the port forward?

9

the port forwardings are reacting strange (to me). I have only one firewall zone for wan and wanb and the forwardings are told to use incoming connections from there and push them to the local clients. some dnat redirects, only ports differ, are accepting wan domains and some wanb - I have no control on this :slight_smile: although the first ones I did are like steady on wanb...
I did assume that both incomings should be forwarded to the declared lan machine. but they aren't.

10

I think you issue is that you're confusing inbound and outbound.

You can only have an internal service use one outbound route/rule in general.

How are you able to determine this to be the case?

11

case wan metric '10' & wanb metric '20'

remote client (LTE etc.) --> domain wan.isp.1 --> port forwarding wan/wanb zone --> lan webserver = connection established (website loading)
and
remote client (LTE etc.) --> domain wanb.isp.2 --> port forwarding wan/wanb zone--> lan webserver = blocked...

switching metrics results to the opposite.

12

To be clear...verify your issue is:

  • packet enters wanA
  • received by LAN device
  • packet leave out wanB

and; in the inverse:

  • packet enters wanB
  • received by LAN device
  • packet leave out wanA

Correct :question:

If so, you cannot use metrics. You have to set the servers via policy-based routing rules and routes to only use one WAN connection.

13

Your effort is great! TY

Is it sufficient to check nginx/apache access logs for incoming packets, if so, then there is no receiving on lan device (webserver) from wanb (right now)

or= no inbound in lan server coming from wanb, but from wan

1 Like
14

Let's call WANA and WANB so we can distinguish carefully, and imagine IPA and IPB are public IP addresses assigned to WANA and WANB respectively...

Let's call two machines on your LAN as LANA and LANB such that IPA on port something is supposed to forward to LANA on similar port.... and so also IPB on WANB is forwarding to LANB.

Let's suppose WANA and WANB are up and running, but have different metrics.

Please set up tcpdump or wireshark on LANA and LANB listening for connections to the port that is forwarded for each...

Now from the internet access IPA on forwarded port and look for packets on LANA , do the same for IPB on forwarded port and look for packets on LANB

tell us at least if packets arrive at LANA and LANB as they should.

Next step would be to determine what happens to responses from LANA and LANB which may be incorrectly routed.

If the routing is the problem, and I think it is, then solving the routing problem should be easy with policy routing. Basically a rule says "if it comes from LANA send it out WANA" and "if it comes from LANB send it out WANB".

15

I agree on your scheme!

tcpdump -i eth0 -nn -s0 -v port 80 > port80tcpdump

IPA > WANA > LANA resolves alright

IPB > WANB > LANA repeats till time out:

192.168.1.1.56950 > 192.168.1.103.80: Flags [S], cksum 0x0ada (correct), seq 1389257278, win 65535, options [mss 1452,nop,wscale 6,nop,nop,TS val 245892598 ecr 0,sackOK,eol], length 0

20:42:16.201865 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

192.168.1.103.80 > 192.168.1.1.56950: Flags [S.], cksum 0x83e7 (incorrect -> 0x27ae), seq 480113131, ack 1389257279, win 28960, options [mss 1460,sackOK,TS val 260474018 ecr 245884475,nop,wscale 7], length 0

20:42:20.417667 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

192.168.1.103.80 > 192.168.1.1.56950: Flags [S.], cksum 0x83e7 (incorrect -> 0x2390), seq 480113131, ack 1389257279, win 28960, options [mss 1460,sackOK,TS val 260475072 ecr 245884475,nop,wscale 7], length 0

20:42:23.027016 IP (tos 0x0, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 48)

192.168.1.1.56950 > 192.168.1.103.80: Flags [S], cksum 0x6c9c (correct), seq 1389257278, win 65535, options [mss 1452,sackOK,eol], length 0

20:42:23.027057 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

Inbound on LANA via WANA & WANB looks OK to me, now :smiley:
LANA is routed back to WANA on request via WANA, but via WANB its going to nirvana

16

Hmm.. Ok, so you're saying that host LANA is supposed to respond to requests coming from BOTH WANA and WANB?

Give LANA two different LAN ip addresses... call them IPLANA and IPLANB, when a request comes in on WANA forward it to IPLANA when a request comes in on WANB forward it to IPLANB

I think this will resolve your problem, maybe.

17

Am I correct to assume that with IPV6 this whole shizzle has an end? I see policy based routing more efficient then dealing with mwan, after shutting down the service, ipv6 starts living and a dive deeper into pbr. as of now some issues are solved. lets close this ticket. Thanks for the effort and your time :smiley:

18

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