Thanks for commenting, this helps to understand things much better.
At all I do believe your shorewall box is configured well (or lets say your
network configuration on box you call shorewall box)
>From the given point I do see only one logic cause of your problem.
I suppose that those packets sent from 10.5.10.2 into your switch are not
tagged well which must mean the access port (access port is the port where
your clients/phones are connected to the switch) are not configured well to
tag incoming traffic with tag 2. If this is the case they will be native
tagged (normally 1) and beeing anyway forwarded through your trunk port. On
the other side of the trunk the VLAN kernel treats the native interface (the
physical eth1 one) as vlan 1 (even if it is not especially specified to be
vlan 1 its anyway vlan1)
Since the packet which arrives from 10.5.10.2 is tagged by native vlan 1 it
is also forwarded over the trunk with tag 1 which results in beeing
terminated on vlan1 (eth1 physically) instead of vlan2. This should be the
reason why you see it arriving on vlan1 (eth1 which is actually the same
interface as vlan1) and not on vlan2 because tag2 is missing.
All what you need to do is to ensure, that your access ports in Netgear will
tag traffic well. You just have to move their access vlan to 2 (dont mix up
with trunk, you must configure as access). The major difference between
access and trunk ports are trunk port forward vlan tags to remote machines
where access ports keep the tag locally.
Try it and tell me if it works.
Cheers
Michael
_____
Von: Stephen Brown [mailto:[email protected]]
Gesendet: Donnerstag, 25. November 2010 22:55
An: Shorewall Users
Betreff: Re: [Shorewall-users] VLAN martians
Thanks Michael, I'll admit I'm quite a newbie with this, but I'm doing it
self educate so I have an understanding of how this is expected to work.
To give you an idea of my goal as well as network topology, it consists of
this:
Shorewall box with two network cards, eth0 is on a Comcast Business class
modem with 5 public IP's. eth1 serves the local network and (hopefully at
some point) vlan2, and maybe a 3rd vlan in the future. eth1 is cabled to
port 24 on a Netgear GS724T-300 gigabit switch, which to the best of my
knowledge is setup as a trunk port.
Here's the output of /proc/net/vlan/config:
r...@bubastis:/etc/shorewall# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan2 | 2 | eth1
Trying to keep everything on one network card if it's possible.
Thanks,
Stephen
On 11/25/10 4:23 PM, Michael Weickel - iQom Business Services GmbH wrote:
Could you please send
cat /proc/net/vlan/config
Actually its very strange to me that you try to make subifs while using the
physical interface as well. This is normally not what needs to be done.
Either you go by layer-3 physical ip interface or you consider it to be
"null" (which obviously means to treat the interface in a trunking mode) by
having as many layer-3 vlan subifs as you like.
This configuration may causes your martian log or in other words causes why
your packet arrives on eth1 instead of vlan2 because your vlan kernel may
get confused by that configuration. On a tagged interface there should be
nothing but tagged packets. To have a mix of tagged and untagged packets in
one and the same routed interface is maybe not what you want.
Try to use another physical interface or switch your local lan segment to be
e.g. vlan 3. If I got your right you have a 802.1q enabled switch. So try to
move your local network on that switch into access vlan 3 and your voip
network should already stay in access vlan 2.
This configuration should work as you expect it.
Let me now whats going on, we may figure it out. All what I can offer to you
is to reproduce each time on one of our machines with vlan support enabled.
Cheers
Michael
_____
Von: Stephen Brown [mailto:[email protected]]
Gesendet: Donnerstag, 25. November 2010 21:26
An: Shorewall Users
Betreff: Re: [Shorewall-users] VLAN martians
Thanks Tom, here's the output of shorewall show routing:
Shorewall 4.4.11.6 Routing at bubastis - Thu Nov 25 15:22:40 EST 2010
Routing Rules
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Table default:
Table local:
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 10.5.10.255 dev vlan2 proto kernel scope link src 10.5.10.1
local 10.5.1.1 dev eth1 proto kernel scope host src 10.5.1.1
broadcast 10.5.1.0 dev eth1 proto kernel scope link src 10.5.1.1
local 70.90.228.197 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 70.90.228.199 dev eth0 proto kernel scope link src
70.90.228.197
local 10.5.10.1 dev vlan2 proto kernel scope host src 10.5.10.1
local 70.90.228.193 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 10.5.10.0 dev vlan2 proto kernel scope link src 10.5.10.1
broadcast 70.90.228.192 dev eth0 proto kernel scope link src
70.90.228.197
local 70.90.228.195 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
broadcast 10.5.1.255 dev eth1 proto kernel scope link src 10.5.1.1
local 70.90.228.194 dev eth0 proto kernel scope host src 70.90.228.197
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Table main:
70.90.228.192/29 dev eth0 proto kernel scope link src 70.90.228.197
10.5.10.0/24 dev vlan2 proto kernel scope link src 10.5.10.1
10.5.1.0/24 dev eth1 proto kernel scope link src 10.5.1.1
default via 70.90.228.198 dev eth0
And this is a sample of what I see in the logs:
Nov 25 15:24:36 bubastis kernel: [28104.130146] martian source 10.5.1.1 from
10.5.10.2, on dev eth1
Nov 25 15:24:36 bubastis kernel: [28104.130152] ll header:
d8:5d:4c:b0:70:8e:00:25:90:01:35:44:08:00
I kinda think I know what's going on, but not really.
Any help appreciated :)
Thanks,
Stephen
On 11/25/10 2:24 PM, Tom Eastep wrote:
On 11/25/10 11:11 AM, Stephen Brown wrote:
I'm playing around with VLAN's and I have a VLAN capable (layer 2) smart
switch. I see a steady stream of martians in the logfile if I have the
routefilter option set on the loc zone interfaces in
/etc/shorewall/interfaces. I have two interfaces in the loc zone, eth1
and vlan2 respectively. vlan2 is an 802.1q trunk going towards the switch.
Is this the expected behavior in this configuration? I just want to make
sure Im not missing anything because I've seen some weird stuff happening.
Here's my /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect tcpflags,nosmurfs,routefilter,logmartians
loc eth1 detect dhcp,tcpflags,nosmurfs,logmartians
loc vlan2 detect dhcp,tcpflags,nosmurfs,logmartians
And /etc/network/interfaces:
# eth1 - local lan segment (gigabit)
auto eth1
iface eth1 inet static
address 10.5.1.1
netmask 255.255.255.0
# VLAN 2 - VoIP network
auto vlan2
iface vlan2 inet static
address 10.5.10.1
netmask 255.255.255.0
vlan_raw_device eth1
I just want to make sure my approach is right with this configuration...
my end goal is to contain my VoIP network in VLAN2. So far it works, but
still a few anomalies.....
Let's be clear -- Martians have nothing to do with Shorewall and
everything to do with routing. So ignore Shorewall for now and fix your
network configuration.
If you forward:
a) The output of 'shorewall show routing'; and
b) A copy of the martian messages that you are seeing
then we may be able to help.
-Tom
----------------------------------------------------------------------------
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
----------------------------------------------------------------------------
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
