Creating VLAN and IPTABLES questions...

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Wed May 05, 2021 21:20    Post subject: Creating VLAN and IPTABLES questions... Reply with quote
I'm wanting to create a separate network segment to isolate 1 machine on 192.168.2.0 (no WAN access) and remaining machines 192.168.3.0 (WAN access)

I've successfully change P4 on my router to vlan3 (192.168.2.0) and the remaining ports are on vlan1 (192.168.3.0).

I've unbridged vlan3 and set the IP address and applied the settings.

From here I would anticipate that the segments as expected can't talk to each other without setting up some firewall rules, before I go to the firewall commands did I miss anything above?

The firewall rules I've tried are the following without success?


Code:

iptables -I FORWARD -i vlan1 -o vlan3 -j ACCEPT
iptables -I FORWARD -i vlan3 -o vlan1 -j ACCEPT


Do I need to add anything for br0 like the following and what exactly is br0??

Code:

iptables -I FORWARD -i br0 -o vlan3 -j ACCEPT
iptables -I FORWARD -i vlan3 -o br0 -j ACCEPT


Any help would be appreciated here.. I'm pretty green at this.
Sponsor
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Wed May 05, 2021 23:19    Post subject: Reply with quote
If you aren't trying to isolate the one machine from the others but only from the WAN (internet), VLANs are the hard way to do it. Just give the one machine a static IP lease, either in GUI>Services>Services in the section dedicated to that or with the Additional Dnsmasq options (heavily discussed... search), and then add a single firewall rule to keep that IP, call it XX.XX.XX.XX here, from reaching the WAN. I'll also assume your WAN interface is eth0. Edit as appropriate or use one of the many ways discussed in the forums to determine it automatically and assign it to a shell variable like WAN_IF so that you can use $WAN_IF instead of eth0 here:

iptables -I FORWARD -s XX.XX.XX.XX -o eth0 -j REJECT

You can use DROP instead of REJECT if you'd prefer your banned machine not know it has been banned but only that it is not getting through.

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Thu May 06, 2021 11:01    Post subject: Reply with quote
Many thanks for the reply SIW.

In your suggestion I believe that leaves the one machine on the same network segment correct?

WAN access restriction to this machine is important so I'm curious why the firewall rule for blocking eth0 and not br0 as seen in the image of my current bridging table, is eth0 specifically the WAN?

To create the machine on a new segment the only option is to create a Vlan, is that correct?

ampapa,
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Thu May 06, 2021 14:41    Post subject: Reply with quote
Yes, what I suggest would leave the one specific machine on the same network segment as everything else.

You need VLANs if you need subsets of the LAN ports to be isolated from each other. I have ports 1 and 2 on a household VLAN and bridge (bridged with a wifi interface) and ports 3 and 4 on a an office VLAN and bridge (different wifi) so that malware on home machines (imagine having a click-everything household member!) can't find or interact with office machines. You still need firewall rules, but without VLANs there is no way the firewall can address that situation, because packets flowing between LAN ports (on the same VLAN) are not seen by the firewall at all. The situation is similar for traffic between clients on the same bridge. That traffic is not seen by the firewall either. Its only once traffic leaves the bridge (or unbridged wifi interface) that the firewall can have a look at it.

And yes, on my routers eth0 is the WAN interface. This is standard in the modern Linksys WRT... series. Other routers may have it on eth1 or on vlan2 or whatever. Some ways to determine and assign the interface name to variable WAN_IF:

WAN_IF=`nvram get wan_iface`

You'll see that a lot in old discussions. The backquotes are hard to see (for some of us) and distinguish from single quotes ' however, so that's considered poor practice now, and the preferred alternative form is

WAN_IF=$(nvram get wan_iface)

In some circumstances, this nvram variable is empty, however, like in some client-mode setups. You can try variable wan_iface2 instead, as this seems to work in some settings, though I am ignorant as to the distinction between the two variables or whether I am doing something dumb by depending on the 2 version. An alternative that has become popular because it works in more setups is this:

WAN_IF=$(ip route | awk '/^default/{print $NF}')

This identifies the WAN interface by using ip route to look at the routing table and then awk to strip the WAN interface name from the default line. Recently I got into a situation where my nvram memory was so full that every little bit I could shave from my Startup and Firewall setups mattered. That suggests a very minor tweak:

WAN_IF=$(ip r | awk '/^def/{print $NF}')

I now regard this as the preferred form for the Firewall commands. For Startup commands, however, it can be executed so early that the routing table is not yet set up. The WAN_IF variable then comes up empty. When I met this, I simply polled to see whether the table was there with a default line yet, at the cost in my case of delaying other Startup actions by about 7 seconds. This polling version for Startup uses intermediate variable L (for "Line") and is also sqeezed spacewise:

until L=$(ip r|grep ^def); do sleep 1; done
WAN_IF=${L#*dev}


the grep gets the routing-table line, once it exists, that sets the default route. The line goes into variable L, and the WAN_IF= assignment then strips away the first part of the line, everything up to and through the string "dev". This approach also leaves the interface name in WAN_IF with a single space on each side, but this is harmless in the iptables commands discussed here.

So there are many ways! If you are of the keep-it-simple school though, just do nvram get wan_iface in the CLI and if the result is not empty, use it directly in a firewall command. No need to get fancy. I'm making this an encyclopedia for the wider readership, since this business seems to come up over and over.

I suggested -j REJECT in the firewall rule, with -j DROP as an alternative. Another alternative, one that is probably the best of the three, is REJECT --reject-with icmp-host-prohibited to use an ICMP message packet back to the client to explicitly notify it that it (the host) is prohibited from sending such packets. Perhaps it won't know why, but at least we tried to tell it.

Finally, on many combinations of router/build you can actually skip using a static lease and just screen out packets headed for the WAN by looking at the MAC address of their source. Here then is my MAC version using the simplest nvram determination of the interface but eliminating the middleman of the WAN_IF variable:
Code:
iptables -I FORWARD -o $(nvram get wan_iface) \
-m mac --mac-source 12:34:56:78:90:ab \
-j REJECT --reject-with icmp-host-prohibited
Of course replace 12:34:56:78:90:ab with the MAC address of the client to be kept offline. Breaking the command into multiple lines using \ at the end of lines that are to be continued is of course completely optional. Its a readability thing. Note that Windows 10 can be set to use a fixed MAC address or to use a random one. Somewhat similarly, iOS can be set to use a "private address" that is different for each wifi network but always the same for a given wifi network.

There are settings in which you don't want to prohibit all traffic to the WAN but only new connections. I believe you can just add -m state --state NEW to the iptables command in such a case.

Some readers prefer a short "just do this" response to questions. When I have the time, I prefer the "teach a man to fish" approach.

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Thu May 06, 2021 16:04    Post subject: Reply with quote
Much appreciate the in depth discussion. It's difficult to learn if everyone just says do this..

I think I have a "working" vLan setup currently by using vLan1 and vLan3, also needing to add a new bridge br1.

I was originally under the impression that I could just setup the 2 vLans and apply some firewall rules to allow/restrict communication. Without the bridge neither vLan could "talk" to each other.

Now that I have br1, vLan1 and vLan3 talking. I'm not sure what communication is enabled or disabled by default??? is that visible somewhere so that I can figure out what traffic either needs to be allowed/disallowed in firewall rules?

Meaning by default can br1 talk directly to br0 and have full access? Does br1 use the dns servers of br0 since there's no entry for that information?
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Thu May 06, 2021 18:49    Post subject: Reply with quote
By default everyone talks to everyone.

There is no way to keep users of a single VLAN from talking to each other. Same for LAN-port users if you have not configured VLANs. This connectivity is at the level of a hardware switch directly attached to LAN ports. When you set up VLANs, you are reconfiguring this switch, among other things.

Then within a bridge, there is automatic connectivity also. It happens in software but only barely removed from the hardware level. I think people call this level-2 connectivity, but I'm not a networking guy, just a curious amateur.

Level 3, the networking level, is where packets are exchanged between level-2 entities like bridges and unbridged interfaces. At this level a firewall and a configurable routing process are involved.

In the br1 section of the Networking subtab you can enable "Net Isolation" to isolate it from br0 with firewall rules. That setting is always to isolate from br0, so it only makes sense when there are only two subnets, the br0 "main" subnet and a second subnet like br1. There is a similar setting for unbridged wifi interfaces, but again, it only isolates from br1. Isolating more than two subnets from each other requires custom firewall rules.

The router has a single DNS system shared by all subnets, VPNs, etc. You can configure to pass different DNS-server IPs to different clients or to clients in different subnets if you wish (find the "man page" for DNSMasq), but when you just pass the subnet IP to clients in the normal way, DNS queries go to the single DNSMasq system in the router, which is what forwards queries to the servers you named in the GUI.

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 4402
Location: UK, London, just across the river..

PostPosted: Thu May 06, 2021 19:13    Post subject: Reply with quote
although they mean the same, in some very narrow scenarios get_wanface is better than nvram get wan_iface Rolling Eyes Laughing
_________________
Atheros
TP-Link WR740Nv1 -----DD-WRT 46974 BS AP,NAT
TP-Link WR740Nv4 -----DD-WRT 44251 BS WAP/Switch
TP-Link WR1043NDv2 ---DD-WRT 46885 BS AP,NAT,AP Isolation,Ad-Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---DD-WRT 46974 BS AP,NAT,AD/Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Qualcomm/IPQ8065
Netgear R7800 -----DD-WRT 46979 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Broadcom
Netgear R7000 -----DD-WRT 46979 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,VLAN's,DoT,VPN
-----------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 by mac913
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Thu May 06, 2021 22:28    Post subject: Reply with quote
SurprisedItWorks wrote:
By default everyone talks to everyone.

There is no way to keep users of a single VLAN from talking to each other. Same for LAN-port users if you have not configured VLANs. This connectivity is at the level of a hardware switch directly attached to LAN ports. When you set up VLANs, you are reconfiguring this switch, among other things.


If I understand you correctly, moving a PORT on the router to a new vLan (vLan3) would not allow it to directly talk to the other vLan (vLan1). It is in fact separating at the hardware level, if I understood correctly. Would this, vLan's, be considered Level1, not that it matters?

Does the vLan then require a bridge to be able to talk to the other vLan? or can they directly talk to one another?

This is why the need for Firewalling off what communications you do not want happening between the 2 vLan's..
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Fri May 07, 2021 1:19    Post subject: Reply with quote
I believe that clients of different VLANs and different bridges have to communicate with each other at level 3 via router comm and through the firewall, but in dd-wrt the firewall permits it by default. At this level an interface (wlan1 or eth1 for example), a VLAN (which is an unbridged interface if not added to a bridge), and a bridge have equal status and are treated alike when setting up firewall rules with iptables. So no, you do not need your VLANs to be bridged in order for their clients to communicate. BUT... these separate entities communicating at level 3 are on different IP subnets, and Windows network discovery (looking around to see what's on the network) won't work across subnet boundaries. So if you want them to be one big happy discovery family, either bridge them or ask yourself "Self, why do you want them in separate VLANs at all?"
_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 4402
Location: UK, London, just across the river..

PostPosted: Fri May 07, 2021 6:47    Post subject: Reply with quote
To my understanding, vlans assigned to bridges, can be isolated with IPtables rules regarding bridges...layer 3...
and yes as SurprisedItWorks noted, all devices on those vlans or inside br, cannot be isolated from internal communications in between on layer 2...
Only default wlan via GUI has, so called 'AP isolation' witch is related to devices MAC addresses isolation...to no communicate on layer 2...'kind of'

ebtables rules can do some layer 2 stuff, but their use is not very recommended, as they take a big toll on performance side...

_________________
Atheros
TP-Link WR740Nv1 -----DD-WRT 46974 BS AP,NAT
TP-Link WR740Nv4 -----DD-WRT 44251 BS WAP/Switch
TP-Link WR1043NDv2 ---DD-WRT 46885 BS AP,NAT,AP Isolation,Ad-Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---DD-WRT 46974 BS AP,NAT,AD/Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Qualcomm/IPQ8065
Netgear R7800 -----DD-WRT 46979 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Broadcom
Netgear R7000 -----DD-WRT 46979 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,VLAN's,DoT,VPN
-----------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 by mac913
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Fri May 07, 2021 14:46    Post subject: Reply with quote
Alozaros wrote:
although they mean the same, in some very narrow scenarios get_wanface is better than nvram get wan_iface Rolling Eyes Laughing

Thanks Alozaros... I always forget about this function! Am setting up a test now to see whether it picks up the interface before the routing table does. Will edit this post when that becomes clear.

Edit: in my primary router get_wanface does indeed pick up the correct WAN interface before the routing table has that information. I need to try it on my client-mode travel router next. The latter router does not set nvram variable wan_iface to the wifi interface used for WAN connectivity, so it's a different use case.

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.


Last edited by SurprisedItWorks on Sat May 08, 2021 17:31; edited 1 time in total
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Fri May 07, 2021 18:57    Post subject: Reply with quote
Many thanks for the information and conversation it has been very helpful and insightful.

Would anyone be willing to help me analyze my Firewall rules to make sure they make sense and are doing what I'm expecting them to do?

Code:
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -I INPUT -i br1 -m state --state NEW -j DROP
iptables -I INPUT -i br1 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o $WAN_IF -j MASQUERADE


Does this DROP forwarding new packets from br1 to br0?
Quote:
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP


Does this DROP new packets for br1?
Quote:
iptables -I INPUT -i br1 -m state --state NEW -j DROP


Does this allow tcp/udp traffic to DHCP and DNS for br1?
Quote:
iptables -I INPUT -i br1 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT


I believe these lines are for OpenVPN?
Quote:
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o $WAN_IF -j MASQUERADE
ampapa
DD-WRT User


Joined: 25 Nov 2011
Posts: 102

PostPosted: Mon May 10, 2021 14:56    Post subject: Reply with quote
Should I assume no news is good news?
Per Yngve Berg
DD-WRT Guru


Joined: 13 Aug 2013
Posts: 6140
Location: Romerike, Norway

PostPosted: Mon May 10, 2021 15:19    Post subject: Reply with quote
Does this DROP new packets for br1?
Quote:
iptables -I INPUT -i br1 -m state --state NEW -j DROP

No, it drops packets coming in on br1 destined for a process on the router.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Mon May 10, 2021 15:28    Post subject: Reply with quote
Can't assume anything beyond that volunteers have lives and get busy, and perhaps that when you appear to be "assigning homework" in a pretty big pile, you are going to lose potential respondents who only have a moment.
ampapa wrote:
Many thanks for the information and conversation it has been very helpful and insightful.

Would anyone be willing to help me analyze my Firewall rules to make sure they make sense and are doing what I'm expecting them to do?

Code:
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -I INPUT -i br1 -m state --state NEW -j DROP
iptables -I INPUT -i br1 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o $WAN_IF -j MASQUERADE


Does this DROP forwarding new packets from br1 to br0?
Quote:
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP

Yes. But if you check "Net Isolation" in the br1 GUI>Networking, dd-wrt will install a stronger (not limited to NEW connections) this rule for you, along with a similar one in the other direction. The only reason to to leave the feature disabled and go the DIY route would be if you want something different.
Quote:
Does this DROP new packets for br1?
Quote:
iptables -I INPUT -i br1 -m state --state NEW -j DROP

It drops new packets FROM br1... to anywhere (other than br1). So it means br1 clients will not see the internet, either directly or through a vpn. But perhaps you meant to include -i br0 here to make it the other half of network isolation. Same comment as above. Why?
Quote:
Does this allow tcp/udp traffic to DHCP and DNS for br1?
Quote:
iptables -I INPUT -i br1 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT

For DNS, yes. (I don't know enough about dhcp to comment.) But why would you need it? Default dd-wrt firewall rules have it covered.
Quote:
I believe these lines are for OpenVPN?
Quote:
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o $WAN_IF -j MASQUERADE

The first one appears to be a VPN rule, but it's one that the dd-wrt OpenVPN client defaults take care of (if configured properly in the GUI). You shouldn't include it explicitly in your system.

The last one is not about the VPN but appears to just duplicate a dd-wrt rule for br1 that you get if you enable "Masquerade / NAT" in the br1 section of Setup>Networking.

Overall you seem to be trying too hard. What do you really need to do with iptables that isn't more easily accomplished by clicking a box in the GUI and letting dd-wrt handle the details?

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum