Question about VLANS

[Crusty]

So, I've got a network with 2 VLANS setup, one 192.168.1.0/24, and the other 192.168.2.0/24. The firewall is set to drop all traffic between the 2 VLANS and there are no routes between them. What is the best way to share a standalone network printer?

I was thinking of creating a 3rd VLAN on 192.168.3.0/24 and allowing VLAN1<->VLAN3 traffic, and VLAN2<->VLAN3 traffic while still denying VLAN<->VLAN2.

Is this the best way, or even the proper way?

 

[spidey07]

Best way would be to open the necessary ports on the firewall.

 

[Crusty]

So put the printer on either VLAN1 or VLAN2, and just allow traffic on the ports the printer uses to the printers IP. I guess that make sense 😛

 

[spidey07]

Why complicate things? Keep It Simple Stupid.

 

[jlazzaro]

:lips:

 

[Crusty]

Okay, I've finally gotten around to setting up my jetdirect print server on the network. The printer is attached to VLAN1 and given an static IP through DHCP (192.168.1.7)

My current iptables ruels are as follows.

iptables -I INPUT -i vlan2 -j ACCEPT
iptables -I FORWARD -i vlan2 -o vlan1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan2 -o ppp0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j logdrop


br0 is just a bridge between the VLAN1 and the wireless LAN interface.
how would I modify them to allow the printer to be accessed from VLAN2 as well.

I know it uses port 9100 for printing and I assume I need to allow both IP and TCP connections.

My problem is that I am such an iptables noob 🙁

 

[p0lar]

Originally posted by: Crusty
My current iptables ruels are as follows.

iptables -I INPUT -i vlan2 -j ACCEPT
iptables -I FORWARD -i vlan2 -o vlan1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan2 -o ppp0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j logdrop

My problem is that I am such an iptables noob 🙁

<rant>

Yet another fine example why IPTABLES will remain in the pitiful state it is in, syntax-nasty 101: dash-this, dash-that, forward here, input there, accept over here, deny over there, postroute, masquerade, order-of-operations huh? Pre-route, post-route, caveat-here-and-there...

Clear documentation-wha?
</rant>

The guy never had a chance.

 

[Crusty]

Originally posted by: p0lar

Originally posted by: Crusty
My current iptables ruels are as follows.

iptables -I INPUT -i vlan2 -j ACCEPT
iptables -I FORWARD -i vlan2 -o vlan1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan2 -o ppp0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j logdrop

My problem is that I am such an iptables noob 🙁

<rant>

Yet another fine example why IPTABLES will remain in the pitiful state it is in, syntax-nasty 101: dash-this, dash-that, forward here, input there, accept over here, deny over there, postroute, masquerade, order-of-operations huh? Pre-route, post-route, caveat-here-and-there...

Clear documentation-wha?
</rant>

The guy never had a chance.

Unless you have something helpful to say, please kindly get out of my thread 🙂

 

[p0lar]

Originally posted by: Crusty
Unless you have something helpful to say, please kindly get out of my thread 🙂

My apologies, I wasn't trying to poo-poo your thread, only the unfortunate predicament you are in due to IPTABLES syntax. I digress..

As an alternative, have you considered using OpenBSD's PF in place of iptables? You can enable it on Free/Net/OpenBSD and is, IMHO, considerably easier to configure, diagnose, and read than all but the best inline-documented iptables implementations.

You can find thorough documentation here.

A very quick yet fully operable and secure example:

# Define variables/macros/lists
printer="192.168.1.7"

# Default Deny for ALL interfaces
block log

# Allow previously permitted traffic tagged on incoming interfaces to exit others
pass out quick tagged allowed

# Permit vlan0 network scope to reach the printer on TCP/9100, tag the packet so that it can exit vlan1
pass in on vlan0 inet proto tcp from vlan0:network to $printer port 9100 tag allowed

Perhaps not helpful, but does give you some insight to alternatives. Good luck with the IPTABLES either way.

 

[Crusty]

Not really an option, i'm stuck with the software i've got.