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..... Thanks, Stephen ------------------------------------------------------------------------------ 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
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 -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
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 > Shorewall-users@lists.sourceforge.net > 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
On 11/25/10 12:25 PM, Stephen Brown wrote:> Thanks Tom, here''s the output of shorewall show routing:> > 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 :)What is happening is that packets from 10.5.10.2 are arriving on eth1 even though 10.5.10.0/24 is supposedly connected to vlan2. So your VLAN configuration seems wrong. Sorry that I can''t be more specific but I have no personal experience with VLAN configuration. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
That was my suspicion as well, but I wasn''t entirely sure... thanks I''ll keep digging :) On 11/25/10 3:37 PM, Tom Eastep wrote:> On 11/25/10 12:25 PM, Stephen Brown wrote: >> Thanks Tom, here''s the output of shorewall show routing: >> 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 :) > What is happening is that packets from 10.5.10.2 are arriving on eth1 > even though 10.5.10.0/24 is supposedly connected to vlan2. So your VLAN > configuration seems wrong. > > Sorry that I can''t be more specific but I have no personal experience > with VLAN configuration. > > -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 > Shorewall-users@lists.sourceforge.net > 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
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:stephen.brown75@gmail.com] 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 Shorewall-users@lists.sourceforge.net 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
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: root@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:stephen.brown75@gmail.com] > *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 > Shorewall-users@lists.sourceforge.net <mailto:Shorewall-users@lists.sourceforge.net> > 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 > Shorewall-users@lists.sourceforge.net > 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
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:stephen.brown75@gmail.com] 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: root@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:stephen.brown75@gmail.com] 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 Shorewall-users@lists.sourceforge.net 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 Shorewall-users@lists.sourceforge.net 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
Michael Weickel wrote:>All what you need to do is to ensure, that your access ports in >Netgear will tag traffic well.I''ve seen problems before when setting up VLANs. There are often two different places the ports must be configured, and it''s not always obvious that this is the case. Yes I''ve learned this the hard way :-/ Typically there can be a screen where ports are made members of the VLANs, and configured as tagged/untagged. This covers OUTBOUND packets. There is then often a different screen where it is configured what the switch does with untagged packets arriving inbound on the port. If this isn''t configured, then untagged packets (which will be all packets if the port is configured as untagged) arriving from connected devices will be put into the default VLAN which is (as you say) normally VLAN1). Separate to this, the trunk port may well be configured to leave packets from VLAN1 as untagged even though it is a trunk port that should tag all outbound packets. So several traps for the novice here. I''d suggest going back and re-checking the switch config - looking for these specific points. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
On 11/25/2010 1:54 PM, Stephen Brown wrote:> 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.You should not have both tagged and untagged traffic on the same port Set your eth1 i/f to have no address (ifcfg-eth1 on a CentOS/ES/fedora box) # less /etc/sys*/ne*s/ifcfg-eth1 DEVICE=eth1 BOOTPROTO=none HWADDR=00:19:B9:33:2F:18 ONBOOT=yes HOTPLUG=no TYPE=Ethernet USERCTL=no IPV6INIT=no and your VLANs # less /etc/sys*/ne*s/ifcfg-eth1.2 VLAN=yes DEVICE=eth1.2 BOTPROTO=static TYPE=ethernet ONBOOT=yes IPADDR=10.1.16.1 NETMASK=255.255.255.0 ifconfig should show something like... eth1 Link encap:Ethernet HWaddr 00:19:B9:33:2F:18 inet6 addr: fe80::219:b9ff:fe33:2f18/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:101331737 errors:0 dropped:0 overruns:0 frame:0 TX packets:91661042 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3499614384 (3.2 GiB) TX bytes:2212290220 (2.0 GiB) Interrupt:169 Memory:dfaf0000-dfb00000 eth1.2 Link encap:Ethernet HWaddr 00:19:B9:33:2F:18 inet addr:10.1.16.1 Bcast:10.1.16.255 Mask:255.255.255.0 inet6 addr: fe80::219:b9ff:fe33:2f18/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:23834555 errors:0 dropped:0 overruns:0 frame:0 TX packets:18793985 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4126991039 (3.8 GiB) TX bytes:1402899934 (1.3 GiB) eth1.3 Link encap:Ethernet HWaddr 00:19:B9:33:2F:18 inet addr:10.1.17.2 Bcast:10.1.17.255 Mask:255.255.255.0 inet6 addr: fe80::219:b9ff:fe33:2f18/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18962305 errors:0 dropped:0 overruns:0 frame:0 TX packets:23276939 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1201558859 (1.1 GiB) TX bytes:87667030 (83.6 MiB) Set up port 24 on your netgear switch as a tagged VLAN port carrying VLANs 2 and 3 Set up the other ports as untagged ports carrying whichever VLAN you want to show up on that particular port. I''m not familiar with the Netgear switch so it may differ in the details. The units we use have the IP address and management functions associated with a particular VLAN so be careful you don''t disable access to that. Your martian attack is from eth1 or vlan2 seeing the mixed untagged and tagged traffic. Hope this helps. ------------------------------------------------------------------------------ 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
On Fri, Nov 26, 2010 at 1:35 PM, Alan Madill <amadill@hwy16.com> wrote:> You should not have both tagged and untagged traffic on the same portThat depends on the switch. Some switches will not let you tag with VLAN 1, so the only way to get there is with untagged traffic. They also sometimes won''t let you access the management interface on any VLAN other than 1. This is what I have to do for our Dell switches and I have no problems with martians (using Debian): auto eth0 iface eth0 inet static address 10.99.1.1 netmask 255.255.255.0 auto vlan3 iface vlan3 inet static vlan-raw-device eth0 address 10.99.3.1 netmask 255.255.255.0 ------------------------------------------------------------------------------ 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
On 11/26/2010 2:31 PM, Brad Clarke wrote:> On Fri, Nov 26, 2010 at 1:35 PM, Alan Madill<amadill@hwy16.com> wrote: > >> You should not have both tagged and untagged traffic on the same port > That depends on the switch. Some switches will not let you tag with > VLAN 1, so the only way to get there is with untagged traffic. They > also sometimes won''t let you access the management interface on any > VLAN other than 1. This is what I have to do for our Dell switches and > I have no problems with martians (using Debian): >We are using Allied Telesyn units and carry all of the VLAN''s on our trunks. We have a linux based router that does the layer 3 routing between the layer 2 VLANs which is what I think he is trying to accomplish. When we first set it up many years ago we ran into an issue similar to what Stephen is seeing. To make it more complicated I think he is trying to make use of voice VLANs which seem to be a sort of hybrid. http://cciepursuit.wordpress.com/2009/01/01/group-study-good-explanation-of-the-voice-vlan/ Netgear Manual p3-16 http://documentation.netgear.com/gs700t/enu/202-10484-02/usermanual.pdf > 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 He is seeing VLAN2 traffic on eth1 - correct? If it is voice VLAN I wonder if he is trying to solve a problem that doesn''t exist by putting it on a separate layer 3 subnet. ------------------------------------------------------------------------------ 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
On 11/26/2010 4:50 PM, Alan Madill wrote:> 11/26/2010 2:31 PM, Brad Clarke wrote: >> On Fri, Nov 26, 2010 at 1:35 PM, Alan Madill<amadill@hwy16.com> wrote: >> >>> should not have both tagged and untagged traffic on the same port >> That depends on the switch. Some switches will not let you tag with >> VLAN 1, so the only way to get there is with untagged traffic. They >> also sometimes won''t let you access the management interface on any >> VLAN other than 1. This is what I have to do for our Dell switches and >> I have no problems with martians (using Debian): >> >> To make it more complicated I think he is trying to make use of voice VLANs >> which seem to be a sort of hybrid. >> http://cciepursuit.wordpress.com/2009/01/01/group-study-good-explanation-of-the-voice-vlan/ >>From the link above... The official Cisco stance is that this is not a trunk <http://www.groupstudy.com/archives/ccielab/200812/msg00219.html>: Cisco calls this a Multi-Vlan access port, and NOT a trunk port. if it were a trunk port, according to Cisco, it would flood all vlans configured on the switch out to the phone. As you probably know already, a port configured for voice Vlan does not flood out all Vlans to the phone, just the voice vlan frames (tagged) and the data frames ( untagged ). The data frames are not tagged and would show up on the default VLAN? ------------------------------------------------------------------------------ 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
On 11/26/10 7:50 PM, Alan Madill wrote:> To make it more complicated I think he is trying to make use of voice VLANs > which seem to be a sort of hybrid. > http://cciepursuit.wordpress.com/2009/01/01/group-study-good-explanation-of-the-voice-vlan/No Cisco equipment here, only linux, Netgear, and Polycom :) Not real sure that makes a difference, is this some sort of standard?> This is what I have to do for our Dell switches and > I have no problems with martians (using Debian): > > > auto eth0 > iface eth0 inet static > address 10.99.1.1 > netmask 255.255.255.0 > > auto vlan3 > iface vlan3 inet static > vlan-raw-device eth0 > address 10.99.3.1 > netmask 255.255.255.0 >This is pretty much what I am wanting to accomplish. I run Debian as well (Squeeze on the Shorewall box). Just to be clear, everything works as it should if I only have one interface online in the Asterisk server. My attempt was to dedicate one of my two available Gig ports on the back of this server just for VoIP and attach it to the associated VLAN (vlan2) with port 24 on the switch carrying all of the tagged traffic (this would be considered the trunk correct?) I went bonkers trying to make both network cards work in their respective address spaces (eth0 on 10.5.1.0/24, vlan1. eth1 on 10.5.10.0/24, vlan2). I had some clues from other people that I had two default gateways in this config, and after spending most of the day on it Thursday trying to make that work, I eventually just gave up to get the server back online so I could use my phones. As it stands now eth0 is on 10.5.10.0/24 and it works as it should. I''m still at a loss however as to what the real root of the issue is..... Thanks all for the responses. Stephen ------------------------------------------------------------------------------ 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