Deny VLAN100 WAN access

[Nikotine]

FYI, this is what I'm trying to accomplish: https://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR-managed-switch-with-shared-internet-access

The only difference (apart from different brand of switch) is that I'm trying to deny WAN access to VLAN100 in the Friendlywrt router instead of using ACL in the switch.

[trendy]

@Nikotine

[0:0] -A FORWARD -i eth1.100 -m comment --comment "!fw3" -j zone_NO_WAN_forward

There doesn't seem to be any hit on the firewall coming from the eth1.100. Therefore the packets are somehow bypassing it, even though you have it configured properly. My guess is that your switch is acting as a router and uses another vlan to reach the internet. Remove the vlan interfaces 9 and 100 from the switch. They are not needed and you can access the switch on vlan4095 for management.

[ASFP]

Set this to reject.

[trendy]

@ASFP

Set this to reject.

It is already set to reject and it is not relevant.

@Nikotine

[0:0] -A zone_NO_WAN_forward -m comment --comment "!fw3" -j zone_NO_WAN_dest_REJECT

[Nikotine]

@trendy

@ASFP

Set this to reject.

It is already set to reject and it is not relevant.

@Nikotine

[0:0] -A zone_NO_WAN_forward -m comment --comment "!fw3" -j zone_NO_WAN_dest_REJECT

Yes, I have changed that already, on @lleachii 's request.
Also, I'm trying to stop step 2 to 3 for vlan 100 in this traceroute, not 1 to 2:

@Nikotine

traceroute to google.com (172.217.17.46), 30 hops max, 60 byte packets
 1  10.25.100.2 (10.25.100.2)  1.074 ms  1.558 ms  2.118 ms
 2  FriendlyWrt.lan (10.25.100.1)  0.614 ms  0.490 ms  0.827 ms
 3  192.168.1.1 (192.168.1.1)  2.076 ms  3.940 ms  1.789 ms
 4  192.168.0.1 (192.168.0.1)  4.673 ms  3.621 ms  5.529 ms

@trendy

Remove the vlan interfaces 9 and 100 from the switch. They are not needed and you can access the switch on vlan4095 for management.

Will the switch do routing between vlan 9 and 100 without them?

[trendy]

@Nikotine

Will the switch do routing between vlan 9 and 100 without them?

Definitely not.

[Nikotine]

@trendy

@Nikotine

[0:0] -A FORWARD -i eth1.100 -m comment --comment "!fw3" -j zone_NO_WAN_forward

There doesn't seem to be any hit on the firewall coming from the eth1.100. Therefore the packets are somehow bypassing it, even though you have it configured properly. My guess is that your switch is acting as a router and uses another vlan to reach the internet.

Wouldn't I see this in the traceroute?
The other vlans have different subnets, 10.25.9.1/24 for vlan 9 and 10.25.1.1/24 for default vlan.

Another thing I can try is use tcpdump and Wireshark to check the packages arriving and how they are tagged.

[lleachii]

At this juncture...I would test explicitly putting a block rule to stop forward of traffic from the MAC on 10.25.100.1 from forwarding to WAN.

I think the zone FORWARD is only regarding going to another interface in the zone, not another IP that routes (when I test I get ICMP errors trying to use 2 routers in the same network, so I haven't replicated this 2 router thing - which I still don't understand its need).

[trendy]

I would test by connecting one host directly on the router, that is exclude the switch from the picture. Test with untagged frames, then tag vlans 9 and 100, verify you get dhcp and test access to the internet.

[lleachii]

@trendy

that is exclude the switch from the picture

He can also stop forwarding traffic from the Pi to the "switch" running OpenWrt.

(Recall this "switch" is the "OpenWrt device" )

[trendy]

Maybe you have a point but if I am not mistaken the switch is not running any *Wrt.

@Nikotine

This is the setup of the switch:

ICX6450-48P-Router>show run
Current configuration:
!
ver 08.0.30tT313

[lleachii]

@trendy

but if I am not mistaken the switch is not running any *Wrt.

@Nikotine

main OpenWRT home network 192.168.1.1/24

@Nikotine

config interface 'wan'
        option ifname 'eth0'
        option proto 'dhcp'
        list dns '1.1.1.1'
        list dns '1.0.0.1'
        option peerdns '0'

@Nikotine

config interface 'vlan100'
        option ifname 'eth1.100'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '10.25.100.1'

@Nikotine

 2  FriendlyWrt.lan (10.25.100.1)  0.614 ms  0.490 ms  0.827 ms
 3  192.168.1.1 (192.168.1.1)  2.076 ms  3.940 ms  1.789 ms

@Nikotine

FriendlyWRT IS Openwrt.

Are you sure @trendy?

(And I assume the network is 192.168.1.0/24.)

[trendy]

I suppose @Nikotine should clarify that, but the way I understand it, it is:
internet - main OpenWrt Router - FriendlyWrt Router - SomeSwitch

[lleachii]

@trendy

I suppose @Nikotine should clarify that, but the way I understand it, it is:
internet - main OpenWrt Router

(As I understood, he doesn't have an official device...perhaps he should re-clarify...)

@lleachii

Now I understand the confusion, you kept mixing FriendlyWRT and OpenWrt.

@lleachii

I thought another device was running FriendlyWRT and one OpenWrt - since this support is only for official software, I never guessed you were continuing about unsupported software, my apologies.

EDIT:

@Nikotine

The Nanopi runs Friendlywrt = Openwrt.
The Nanopi is .1 yes.

[Nikotine]

@trendy

Maybe you have a point but if I am not mistaken the switch is not running any *Wrt.

Correct.
I've made you a sketch, lleachii

@lleachii

this 2 router thing - which I still don't understand its need).

At this point, it's more a case of whether it can be done, instead of should it be done.
I bought this switch to learn a bit about networking, I'm a pharmacist for Pete's sake
And I still have the feeling that what I want is possible, and that there is speed to gain when not all traffic has to pass the OpenWRT router first for inter-vlan routing on the switch.

@trendy

I would test by connecting one host directly on the router, that is exclude the switch from the picture. Test with untagged frames, then tag vlans 9 and 100, verify you get dhcp and test access to the internet.

Thanks, yes another thing I can try.

[lleachii]

@Nikotine

@trendy

Maybe you have a point but if I am not mistaken the switch is not running any *Wrt.

Correct.
I've made you a sketch, lleachii

Your picture contradicts your statement!

To be clear, we're talking about this device????

@Nikotine

At this point, it's more a case of whether it can be done, instead of should it be done.

OK...true...trying to understand the diagram now...

[Nikotine]

@lleachii

@trendy

I suppose @Nikotine should clarify that, but the way I understand it, it is:

internet - main OpenWrt Router

(As I understood, he doesn't have an official device...perhaps he should re-clarify...)

The "WWW" cloud in the drawing above in fact is another router, running official OpenWRT.
But from the Nanopi's perspective, that's just WAN, so out of the equation here.

[lleachii]

@Nikotine

But from the Nanopi's perspective, that's just WAN, so out of the equation here.

That's not true!!!

@Nikotine

The client:

pi@rpi4-servemepi:~ $ ifconfig

@Nikotine

pi@rpi4-servemepi:~ $ traceroute -i eth0 google.com
traceroute to google.com (172.217.17.46), 30 hops max, 60 byte packets
 1  10.25.100.2 (10.25.100.2)  1.074 ms  1.558 ms  2.118 ms
 2  FriendlyWrt.lan (10.25.100.1)  0.614 ms  0.490 ms  0.827 ms
 3  192.168.1.1 (192.168.1.1)  2.076 ms  3.940 ms  1.789 ms
 4  192.168.0.1 (192.168.0.1)  4.673 ms  3.621 ms  5.529 ms

Are you actually looking at the traceroute?

@Nikotine

The "WWW" cloud in the drawing above in fact is another router running official OpenWRT.

???

• Can you actually identify the device we're helping you with???
• This device must be running Official OpenWrt.

[trendy]

Alrighty, try to test with the Rpi directly connected on the NanoPi, using the proper tags or without tagged frames and verify everything works as it should.
I am afraid this is all we can go, since this is an OpenWrt forum and none of the above mentioned devices are running OpenWrt. Even if FriendlyWrt derives from OpenWrt, we are not able to replicate any issues you might face and you'll have better luck at the support forum of FriendlyWrt.
However I strongly believe that it is not that terrible and you merely were routing with the switch instead of switching.

[Nikotine]

@lleachii

@Nikotine

But from the Nanopi's perspective, that's just WAN, so out of the equation here.

That's not true!!!

@Nikotine

The client:

pi@rpi4-servemepi:~ $ ifconfig

@Nikotine

> pi@rpi4-servemepi:~ $ traceroute -i eth0 google.com
traceroute to google.com (172.217.17.46), 30 hops max, 60 byte packets
 1  10.25.100.2 (10.25.100.2)  1.074 ms  1.558 ms  2.118 ms
 2  FriendlyWrt.lan (10.25.100.1)  0.614 ms  0.490 ms  0.827 ms
 3  192.168.1.1 (192.168.1.1)  2.076 ms  3.940 ms  1.789 ms
 4  192.168.0.1 (192.168.0.1)  4.673 ms  3.621 ms  5.529 ms
> ```

Are you actually looking at the traceroute?

Yes lleachii, I'm looking.
Again:
10.25.100.2 = virtual router interface on the Brocade switch
10.25.100.1 = interface on the Nanopi running Friendlywrt <= we are talking about this device here
192.168.1.1 = LAN interface on the WRT1900AC router, running official OpenWRT <= as far as the Nanopi is concerned, this is its WAN
192.168.0.1 = WAN interface on the WRT1900AC (connected to ISP router)

I'm trying to stop traffic between 10.25.100.1 and 192.168.1.1, on the Nanopi.