Binding multiple wan IP's via one WAN cable to vlans

gcraenen · Wed Jan 28, 2015 11:36 am

Hello,

I have a range of 8 static wan IP's to my disposal. One is a gateway address, one is deginated to a routerport and one is the broadcast address, so there 5 of them free for me to use. At the moment I'm using only one (x.x.x.242) as Wan IP that is srcnatted to internal networks for setting up my MT the last few weeks. Only one physical cable is used between the ISP-router and my MT router. More physical connections are not possible because the ISP controls the router and only allows one cable-connection out to my network.

The next step I want to configure is connecting the remaining free wan IP's to vlans in my network. I can setup vlans, etc. on the MT and added all wan IP's to the IP address list (on ether1-gateway because that's the only one available). I cannot figure out how to "connect" and srcnat an external wan ip (say x.x.x.243) to an internal vlan I created. I can use src address in the nat-rule to point it to the vlan network (dhcp) I set up on that vlan, but is that enough? All examples I can find are using seperate ethernetports to set this up.

Thanks for the help.

lz1dsb · Wed Jan 28, 2015 5:10 pm

As far as the configuration goes, it does not matter whether it's an ethernet port a vlan interface or a bridge, or whatever. In the NAT rule you just have to reference the correct IP address, the IP address which is assigned for the proper vlan in your example.

gcraenen · Sun Feb 01, 2015 6:54 pm

Hi,

Still wrestling with this and not getting it to work. I have checked that the vlan itself (with it's own address, dhcp-server, dhcp-pool and networkrang) is working within my private network. The VM is in a standard switch on a seperate portgroup on the ESXi-server and is getting a ip-address that's in the range of the vlan-pool. So that seems to be working ok.

If connect the vlan-port in the default "bridge-local" (that's natted/masquereaded to the first wan-ip), the VM has wan-connecting and can ping for instance 8.8.8.8 fine. But off course with the wan-ip x.x.x.242.

I'm stuck on the right firewall-masquerade rule for masquerading the vlan to a different wan-ip, say x.x.x.243? What have I tried sofar:

1. make a separate vlan-bridge and put the vlan in that. After that create a srcnat rule with src.address=vlan-ip-net and dest.address=x.x.x.243. Doesn't work.
2. make prerouting mangle rules to "tag" the connection and the packets of the vlan with in.interface=vlan-bridge. The use that in the srcnat rule Packet Mark=vlan and dest.address=x.x.x.243. Doesn't work.

I'm unclear how to proceed next. This should not be difficult, though?

NathanA · Mon Feb 02, 2015 12:43 am

Nono, "dst-address" is not the address you want to have your internal traffic NATted to. "dst-address" is a matcher, just like "src-address" is. That is, "dst-address" is a value to be checked on the original packet, and if a packet matches all matchers on a rule, then the rule is executed.

You don't (typically) match on dst-address for things in the src-nat chain. So you would specify chain=srcnat, src-address=vlan-net (e.g., 192.168.1.0/24), action=src-nat, and to-addresses=WAN-IP (e.g., x.x.x.243). So to translate, you want to match all packets with a source IP in the VLAN subnet, and change the source IP TO the WAN IP. If you wanted to do a port forward (that is, destination NAT), you would put the rule in the dstnat chain, action=dst-nat, and then to-addresses becomes the value you want to change the destination IP to instead of the source IP. So the meaning of to-addresses (and to-ports) changes depending on what your 'action' is set to.

The to-blahblah parameters (e.g., to-addresses, to-ports) are the parameters that indicate what you want to change; everything else is a matcher.

Manual for IP -> Firewall -> NAT is located here.

-- Nathan

gcraenen · Mon Feb 02, 2015 10:42 pm

Hello Nathan,

Ok, thanks. So I shouldn't be making a masquerade rule for this but a src-nat rule in the action field? I thought I needed a masquerade rule, because the vlan is an internal private network, while the x.x.x.243 is a wan ip from my isp I can use.

rmmccann · Mon Feb 02, 2015 11:02 pm

Src-nat is inside source to outside source NAT for outbound (to internet) connections. Dst-nat is the reverse for inbound (say making a NAT webserver accessible on a public IP). Masquerade is just quick and dirty outbound NAT.

For your config, it's pretty simple. Let's make some assumptions and you can modify to your config:

1) WAN port: ether1, WAN IP range 1.2.3.0/29 with 1.2.3.1 as your gateway address.
2) LAN1 is 192.168.0.0/24, VLAN1 is 192.168.1.0/24, VLAN2 is 192.168.2.0/24, VLAN3 is 192.168.3.0/24, VLAN4 is 192.168.4.0/24
3) You have your VLANs created and connected to your switch. All other config is handled (your default gateway, DHCP, etc).

Your IP NAT rules should look something like:

/ip firewall nat
add action=src-nat chain=srcnat comment=LAN1 out-interface=ether1 src-address=192.168.0.0/24 to-addresses=1.2.3.2
add action=src-nat chain=srcnat comment=VLAN1 out-interface=ether1 src-address=192.168.1.0/24 to-addresses=1.2.3.3
add action=src-nat chain=srcnat comment=VLAN2 out-interface=ether1 src-address=192.168.2.0/24 to-addresses=1.2.3.4
add action=src-nat chain=srcnat comment=VLAN3 out-interface=ether1 src-address=192.168.3.0/24 to-addresses=1.2.3.5
add action=src-nat chain=srcnat comment=VLAN4 out-interface=ether1 src-address=192.168.4.0/24 to-addresses=1.2.3.6

By the rules, you're basically telling the router that "this subnet" should use "this IP address". I've added the out-interface so that you're saying "this rule is only valid if the packet is leaving the router via the WAN interface".

Now, if you wanted to say have a web server connect to a server on VLAN4 192.168.4.10, using public IP 1.2.3.6, you'd create a dst-nat rule like so:

/ip firewall nat
add action=dst-nat chain=dstnat comment=Webserver in-interface=ether1 dst-address=1.2.3.6 dst-port=80 protocol=tcp to-addresses=192.168.4.10 to-ports=80

I've also specified that the rule is only valid when the request for the webserver comes in to the router from the WAN interface (the internet). If you wanted to make the web server accessible via other subnets on the router, just drop the in-interface piece.

Make sense?

gcraenen · Tue Feb 03, 2015 12:11 am

Yes, thank you. This makes perfect sense. Now I see the logic of it, it's quite clear.

I'll implement this setup and have to find out if I have to change or add firewall rules. Most off them are not bound to a specific bridge, lan or vlan so I think they should work "in" the vlans too, but I'll test it. I must say that I'm getting more impressed of the MT's and routerOS everytime I find something out and getting further with it step-by-step.

Thanks for the clear explanation.

NathanA · Tue Feb 03, 2015 2:48 am

"action=masquerade" doesn't take/ignores "to-addresses", and is literally just a shortcut for "action=src-nat to-addresses=<WAN-IP>", where <WAN-IP> is somewhat misleading (I couldn't think of a better label) and actually refers to whatever the main IP is on whatever interface you are routing a packet out through (the route's "pref-src").

The main advantage to using "action=masquerade" instead of "action=src-nat to-addresses=x.x.x.x/y", besides it being less typing, is that if you ever change <WAN-IP> (e.g., you have a dynamic IP address from your ISP), you don't have to change your NAT rule...it just continues to work and automatically makes the adjustment.

Since you have multiple IP addresses on the same interface, and you want to change the source IP address to a different WAN IP depending on what subnet the traffic is coming from, you can't use "action=masquerade", and have to build a set of explicit "action=src-nat" rules.

-- Nathan

gcraenen · Tue Feb 03, 2015 9:10 pm

Everything is setup and working as expected, because of your help. So, thank you for that.

I have an additional question. At the moment pc's from my "normal" lan cannot ping and reach machines on the vlan and that is to be expected. I want to create an address list ("access to vlan") with pc's with fixed ip-addresses in the range 192.168.88.0/24 that will have access to the machines and servers on the vlan in ip-range 192.168.200.0/24. I already created the address list, but I'm looking for the firewall rule(s) to make this happen. Do I need an "accept" rule and/or a srcnat or dstnat rule between lan and vlan?

NathanA · Tue Feb 03, 2015 11:26 pm

At the moment pc's from my "normal" lan cannot ping and reach machines on the vlan and that is to be expected.

Why is that to be expected? Default firewall filter action for forwarded traffic is "accept" so I would actually expect this to work without any additional configuration. Have you added any firewall filter rules that cause traffic to be dropped?

-- Nathan

gcraenen · Tue Feb 03, 2015 11:47 pm

I thought that vlan trafic and access is totaly separated from "other" lan or vlan trafic, but I realise that's only true for the trafic and not the access to the ip-addresses. I actually have quit a few firewall rules, I'll copy in below. There are some references to lists I created (or scripts create them) in the address list section.

[admin@Gateway router] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Drop invalid connections
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 1    ;;; Drop ICMP ping from gateway
      chain=input action=drop protocol=icmp in-interface=ether1-gateway 
      log=no log-prefix="" 

 2    ;;; Drop open proxy
      chain=input action=drop protocol=tcp in-interface=ether1-gateway 
      dst-port=8080 log=no log-prefix="" 

 3    ;;; Allow already established connections
      chain=input action=accept connection-state=established log=no 
      log-prefix="" 

 4    ;;; Allow already related connections
      chain=input action=accept connection-state=related log=no log-prefix="" 

 5    ;;; allow SSTP
      chain=input action=accept protocol=tcp dst-port=443 log=yes 
      log-prefix="" 

 6    ;;; allow L2TP/IPSEC
      chain=input action=accept protocol=udp dst-port=500,1701,4500 log=yes 
      log-prefix="" 

 7    ;;; allow ipsec-esp
      chain=input action=accept protocol=ipsec-esp log=yes log-prefix="" 

 8    ;;; Drop blacklist entries
      chain=input action=drop src-address-list=blacklist 
      in-interface=ether1-gateway log=yes log-prefix="" 

 9    ;;; WAN login tries
      chain=input action=add-src-to-address-list protocol=tcp 
      address-list=Login_tries_wan address-list-timeout=1d 
      in-interface=ether1-gateway dst-port=20-23,53,8291 log=yes 
      log-prefix="" 

10    ;;; Drop WAN login tries
      chain=input action=drop src-address-list=Login_tries_wan log=yes 
      log-prefix="" 

11    ;;; Detect Dos attack
      chain=input action=add-src-to-address-list protocol=tcp 
      address-list=DoS address-list-timeout=1d connection-limit=10,32 log=no 
      log-prefix="" 

12    ;;; Supress Dos attack
      chain=input action=tarpit protocol=tcp src-address-list=DoS 
      connection-limit=3,32 log=no log-prefix="" 

13    ;;; LAN login tries
      chain=input action=add-src-to-address-list protocol=tcp 
      src-address-list=!Admin address-list=Login_tries_lan 
      address-list-timeout=1d in-interface=!ether1-gateway 
      dst-port=20-23,8291 log=yes log-prefix="" 

14    ;;; Block winbox access - except support list
      chain=input action=drop protocol=tcp src-address-list=!support 
      dst-port=8291 log=no log-prefix="" 

15    ;;; Block home network --> guest wlan
      chain=input action=drop src-address=192.168.88.0/24 
      dst-address=192.168.90.0/24 log=no log-prefix="" 

16    ;;; Block guest wlan --> home network
      chain=input action=drop src-address=192.168.90.0/24 
      dst-address=192.168.88.0/24 log=no log-prefix="" 

17    ;;; Add Syn Flood IP to the list
      chain=input action=add-src-to-address-list tcp-flags=syn protocol=tcp 
      src-address-list=!Admin address-list=Syn_Flooder 
      address-list-timeout=30m connection-limit=30,32 log=yes log-prefix="" 

18    ;;; Drop to syn flood list
      chain=input action=drop src-address-list=Syn_Flooder log=yes 
      log-prefix="" 

19    ;;; Port Scanner Detect
      chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1 
      src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

20    ;;; FIN/PSH/URG scan
      chain=input action=add-src-to-address-list 
      tcp-flags=fin,psh,urg,!syn,!rst,!ack protocol=tcp 
      src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

21    ;;; NMAP FIN Stealth scan
      chain=input action=add-src-to-address-list 
      tcp-flags=fin,!syn,!rst,!psh,!ack,!urg protocol=tcp 
      src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

22    ;;; NMAP Null scan
      chain=input action=add-src-to-address-list 
      tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg protocol=tcp 
      src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

23    ;;; ALL/ALL scan
      chain=input action=add-src-to-address-list 
      tcp-flags=fin,syn,rst,psh,ack,urg protocol=tcp src-address-list=!Admin 
      address-list=Port_Scanner address-list-timeout=1w log=yes log-prefix="" 

24    ;;; SYN/FIN scan
      chain=input action=add-src-to-address-list tcp-flags=fin,syn 
      protocol=tcp src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

25    ;;; SYN/RST scan
      chain=input action=add-src-to-address-list tcp-flags=syn,rst 
      protocol=tcp src-address-list=!Admin address-list=Port_Scanner 
      address-list-timeout=1w log=yes log-prefix="" 

26    ;;; Drop to port scan list
      chain=input action=drop src-address-list=Port_Scanner log=yes 
      log-prefix="" 

27    ;;; Allow broadcast traffic
      chain=input action=accept dst-address-type=broadcast log=no 
      log-prefix="" 

28    ;;; Jump to chain icmp
      chain=input action=jump jump-target=ICMP protocol=icmp log=no 
      log-prefix="" 

29    ;;; Allow internal nets
      chain=input action=accept in-interface=!ether1-gateway log=no 
      log-prefix="" 

30    ;;; Drop everything else
      chain=input action=drop log=yes log-prefix="Dropped" 

31    ;;; Drop invalid connection forwards
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

32    ;;; Allow new connections from LAN
      chain=forward action=accept connection-state=new 
      src-address-list=internal-nets log=no log-prefix="" 

33    ;;; Allow established connections from LAN
      chain=forward action=accept connection-state=established log=no 
      log-prefix="" 

34    ;;; Allow related connections from LAN
      chain=forward action=accept connection-state=related log=no 
      log-prefix="" 

35    ;;; Drop bogons
      chain=forward action=drop dst-address-list=bogons log=yes 
      tcp-flags=fin,syn,rst,psh,ack,urg protocol=tcp src-address-list=!Admin 
      address-list=Port_Scanner address-list-timeout=1w log=yes log-prefix="" 

36    ;;; Add Spammers to list for 3 hours
      chain=forward action=add-src-to-address-list protocol=tcp 
      address-list=spammers address-list-timeout=3h dst-port=25,587,465 
      connection-limit=30,32 limit=30/1m,0 log=no log-prefix="" 

37    ;;; Drop from spammers list
      chain=forward action=drop protocol=tcp src-address-list=spammers 
      dst-port=25,587,465 log=yes log-prefix="Drop spammer" 

38    ;;; Jump to icmp forward flow
      chain=forward action=jump jump-target=ICMP protocol=icmp log=no 
      log-prefix="" 

39    ;;; Jump for icmp output
      chain=output action=jump jump-target=ICMP protocol=icmp log=no 
      log-prefix="" 

40    ;;; 0:0 and limit for 5pac/s
      chain=ICMP action=accept protocol=icmp icmp-options=0:0-255 limit=5,5 
      log=no log-prefix="" 

41    ;;; 3:0-1 destination unreachable
      chain=ICMP action=accept protocol=icmp icmp-options=3:0-1 log=no 
      log-prefix="" 

42    ;;; 3:3 and limit for 5pac/s
      chain=ICMP action=accept protocol=icmp icmp-options=3:3 limit=5,5 
      log=no log-prefix="" 

43    ;;; 3:4 and limit for 5pac/s
      chain=ICMP action=accept protocol=icmp icmp-options=3:4 limit=5,5 
      log=no log-prefix="" 

44    ;;; 8:0 and limit for 5pac/s
      chain=ICMP action=accept protocol=icmp icmp-options=8:0-255 limit=5,5 
      log=no log-prefix="" 

45    ;;; 11:0 and limit for 5pac/s
      chain=ICMP action=accept protocol=icmp icmp-options=11:0-255 limit=5,5 
      log=no log-prefix="" 

46    ;;; Drop everything else
      chain=ICMP action=drop protocol=icmp log=no log-prefix=""

Thanks for taking the time and trouble to "wade" through this list and help me out.

NathanA · Wed Feb 04, 2015 12:14 am

I thought that vlan trafic and access is totaly separated from "other" lan or vlan trafic, but I realise that's only true for the trafic and not the access to the ip-addresses.

You shouldn't conceive of your VLANs as anything other than separate network interfaces. In this case, they are "virtual" interfaces that allow you to multiplex a single physical ethernet port into multiple virtual ones, but that is just an implementation detail, and other than that, from the router's perspective, they are conceptually no different than an ethernet port. If you bridge or switch two ethernet-like interfaces together (VLANs, physical ports, EoIP, or whatever), the devices connected to either interface will be able to "reach" each other at L2. If they are not bridged together, then with the router's help, they will be able to "reach" each other at L3. You can prevent this either with bridge filter rules in the forward chain (in the case of L2) or with IP route filter rules in the forward chain (in the case of L3).

I don't see anything in your list that immediately sticks out. What if you were to try disabling all IP firewall filter rules and then see if you can ping between the two networks/subnets? If you can, start enabling the filter rules one by one until the ping dies. If it still doesn't work, then it is a problem with routing configuration, either on the router or on the hosts themselves. If 192.168.88.1 and 192.168.200.1 are on the router and on the correct interfaces on the router, and if all of the hosts in 192.168.88.0/24 have 88.1 set as their default gateway, and all of the hosts in 192.168.200.0/24 have 200.1 set as their default gateway, and if you can verify that 192.168.200.x machines can ping/reach 192.168.200.1 and 192.168.88.x machines can ping/reach 192.168.88.1, then it should "just work".

-- Nathan

gcraenen · Wed Feb 04, 2015 9:52 am

Ok, thanks. I'll try this first and come back with the results.

rmmccann · Wed Feb 04, 2015 6:02 pm

I noticed two things:

You have Guest/Home traffic blocked, however you've specified the input chain instead of the forward chain. "Input" specifies traffic destined for the router itself. "Forward" is for traffic that is going THROUGH the router and out to other interfaces.

Additionally, you have a rule for dropping bogons on your forward chain (see above). Is this the full list of private/non-routed IPs? If so, that's likely where traffic is being blocked.

I would put the bogon on the Input chain and explicitly define which type of subnet communication you want to allow using forward chain rules and address lists. I've seen on another post here where you can essentially allow "one-way" traffic (from a management subnet, for instance) to talk to all subnets using established and related connection matching and blocking the opposite direction traffic (subnet2 -> management subnet) unless it was initiated by the management subnet.

gcraenen · Wed Feb 04, 2015 6:17 pm

Hello,

Thanks for the remarks on the firewall rules. I just tried disabling all of the rules and see if I can ping form lan to vlan, but that's still unreachable so it doesn't seem to be that these firewall rules are blocking that traffic. I noticed on further inspection that I didn't make the vlan part of bridge-local so I added the vlan port to bridge-local. I still couldn't ping lan to vlan and the other effect was that servers on the valn couldn't ping (reach) external ip addresses.

Could this be a problem in routing protocols? I have IGMP proxy and PIM enabled on this MT and on another MT (the ESXi server with the vlan ports is connected to that MT)?

rmmccann · Wed Feb 04, 2015 6:21 pm

If you try a traceroute is it able to find a route to the hosts?

gcraenen · Wed Feb 04, 2015 7:03 pm

No, I'm getting a route (nr. 1) to the router 192.168.88.1, but after that only "stars" until I stop the traceroute.

rmmccann · Wed Feb 04, 2015 7:24 pm

What do your NAT rules look like? I've had a problem similar to this before on my lab environment - I borked myself with a masquerade rule that ended up blocking the traffic.

gcraenen · Wed Feb 04, 2015 8:20 pm

They look like this:

[admin@Gateway router] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Nat WAN-->LAN
      chain=srcnat action=src-nat to-addresses=x.x.x.242 
      src-address=192.168.88.0/24 out-interface=ether1-gateway log=no 
      log-prefix="" 

 1    ;;; Nat WAN-->VLAN10
      chain=srcnat action=src-nat to-addresses=x.x.x.243 
      src-address=192.168.200.0/24 out-interface=ether1-gateway log=no 
      log-prefix="" 

 2 X  ;;; Redirect to web proxy
      chain=dstnat action=redirect to-ports=8080 protocol=tcp 
      dst-address=!192.168.88.1 dst-port=80 log=no log-prefix="" 

 3 X  ;;; Masquerade/NAT guest wlan <--> wan
      chain=srcnat action=masquerade src-address=192.168.90.0/24 
      out-interface=ether1-gateway log=yes log-prefix=""

NAT rules 2 and 3 are disabled.

Another thing I thought about is to which interface I "connected" the vlan to. I did this to bridge-local on the MT router and also on the second MT router.

rmmccann · Wed Feb 04, 2015 10:53 pm

I've always created the VLANs on the individual interfaces. I very well could be wrong, but I don't know if you can actually create the VLAN IDs on a bridge interface directly.

Additionally, my routers are x86 so I'm not 100% familiar with the process of using the switch chips on routerboards for VLANs - I'm sure someone else can chime in and get you squared away.

gcraenen · Thu Feb 05, 2015 9:50 am

I have tried binding the vlan to ether2, which is a masterport to which the other etherports are bridged as slaves, but the results are the same as when I create the vlan directly "to" bridge-local.

rmmccann · Thu Feb 05, 2015 10:28 pm

I was able to play around with VLANs under the switch configuration on a 750GL and was able to get everything working as expected (and learned a few things at the same time).

With your VLAN configuration, do you have them created under /interface vlan (The VLAN tab in Interfaces on Winbox) or under /interface ethernet switch (The switch page in Winbox)?

I set up my 750 using vlan-mode=secure. With this, I have to explicitly create every VLAN and choose which ports are members. For trunk ports, I leave vlan-header as "leave as is", access ports have a vlan-header of "always strip" followed by the VLAN for the port and for hybrid ports (untagged and tagged packets on same port) I have it set to "add if missing" followed by the untagged VLAN.

I also learned that ANY VLAN that needs to traverse the CPU (such as for bridging, NAT, firewall, etc) has to also be explicitly assigned to the switch CPU. This also includes your management VLAN.

It might be helpful to get a full view of your config so we can try to pinpoint where it's failing.

gcraenen · Fri Feb 06, 2015 12:22 am

Hi,

First off all, thank you for diving into this. I appreciate it.

I created one vlan (vlan10-sec) under the vlan tab and left the switch settings alone. Below I include a full "export compact" for review. I sanitized it for security reasons. I'm very curious and appreciative for tips on how to improve it, since I'm just a few weeks "configuring" around with the MT's.

NathanA · Fri Feb 06, 2015 12:52 am

No, I'm getting a route (nr. 1) to the router 192.168.88.1, but after that only "stars" until I stop the traceroute.

I am assuming you are tracerouting from a 192.168.88.x host. This at least proves that the router at 192.168.88.1 is reachable to those hosts. What about from a 192.168.200.x host, though? Have you tried a traceroute from one of those to a 192.168.88.x host and/or have you tried pinging 192.168.200.1 from a 192.168.200.x host?

I've always created the VLANs on the individual interfaces. I very well could be wrong, but I don't know if you can actually create the VLAN IDs on a bridge interface directly.

You absolutely can, and *should* do so if the member ports that you want the VLAN tagged on are in a bridge together. The golden rule of bridges is that once an interface is a member of a bridge, when it comes to logical network configuration, you no longer consider that port to be a discrete thing. From that point on, when it comes to that port, you deal with the bridge, not the port. Not doing so can result in undefined behavior. (MT has taken steps in recent versions to explicitly allow for certain things...I think I remember reading in one of the release notes for a recent version that they now allow for a DHCP client to be attached to a member of a bridge instead of the bridge itself for some reason. But that's confusing, and so I adhere to the general rule in order to keep things simple and understandable and to avoid pitfalls.)

I have tried binding the vlan to ether2, which is a masterport to which the other etherports are bridged as slaves, but the results are the same as when I create the vlan directly "to" bridge-local.

I would recommend you change this back, although it sounds like it is clear that this is not what is causing the problem you have been describing. It will at least ensure, though, that another variable is not present that could cause other problems to arise which may mask the one you are trying to troubleshoot.

-- Nathan

rmmccann · Fri Feb 06, 2015 1:02 am

You absolutely can, and *should* do so if the member ports that you want the VLAN tagged on are in a bridge together. The golden rule of bridges is that once an interface is a member of a bridge, when it comes to logical network configuration, you no longer consider that port to be a discrete thing. From that point on, when it comes to that port, you deal with the bridge, not the port. Not doing so can result in undefined behavior. (MT has taken steps in recent versions to explicitly allow for certain things...I think I remember reading in one of the release notes for a recent version that they now allow for a DHCP client to be attached to a member of a bridge instead of the bridge itself for some reason. But that's confusing, and so I adhere to the general rule in order to keep things simple and understandable and to avoid pitfalls.)

Thanks for the insight - it certainly makes sense. I can't say that I've personally had any configurations where I've needed to do something like this. I've had situations where I've needed multiple bridges because some are providing RSTP and others are not. Either way, gives me another way to look at things.

After looking through the above config (it was a lot to digest and it might be beneficial to scrub the blacklist address list entries so we don't have to scroll so much) - I'm thinking your problem is coming in somewhere with the firewall and mangle rules.

It might be beneficial to just disable everything but the basics, then once you have some success, start enabling things until you find out what is breaking it.

gcraenen · Fri Feb 06, 2015 10:16 am

No, I'm getting a route (nr. 1) to the router 192.168.88.1, but after that only "stars" until I stop the traceroute.
I am assuming you are tracerouting from a 192.168.88.x host. This at least proves that the router at 192.168.88.1 is reachable to those hosts. What about from a 192.168.200.x host, though? Have you tried a traceroute from one of those to a 192.168.88.x host and/or have you tried pinging 192.168.200.1 from a 192.168.200.x host?

I have tried pinging and traceroute form 192.168.200.x hosts. I can reach wan address 8.8.8.8 fine but nothing on 192.168.88.x.

I have tried binding the vlan to ether2, which is a masterport to which the other etherports are bridged as slaves, but the results are the same as when I create the vlan directly "to" bridge-local.
I would recommend you change this back, although it sounds like it is clear that this is not what is causing the problem you have been describing. It will at least ensure, though, that another variable is not present that could cause other problems to arise which may mask the one you are trying to troubleshoot.

-- Nathan

I changed that back.

What I furthermore tried is disabling all firewall rules and start a traceroute from both networks. Unfortunately with the same results as before. The only thing I can think off at the moment is creating a new bridge-vlan interface, create the vlan into that (instead off the bridge-local) and then assign IP-address, dhcp, etc. to that new bridge-vlan. Kind off like the default setup the MT comes with, where the adresses, dhcp, etc. are set on "bridge-local" and not on, for instance, ether2.

gcraenen · Fri Feb 06, 2015 10:32 am

Eureka!

I have found what went wrong. In a second router/switch (a crs125-24g etc. configured as switch, not the gateway I posted about) I also created a vlan10 interface in bridge-local. The vSphere server/virtual network is connected to that switch. When I removed the created vlan interface from that router/switch alltogether I could both networks either way around. So it seems that this was the problem. I cannot figure out why though...

But I'm glad it is working now. Thanks everybody who contributed to the search and with tips. It was a learning experience.

Binding multiple wan IP's via one WAN cable to vlans

Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Re: Binding multiple wan IP's via one WAN cable to vlans

Who is online