[pfSense Support] VLAN trunking?
Hi everyone,I have a pretty basic VLAN question that I haven't been able to find the answer to: Can pfSense do VLAN trunking? More specifically: I'm installing a Metro Ethernet connection with pfSense boxes on each end. I need to tag all traffic sent over the Metro Ethernet connection with a specific VLAN id in order for the ISP's switch to handle the traffic correctly and send it on to the pfSense box on the other end. Can pfSense do this through its VLAN configuration, or would I need a 802.1q switch in between the pfSense and the Metro E connection on each end to specify the VLAN info? Each box has Intel cards (em), running ver 1.0.1.Thanks for any tips,Nate
Re: [pfSense Support] VLAN trunking?
I could be wrong, but don't think I am...You need a switch (802.1Q) in between the pfsense boxen. On 11/8/06, Nathan Osborne <[EMAIL PROTECTED]> wrote: Hi everyone, I have a pretty basic VLAN question that I haven't been able to find the answer to: Can pfSense do VLAN trunking? More specifically: I'm installing a Metro Ethernet connection with pfSense boxes on each end. I need to tag all traffic sent over the Metro Ethernet connection with a specific VLAN id in order for the ISP's switch to handle the traffic correctly and send it on to the pfSense box on the other end. Can pfSense do this through its VLAN configuration, or would I need a 802.1q switch in between the pfSense and the Metro E connection on each end to specify the VLAN info? Each box has Intel cards (em), running ver 1.0.1. Thanks for any tips, Nate -- --- Every revolution begins with the power of an idea and ends when the only idea left is power. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Traffic shaping with or without ALTQ
Hi, As the recent discussion in the forum shows, there is interest in a new traffic shaper. >From the discussion I can see that everybody wants something different from >the traffic shaper. :-) Wishes include: - transparent traffic shaping - QOS - shaping on all interfaces - shaping traffic inside individual IPSEC tunnels - routing traffic based on traffic queue status - port and IP based shaping - easy to use and administrate - everything possible on a large scale OC12 with hundreds of servers To make all this possible, I guess we need some sort of virtual interfaces. If we have an easy way to create a virtual interface, we could combine the traffic we want to shape on an virtual interface and then use a shaper like ALTQ without the need to reprogramm everything. Just create an virtual interface for IPSEC tunnel X, give it a name like (WAN_IPSEC_HQ) and shape on that interface. As for the large scale, it is not practical to add hundreds of rules and shaping entries for each source IP. Virtual Interfaces could also help here. If you can create virtual interfaces based on source IP and apply the same traffic shaping rules to a group of interfaces it would only be a couple of mouse clicks. Pfsense could automatically create an virtual interface when traffic comes in from a new source and X seconds after the last traffic from that source delete the virtual interface again. I guess nobody is suggesting shaping a couple of OC12 lines on a small embedded system with 128 MB of RAM and an slow CPU, but on the other hand for people who only have a 2 Mbit DSL line it should still be possible to run the same code. So please whatever you do, don't increase the minimum requirements too much. Unfortunately I'm not good enough at programming such things, so I wouldn't have a clue on how to do it. :( But I'm willing to put in a bounty for it. Any thougts about this? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Traffic shaping with or without ALTQ
What are you talking about? We are merely raising money for a transparent bridge shaper. Please cut this FUD out. Scott On 11/8/06, Christian Krützfeldt <[EMAIL PROTECTED]> wrote: Hi, As the recent discussion in the forum shows, there is interest in a new traffic shaper. From the discussion I can see that everybody wants something different from the traffic shaper. :-) Wishes include: - transparent traffic shaping - QOS - shaping on all interfaces - shaping traffic inside individual IPSEC tunnels - routing traffic based on traffic queue status - port and IP based shaping - easy to use and administrate - everything possible on a large scale OC12 with hundreds of servers To make all this possible, I guess we need some sort of virtual interfaces. If we have an easy way to create a virtual interface, we could combine the traffic we want to shape on an virtual interface and then use a shaper like ALTQ without the need to reprogramm everything. Just create an virtual interface for IPSEC tunnel X, give it a name like (WAN_IPSEC_HQ) and shape on that interface. As for the large scale, it is not practical to add hundreds of rules and shaping entries for each source IP. Virtual Interfaces could also help here. If you can create virtual interfaces based on source IP and apply the same traffic shaping rules to a group of interfaces it would only be a couple of mouse clicks. Pfsense could automatically create an virtual interface when traffic comes in from a new source and X seconds after the last traffic from that source delete the virtual interface again. I guess nobody is suggesting shaping a couple of OC12 lines on a small embedded system with 128 MB of RAM and an slow CPU, but on the other hand for people who only have a 2 Mbit DSL line it should still be possible to run the same code. So please whatever you do, don't increase the minimum requirements too much. Unfortunately I'm not good enough at programming such things, so I wouldn't have a clue on how to do it. :( But I'm willing to put in a bounty for it. Any thougts about this? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Traffic shaping with or without ALTQ
I haven't yet chimed in too much on this thread. When I do, I'll probably close the thread and start a new one that I can update the first message in with what I'm planning on doing and what's impossible and who has made pledges against the bounty. For the record, the bounty was started for transparent shaping - given that some fundamentals on how we do shaping have to change, some of the other wish list items might creep in (multi-interface shaping), but I need to think about what I think we can and cannot do. I will comment on a couple of the wishlist items that are certainly off the table. This: - shaping traffic inside individual IPSEC tunnels Is an impossible wish list item - doesn't matter how much money anyone comes up with, it requires major kernel land work and I'm reasonably confident I don't have the skill to make the changes that would be required. Maybe the person that brought in enc(4) to FreeBSD could be convinced to make it behave more like a regular interface...that'd go a LONG way towards making this a reality. This: - routing traffic based on traffic queue status Is also unlikely to happen, but at least might be somewhat doable in the future. --Bill On 11/8/06, Christian Krützfeldt <[EMAIL PROTECTED]> wrote: Hi, As the recent discussion in the forum shows, there is interest in a new traffic shaper. From the discussion I can see that everybody wants something different from the traffic shaper. :-) Wishes include: - transparent traffic shaping - QOS - shaping on all interfaces - shaping traffic inside individual IPSEC tunnels - routing traffic based on traffic queue status - port and IP based shaping - easy to use and administrate - everything possible on a large scale OC12 with hundreds of servers To make all this possible, I guess we need some sort of virtual interfaces. If we have an easy way to create a virtual interface, we could combine the traffic we want to shape on an virtual interface and then use a shaper like ALTQ without the need to reprogramm everything. Just create an virtual interface for IPSEC tunnel X, give it a name like (WAN_IPSEC_HQ) and shape on that interface. As for the large scale, it is not practical to add hundreds of rules and shaping entries for each source IP. Virtual Interfaces could also help here. If you can create virtual interfaces based on source IP and apply the same traffic shaping rules to a group of interfaces it would only be a couple of mouse clicks. Pfsense could automatically create an virtual interface when traffic comes in from a new source and X seconds after the last traffic from that source delete the virtual interface again. I guess nobody is suggesting shaping a couple of OC12 lines on a small embedded system with 128 MB of RAM and an slow CPU, but on the other hand for people who only have a 2 Mbit DSL line it should still be possible to run the same code. So please whatever you do, don't increase the minimum requirements too much. Unfortunately I'm not good enough at programming such things, so I wouldn't have a clue on how to do it. :( But I'm willing to put in a bounty for it. Any thougts about this? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
pfSense does do 802.1q trunking so if they device you are connecting does (should be most except some older switches) you shouldn’t have a problem. Thanks John From: Nathan Osborne [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:19 AM To: support@pfsense.com Subject: [pfSense Support] VLAN trunking? Hi everyone, I have a pretty basic VLAN question that I haven't been able to find the answer to: Can pfSense do VLAN trunking? More specifically: I'm installing a Metro Ethernet connection with pfSense boxes on each end. I need to tag all traffic sent over the Metro Ethernet connection with a specific VLAN id in order for the ISP's switch to handle the traffic correctly and send it on to the pfSense box on the other end. Can pfSense do this through its VLAN configuration, or would I need a 802.1q switch in between the pfSense and the Metro E connection on each end to specify the VLAN info? Each box has Intel cards (em), running ver 1.0.1. Thanks for any tips, Nate
Re: [pfSense Support] VLAN trunking?
On 11/8/06, Nathan Osborne <[EMAIL PROTECTED]> wrote: Hi everyone, I have a pretty basic VLAN question that I haven't been able to find the answer to: Can pfSense do VLAN trunking? More specifically: I'm installing a Metro Ethernet connection with pfSense boxes on each end. I need to tag all traffic sent over the Metro Ethernet connection with a specific VLAN id in order for the ISP's switch to handle the traffic correctly and send it on to the pfSense box on the other end. Can pfSense do this through its VLAN configuration, or would I need a 802.1q switch in between the pfSense and the Metro E connection on each end to specify the VLAN info? Each box has Intel cards (em), running ver 1.0.1. Should be possible. The VLAN setup assumes trunk mode. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
Should work - I've been playing with vlans and got it all working. The only weirdness I have left to solve is why my vlan only works if there's a tcpdump -i vlan0 > /dev/null & running on my pfsense box. If thats not running I simply see no data. -Original Message- From: Nathan Osborne [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 3:19 a.m. To: support@pfsense.com Subject: [pfSense Support] VLAN trunking? Hi everyone, I have a pretty basic VLAN question that I haven't been able to find the answer to: Can pfSense do VLAN trunking? More specifically: I'm installing a Metro Ethernet connection with pfSense boxes on each end. I need to tag all traffic sent over the Metro Ethernet connection with a specific VLAN id in order for the ISP's switch to handle the traffic correctly and send it on to the pfSense box on the other end. Can pfSense do this through its VLAN configuration, or would I need a 802.1q switch in between the pfSense and the Metro E connection on each end to specify the VLAN info? Each box has Intel cards (em), running ver 1.0.1. Thanks for any tips, Nate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: Should work - I've been playing with vlans and got it all working. The only weirdness I have left to solve is why my vlan only works if there's a tcpdump -i vlan0 > /dev/null & running on my pfsense box. If thats not running I simply see no data. What kind of NIC(s)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
From: Scott Ullrich [mailto:[EMAIL PROTECTED] >On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: >> Should work - I've been playing with vlans and got it all working. >> >> The only weirdness I have left to solve is why my vlan only works if >> there's a tcpdump -i vlan0 > /dev/null & >> running on my pfsense box. If thats not running I simply see no data. > What kind of NIC(s)? Intel somethingorother... It's a nokia IP330 dmesg says fxp2: port 0x7000-0x701f mem 0xe0301000-0xe0301fff,0xe020-0xe02f irq 5 at device 15.0 on pci0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: From: Scott Ullrich [mailto:[EMAIL PROTECTED] >On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: >> Should work - I've been playing with vlans and got it all working. >> >> The only weirdness I have left to solve is why my vlan only works if >> there's a tcpdump -i vlan0 > /dev/null & >> running on my pfsense box. If thats not running I simply see no data. > What kind of NIC(s)? Intel somethingorother... It's a nokia IP330 Doesn't really make any sense. We already are doing a background TCPDUMP to get the firewall logs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
On 11/8/06, Scott Ullrich <[EMAIL PROTECTED]> wrote: On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: > From: Scott Ullrich [mailto:[EMAIL PROTECTED] > >On 11/8/06, Craig FALCONER <[EMAIL PROTECTED]> wrote: > >> Should work - I've been playing with vlans and got it all working. > >> > >> The only weirdness I have left to solve is why my vlan only works if > >> there's a tcpdump -i vlan0 > /dev/null & > >> running on my pfsense box. If thats not running I simply see no data. > > > What kind of NIC(s)? > > Intel somethingorother... It's a nokia IP330 Doesn't really make any sense. We already are doing a background TCPDUMP to get the firewall logs. On pflog0. This is on the vlan interface which really is bizarre. I could see if for some reason the physical fxp interface wasn't in PROMISC mode needing to do it for that interface, but for the vlan interface I'm stumped. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
Thanks everyone, it worked.For future reference, here's how: I created a new VLAN and assigned it to the Metro Ethernet interface. Then I added the VLAN as a new interface and enabled it, assigning a static IP in a different IP range from the Metro Ethernet interface. I rebooted next for the system to recognize the new VLAN interface. Then I added firewall rules to allow traffic through both the Metro interface and the VLAN interface (not sure yet if both of these are necessary), and finally added a static route to send LAN traffic destined for the remote LAN to the IP of the remote VLAN interface. It's a pretty short distance and it's a fast pipe, so I should be able to get some pretty good benchmarks of the type of traffic it's possible to push over this connection. I'm running it on Poweredge 1850 servers with 2 GB RAM, onboard Intel NICs, and Intel 1000MT dual port server PCI adapters. NateOn 11/8/06, Bill Marquette < [EMAIL PROTECTED]> wrote: On 11/8/06, Nathan Osborne <[EMAIL PROTECTED]> wrote:> Hi everyone,>> I have a pretty basic VLAN question that I haven't been able to find the > answer to: Can pfSense do VLAN trunking? More specifically: I'm > installing a Metro Ethernet connection with pfSense boxes on each end. I> need to tag all traffic sent over the Metro Ethernet connection with a> specific VLAN id in order for the ISP's switch to handle the traffic > correctly and send it on to the pfSense box on the other end. Can pfSense> do this through its VLAN configuration, or would I need a 802.1q switch in> between the pfSense and the Metro E connection on each end to specify the > VLAN info?>> Each box has Intel cards (em), running ver 1.0.1.Should be possible. The VLAN setup assumes trunk mode.--Bill- To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
Title: Message So you have a two-way metrosexual connection? -Original Message-From: Nathan Osborne [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 9:39 a.m.To: support@pfsense.comSubject: Re: [pfSense Support] VLAN trunking?It's a pretty short distance and it's a fast pipe, so I should be able to get some pretty good benchmarks of the type of traffic it's possible to push over this connection. I'm running it on Poweredge 1850 servers with 2 GB RAM, onboard Intel NICs, and Intel 1000MT dual port server PCI adapters.
Re: [pfSense Support] VLAN trunking?
Bill Marquette wrote: Doesn't really make any sense. We already are doing a background TCPDUMP to get the firewall logs. On pflog0. This is on the vlan interface which really is bizarre. I could see if for some reason the physical fxp interface wasn't in PROMISC mode needing to do it for that interface, but for the vlan interface I'm stumped. And he said that's the only way it *works*? Due to the FreeBSD + promisc bug with VLAN's, tcpdumping any vlanX interface or the parent interface should kill all network activity on all VLAN's. Does on every box I've tried, and others have reported the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
Heya - not wishing to argue, but I'm really telling the truth. vlan0 is 192.168.200.1/24 and the workstation is at 192.168.200.2 # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=4.221 ms 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.233 ms ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.233/2.727/4.221/1.494 ms # ps auxw | grep tcpdump root 298 0.0 0.9 3832 2172 d0- SSat07PM 0:51.74 /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 root 48512 0.0 0.2 1468 608 p0 R+2:15PM 0:00.01 grep tcpdump root 67821 0.0 0.9 3852 2244 p0- S 9:12PM 0:17.03 tcpdump -i vlan0 # kill 67821 # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes ^C --- 192.168.200.2 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss # tcpdump -i vlan0 > /dev/null & [1] 48592 # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan0, link-type EN10MB (Ethernet), capture size 96 bytes # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=2.412 ms 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.009 ms ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.009/1.710/2.412/0.701 ms # All I can think of is more Nokia weirdness. This is an IP330 with three on-board NICs. -Original Message- From: Chris Buechler [mailto:[EMAIL PROTECTED] Bill Marquette wrote: >> >> Doesn't really make any sense. We already are doing a background >> TCPDUMP to get the firewall logs. > > On pflog0. This is on the vlan interface which really is bizarre. I > could see if for some reason the physical fxp interface wasn't in > PROMISC mode needing to do it for that interface, but for the vlan > interface I'm stumped. And he said that's the only way it *works*? Due to the FreeBSD + promisc bug with VLAN's, tcpdumping any vlanX interface or the parent interface should kill all network activity on all VLAN's. Does on every box I've tried, and others have reported the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
Craig FALCONER wrote: Heya - not wishing to argue, but I'm really telling the truth. Oh, hey Craig, didn't realize it was you that started this. :) All I can think of is more Nokia weirdness. This is an IP330 with three on-board NICs. The IPxxx boxes certainly do have "special" NIC's. I personally haven't tried VLAN's on fxp cards, but I seem to recall others having the same issue I described with some Intel cards. /me shrugs... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
On Thu, 9 Nov 2006, Craig FALCONER wrote: Heya - not wishing to argue, but I'm really telling the truth. Here's kind of an out of left field idea... Someone mentioned that running tcpdump on a vlan interface actually *breaks* it. By "breaks", I'm betting that means "sends the vlan traffic without vlan tags". If that is indeed the case, perhaps your metro ether provider does not allow tagged ethernet packets. Make sense? Charles vlan0 is 192.168.200.1/24 and the workstation is at 192.168.200.2 # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=4.221 ms 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.233 ms ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.233/2.727/4.221/1.494 ms # ps auxw | grep tcpdump root 298 0.0 0.9 3832 2172 d0- SSat07PM 0:51.74 /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 root 48512 0.0 0.2 1468 608 p0 R+2:15PM 0:00.01 grep tcpdump root 67821 0.0 0.9 3852 2244 p0- S 9:12PM 0:17.03 tcpdump -i vlan0 # kill 67821 # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes ^C --- 192.168.200.2 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss # tcpdump -i vlan0 > /dev/null & [1] 48592 # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan0, link-type EN10MB (Ethernet), capture size 96 bytes # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=2.412 ms 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.009 ms ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.009/1.710/2.412/0.701 ms # All I can think of is more Nokia weirdness. This is an IP330 with three on-board NICs. -Original Message- From: Chris Buechler [mailto:[EMAIL PROTECTED] Bill Marquette wrote: Doesn't really make any sense. We already are doing a background TCPDUMP to get the firewall logs. On pflog0. This is on the vlan interface which really is bizarre. I could see if for some reason the physical fxp interface wasn't in PROMISC mode needing to do it for that interface, but for the vlan interface I'm stumped. And he said that's the only way it *works*? Due to the FreeBSD + promisc bug with VLAN's, tcpdumping any vlanX interface or the parent interface should kill all network activity on all VLAN's. Does on every box I've tried, and others have reported the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] VLAN trunking?
Charles Sprickman wrote: Here's kind of an out of left field idea... Someone mentioned that running tcpdump on a vlan interface actually *breaks* it. By "breaks", I'm betting that means "sends the vlan traffic without vlan tags". I'm not sure exactly what happens to break it, but sending the traffic without tags would make sense. I haven't done enough testing to know what happens to the traffic. Interesting theory, could very well be right on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
Sorry I'm not the metro guy. I have a pfsense box plugged into a non-managed switch, so the vlan MTU had to be dropped to 1496. The pfsense box only sees traffic on the vlan when there's a tcpdump session running. On the other box I had to disable rp_filter before the vlan tagging worked. I haven't found the same thing in freeBSD. This is what rp_filter does in linux. 546 rp_filter - BOOLEAN 547 1 - do source validation by reversed path, as specified in RFC1812 548 Recommended option for single homed hosts and stub network 549 routers. Could cause troubles for complicated (not loop free) 550 networks running a slow unreliable protocol (sort of RIP), 551 or using static routes. 552 553 0 - No source validation. 554 555 conf/all/rp_filter must also be set to TRUE to do source validation 556 on the interface 557 558 Default value is 0. Note that most distributions enable it in startup scripts. I imagine the same concept is hidden somewhere in sysctl but I can't spot it. These are possibilities... net.inet.ip.check_interface: 0 net.inet.ip.sourceroute: 0 net.inet.ip.redirect: 0 Or do I just "ifconfig vlan0 mtu 1496 promisc" ? -Original Message- From: Charles Sprickman [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 2:32 p.m. To: support@pfsense.com Subject: RE: [pfSense Support] VLAN trunking? On Thu, 9 Nov 2006, Craig FALCONER wrote: > Heya - not wishing to argue, but I'm really telling the truth. Here's kind of an out of left field idea... Someone mentioned that running tcpdump on a vlan interface actually *breaks* it. By "breaks", I'm betting that means "sends the vlan traffic without vlan tags". If that is indeed the case, perhaps your metro ether provider does not allow tagged ethernet packets. Make sense? Charles > vlan0 is 192.168.200.1/24 and the workstation is at 192.168.200.2 > > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=4.221 ms 64 bytes > from 192.168.200.2: icmp_seq=1 ttl=64 time=1.233 ms ^C > --- 192.168.200.2 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.233/2.727/4.221/1.494 ms > # ps auxw | grep tcpdump > root 298 0.0 0.9 3832 2172 d0- SSat07PM 0:51.74 > /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 > root 48512 0.0 0.2 1468 608 p0 R+2:15PM 0:00.01 grep tcpdump > root 67821 0.0 0.9 3852 2244 p0- S 9:12PM 0:17.03 tcpdump -i > vlan0 > # kill 67821 > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > ^C > --- 192.168.200.2 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > # tcpdump -i vlan0 > /dev/null & > [1] 48592 > # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vlan0, link-type EN10MB (Ethernet), capture size 96 bytes > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=2.412 ms > 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.009 ms > ^C > --- 192.168.200.2 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.009/1.710/2.412/0.701 ms > # > > > All I can think of is more Nokia weirdness. This is an IP330 with > three on-board NICs. > > > -Original Message- > From: Chris Buechler [mailto:[EMAIL PROTECTED] > > Bill Marquette wrote: >>> >>> Doesn't really make any sense. We already are doing a background >>> TCPDUMP to get the firewall logs. >> >> On pflog0. This is on the vlan interface which really is bizarre. I >> could see if for some reason the physical fxp interface wasn't in >> PROMISC mode needing to do it for that interface, but for the vlan >> interface I'm stumped. > > And he said that's the only way it *works*? Due to the FreeBSD + > promisc bug with VLAN's, tcpdumping any vlanX interface or the parent > interface should kill all network activity on all VLAN's. Does on > every box I've tried, and others have reported the same. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking?
I suspect this is not the answer. I ran tcpdump net 192.168.200.0/24 on a third machine and there's no traffic detected. I'm using a dumb unmanaged switch which makes it more confusing. -Original Message- From: Chris Buechler [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 3:01 p.m. To: support@pfsense.com Subject: Re: [pfSense Support] VLAN trunking? Charles Sprickman wrote: > Here's kind of an out of left field idea... > > Someone mentioned that running tcpdump on a vlan interface actually > *breaks* it. By "breaks", I'm betting that means "sends the vlan > traffic without vlan tags". I'm not sure exactly what happens to break it, but sending the traffic without tags would make sense. I haven't done enough testing to know what happens to the traffic. Interesting theory, could very well be right on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] VLAN trunking? SOLVED
It *IS* promiscuous mode that's making it work. With tcpdump running in the background # ifconfig vlan0 vlan0: flags=8943 mtu 1500 inet 192.168.200.1 netmask 0xff00 broadcast 192.168.200.255 inet6 fe80::2a0:8eff:fef6:6ae8%vlan0 prefixlen 64 scopeid 0x8 ether 00:12:92:33:46:aa media: Ethernet autoselect (100baseTX ) status: active vlan: 4 parent interface: fxp0 # ifconfig fxp0 fxp0: flags=8943 mtu 1500 options=8 inet6 fe80::2004:77a:c5f6:4af5%fxp0 prefixlen 64 scopeid 0x1 inet 10.28.1.1 netmask 0x broadcast 10.28.255.255 ether 02:a5:53:e0:c4:67 media: Ethernet autoselect (100baseTX ) status: active After killing tcpdump # ifconfig vlan0 vlan0: flags=8843 mtu 1500 inet 192.168.200.1 netmask 0xff00 broadcast 192.168.200.255 inet6 fe80::2a0:8eff:fef6:6ae8%vlan0 prefixlen 64 scopeid 0x8 ether 00:12:92:33:46:aa media: Ethernet autoselect (100baseTX ) status: active vlan: 4 parent interface: fxp0 # ifconfig fxp0 fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::2004:77a:c5f6:4af5%fxp0 prefixlen 64 scopeid 0x1 inet 10.28.1.1 netmask 0x broadcast 10.28.255.255 ether 02:a5:53:e0:c4:67 media: Ethernet autoselect (100baseTX ) status: active # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss # ifconfig vlan0 promisc # ping 192.168.200.2 PING 192.168.200.2 (192.168.200.2): 56 data bytes 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=1.360 ms 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.138 ms ^C --- 192.168.200.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.138/1.249/1.360/0.111 ms # So it looks like my VLAN setup required promisc mode on fxp0 (my lan port) and vlan0 What do you think? -Original Message- From: Craig FALCONER [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 3:09 p.m. To: support@pfsense.com Subject: RE: [pfSense Support] VLAN trunking? Sorry I'm not the metro guy. I have a pfsense box plugged into a non-managed switch, so the vlan MTU had to be dropped to 1496. The pfsense box only sees traffic on the vlan when there's a tcpdump session running. On the other box I had to disable rp_filter before the vlan tagging worked. I haven't found the same thing in freeBSD. This is what rp_filter does in linux. 546 rp_filter - BOOLEAN 547 1 - do source validation by reversed path, as specified in RFC1812 548 Recommended option for single homed hosts and stub network 549 routers. Could cause troubles for complicated (not loop free) 550 networks running a slow unreliable protocol (sort of RIP), 551 or using static routes. 552 553 0 - No source validation. 554 555 conf/all/rp_filter must also be set to TRUE to do source validation 556 on the interface 557 558 Default value is 0. Note that most distributions enable it in startup scripts. I imagine the same concept is hidden somewhere in sysctl but I can't spot it. These are possibilities... net.inet.ip.check_interface: 0 net.inet.ip.sourceroute: 0 net.inet.ip.redirect: 0 Or do I just "ifconfig vlan0 mtu 1496 promisc" ? -Original Message- From: Charles Sprickman [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 2:32 p.m. To: support@pfsense.com Subject: RE: [pfSense Support] VLAN trunking? On Thu, 9 Nov 2006, Craig FALCONER wrote: > Heya - not wishing to argue, but I'm really telling the truth. Here's kind of an out of left field idea... Someone mentioned that running tcpdump on a vlan interface actually *breaks* it. By "breaks", I'm betting that means "sends the vlan traffic without vlan tags". If that is indeed the case, perhaps your metro ether provider does not allow tagged ethernet packets. Make sense? Charles > vlan0 is 192.168.200.1/24 and the workstation is at 192.168.200.2 > > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=4.221 ms 64 bytes > from 192.168.200.2: icmp_seq=1 ttl=64 time=1.233 ms ^C > --- 192.168.200.2 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.233/2.727/4.221/1.494 ms > # ps auxw | grep tcpdump > root 298 0.0 0.9 3832 2172 d0- SSat07PM 0:51.74 > /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 > root 48512 0.0 0.2 1468 608 p0 R+2:15PM 0:00.01 grep tcpdump > root 67821 0.0 0.9 3852 2244 p0- S 9:12PM 0:17.03 tcpdump -i > vlan0 > # kill 67821 > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > ^C > --- 192.168.200.2 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > # tcp
