LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 01-14-2016, 05:54 AM   #1
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Rep: Reputation: Disabled
Learning vlan's and need some expertise help...


Let me say right out of the gate that I'm new to network configuration and especially VLAN's and bridging but what I'm trying to accomplish is nearly complete but for that missing puzzle piece that I need some expertise help with..

I am trying to create a Bridge on my router using DD-WRT, that allows one way communication so that it will isolate my webserver on VLAN2 but allow VLAN1 access to the webserver but not allow VLAN2 access to VLAN1.

By default DD-WRT allows this setup and I have successfully created the 2 bridges along with the VLAN's, now for the problem I'm facing. I cannot ping behind each gateway leading me believe there is one piece missing.

Hardware - Nighthawk R7000
Firmware: DD-WRT v3.0-r28000M kongac (10/24/15)

br0/vlan1 = 192.168.3.0
GW = 192.168.3.1

br1/vlan2 = 192.168.2.0
GW 192.168.2.1

Pinging from a machine on on VLAN1 (192.168.3.100) is able to ping the gateway 192.168.2.1 but not a machine behind it e.g. 192.168.2.11 and vice versa a machine on VLAN2 (192.168.2.100) is able to ping the GW 192.168.3.1 but not a machine behind it e.g. 192.168.3.100.

So this tells me that br0 and br1 can see each other but way nothing behind the gateway?? Here is what I can discern from the configuration of the router..

Code:
root@DD-WRT:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 br1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

root@DD-WRT:~# nvram show | grep vlan.*ports
vlan0ports=3 2 1 0 5*
vlan1ports=4 5
size: 23484 bytes (9284 left)

root@DD-WRT:~# nvram show | grep port.*vlans
port5vlans=0 1 2 16
port3vlans=0 18 19
port1vlans=0 18 19
port4vlans=2 18 19
size: 23484 bytes (9284 left)
port2vlans=0 18 19
port0vlans=1 18 19

root@DD-WRT:~# nvram show | grep vlan.*hwname
vlan1hwname=et0
size: 23484 bytes (9284 left)
vlan0hwname=et0

root@DD-WRT:~# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 659 packets, 58186 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       icmp --  *      *       0.0.0.0/0            0.0.0.0             to:192.168.3.1
    0     0 TRIGGER    0    --  *      *       0.0.0.0/0            0.0.0.0             TRIGGER type:dnat match:0 relate:0

Chain POSTROUTING (policy ACCEPT 2 packets, 656 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     0    --  *      br0     0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
    2   656 MASQUERADE  0    --  *      br0     192.168.3.0/24       192.168.3.0/24

Chain OUTPUT (policy ACCEPT 4 packets, 1312 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
root@DD-WRT:~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6543 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5233 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:500027 (488.3 KiB)  TX bytes:361181 (352.7 KiB)

br0:0     Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

br1       Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1142 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1669 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:101084 (98.7 KiB)  TX bytes:1565999 (1.4 MiB)

eth0      Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10774 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14661 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1174049 (1.1 MiB)  TX bytes:4997609 (4.7 MiB)
          Interrupt:4

eth1      Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D8
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:9 dropped:0 overruns:0 frame:387848
          TX packets:1362 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:225526 (220.2 KiB)
          Interrupt:2 Base address:0x5000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:618 (618.0 B)  TX bytes:618 (618.0 B)

vlan0     Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6553 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5233 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:526949 (514.5 KiB)  TX bytes:382113 (373.1 KiB)

vlan1     Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D7
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4828 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:1583584 (1.5 MiB)

vlan2     Link encap:Ethernet  HWaddr 00:14:BF:2A:FE:D6
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4237 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4614 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:454398 (443.7 KiB)  TX bytes:2965968 (2.8 MiB)
Any help or insight it surely appreciated and welcomed.

ampapa,
 
Old 01-14-2016, 02:26 PM   #2
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
Hi,

I don't get the postrouting rules

I think to make 192.168.2.0/24 reachable from 192.168.3.0/24 but not vice versa

I don't have a machine in reach to test it (maybe some typos)
The first one makes it possible for 192.168.2.0 to answer to whatever (also the active FTP stuff)
the second line allow traffic to your webserver from your other subnet
the last drops traffic in the other way that was not allowed by the first line

iptables -A POSTROUTING -s 192.168.2.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -s 192.168.3.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -A POSTROUTING -s 192.168.2.0/24 -d 192.168.3.0/24 -j REJECT

Grts
 
Old 01-14-2016, 02:43 PM   #3
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
Many thanks for the reply tlowk.

By default the router created the routes and the iptable entry's so I can't help on those.

If I'm able to ping the Gateway from each subnet 192.168.1.100 => 192.168.2.1 and 192.168.2.100 => 192.168.3.1 does that mean the bridge is setup correctly?

If that is true, then does this become strictly a firewall problem? I'm trying to figure out what is working and what isn't working to eliminate the things that are working correctly from the problems... so I can focus my attention.

Assuming it is a firewall issue would shutting it down affect the outcome or will it still need iptables in order to pass the packets between the subnets?
 
Old 01-14-2016, 02:48 PM   #4
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
You can see the bridges with the command

brctl show

(brctl addif and brctl defif make it possible to add and remove interfaces from a bridge)

I hope the distro you have uses the brctl command if not, it is possible with the ip command
but that I need to look up myself.
 
Old 01-14-2016, 02:58 PM   #5
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
I don't know if iptables are made peristent on these devices, but once the bridges are correct, you arrive at the point
where firewall rules apply.
 
Old 01-14-2016, 04:00 PM   #6
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
Thanks, I'll do a little digging on the bridges tonight and post the findings a later just as an FYI...

I'll give the iptables entries a go as well..
 
Old 01-15-2016, 08:10 AM   #7
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
I wasn't having much luck last night getting iptables to take the new entry's... not sure what I'm doing wrong, so I don't have an update as of yet.

Seems like it should be straight forward, but I'm having issues with it
 
Old 01-15-2016, 09:21 AM   #8
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
I'm a bit suprised at this moment, so lets try to find out how far it works.

You could also try to use tcpdump on the webserver and see if the pings arrive there, then the problem would be only
to get the reply back to the sender.

try something like this on the webserver, and maybe also at the other side
tcpdump -i eth0 icmp
 
Old 01-15-2016, 09:37 AM   #9
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
I was able to get the bridge info.

Code:
root@DD-WRT:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0014bf2afed6       no              vlan0
                                                        eth1
br1             8000.0014bf2afed6       no              vlan2

I also ran this on a working router... in this case there isn't a second bridge just a vlan but I noticed the additional POSTROUTING information for both subnets.


Code:
root@DD-WRT-Lower:~# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 381K packets, 39M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 1311 packets, 76053 bytes)
 pkts bytes target     prot opt in     out     source               destination
 144K   11M SNAT       0    --  *      vlan1   0.0.0.0/0            0.0.0.0/0           to:myIP
    0     0 RETURN     0    --  *      br0     0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
  383  125K MASQUERADE  0    --  *      br0     192.168.3.0/24       192.168.3.0/24
    0     0 RETURN     0    --  *      vlan2   0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
    0     0 MASQUERADE  0    --  *      vlan2   192.168.2.0/24       192.168.2.0/24

Chain OUTPUT (policy ACCEPT 15713 packets, 1165K bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Old 01-15-2016, 09:51 AM   #10
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
Having vlan0 and vlan1 in the POSTROUTING is probably harmless

this rule handled some packets but I do not see what good it does
383 125K MASQUERADE 0 -- * br0 192.168.3.0/24 192.168.3.0/24


the source and the destination is the same (192.168.3.0/24) but in that case there is no reason
why the packets go via the device (use it as a gateway)

144K 11M SNAT 0 -- * vlan1 0.0.0.0/0 0.0.0.0/0 to:myIP

Here the source net could be 192.168.0.0/16 but it will probably work like it is (a log of traffic
followed that rule)

When I look to the routing table there is no default, but I assume it must be connected to vlan1, but I do not see
an ip address on it either.
 
Old 01-16-2016, 07:40 AM   #11
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
No joy here...

I had to use the following to get the iptables into the firewall.
Quote:
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d 192.168.3.0/24 -j REJECT
I'm hearing some grumblings that its possible to be a hardware limitation of the router that might be causing me the problems.. however it seems to me that since I can ping the gateway's on each subnet that I just find that hard to believe, I'm also very stubborn... lol!

So any ideas on how I might be able to track this down and figure out what's going on?
 
Old 01-17-2016, 04:46 AM   #12
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
Hi,

I don't expect that the hardware would be a limitation. I think it is unlikely if your has a managed switch that gives you vlans as separate ports it cannot handle this.


On the iptables output you can see the packets that are handled by a rule this can help to see what happens and you can
also use tcpdump to check if a ping package arrives at a machine, then you need to check if the reply goes the right way.

Maybe you can also use tcpdump at the device.

this way you could see what happens and maybe start in a different way. For example start fist to get both networks without worrying external connectivity.

Grts
 
Old 01-19-2016, 09:01 PM   #13
ampapa
LQ Newbie
 
Registered: Feb 2012
Posts: 28

Original Poster
Rep: Reputation: Disabled
tlowk, after many frustrating hours I was finally able to determine the problem was firewall related on the machines behind the gateway's. They both were Windows 7 machines that did not alloy Ping's..

Had I been smart enough to start there I could have saved myself and you the frustration.

Many thanks for your efforts and willingness to help, your what makes user forums work.

ampapa,
 
Old 01-20-2016, 12:18 AM   #14
tlowk
Member
 
Registered: Nov 2003
Location: Belgium
Distribution: Slackware
Posts: 184

Rep: Reputation: 36
I must admit I don't know much about the strange behavior of windows machines. I assumed that replying to a ping is part of an IP implementation. The windows machines would have given this behavior away with tcpdump or wireshark, but I don't know whether this is available on them.

I'm glad it works after all.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Open Faculty Expertise grant helps teachers gain necessary expertise LXer Syndicated Linux News 0 11-02-2012 02:50 PM
Route non-vlan packet to a vlan interface mic.sed Linux - Networking 2 04-23-2010 02:39 AM
I'm interested in learning about implementing VLAN tagging into iptables... trist007 Linux - Newbie 1 03-28-2010 05:46 AM
DHCP Config for VLAN's using 1NIC and non VLAN router. scottgutman Linux - Networking 1 07-22-2009 01:41 AM
VLAN configuration - native VLAN and setting PVID kumarwaiting Linux - Networking 0 07-24-2006 02:51 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 05:02 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration