VLANs and bridging
Hello, I'm having a network-problem I cannot solve myself and am hoping you could point me in the right direction. I'm currently hosting a lot of computers, all in the same subnet. Since there are administrative servers, hosting-servers, ans so on, I want to limit access from one logical group to the other. However, the computers are at physically totally scattered locations, some in the same rack, some not. It's impossible for me to divide the network into subnets, keep that in mind. My idea was to install several VLANs, each of them holding a group of computers, and connecting them via a filtering bridge. So my setup looks like this: ++ ++ ++ | Switch |---| Switch |---| Switch | ++ ++ ++ | | | | | | | | | | | | Conputers |Computers | FreeBSD Machine | \-- Internet The obvious drawback is that all the traffic between the VLANs would have to pass through this bridge, but most of the traffic will pass to the internet and back, the traffic between the VLANs is not that much but nevertheless important. For testing, I used a FXP-card and did NOT connect the box to the internet, just to the switch. The switch was configured to give tagged packets to the BSD-machine and non-tagged to all other ports. I compiled the BRIDGE into the kernel and set up to VLANs to test: ifconfig fxp0 up ifconfig vlan1 create ifconfig vlan2 create ifconfig vlan1 vlan 1 vlandev fxp0 ifconfig vlan2 vlan 2 vlandev fxp0 The next step was to setup a bridge between vlan1 and vlan2: sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=vlan1,vlan2 And then: nothing happens. It simply doesn't work. Using tcpdump shows me that there are ARP-packets trying to be sent and the bridge seems to be forwarding those, but I never get an answer-packet. There was no packet-filter active at this moment, so I assume there is a problem with bridging VLANs (since bridging fxp0 to rl0 works flawlessly). My question now is: I've read in some mails that bridging between tagged VLANs is currently not working really well. So what am I to do? Is there a better solution (besides subnets and using a gateway)? Is there a way to make it work? I also read about netgraph bridging but as I understand, there's no way to make it filter packets. Any suggestions or hints? - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLANs and bridging
Mark Daniel Reidel wrote: ifconfig fxp0 up Just if someone is interested: The problem was this line. After changing it to: ifconfig fxp0 link0 up everything worked fine. Thanks, Kevin, for pointing this out :o) - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLANs and bridging
> And then: nothing happens. It simply doesn't work. Using tcpdump shows > me that there are ARP-packets trying to be sent and the bridge seems to > be forwarding those, but I never get an answer-packet. There was no > packet-filter active at this moment, so I assume there is a problem with > bridging VLANs (since bridging fxp0 to rl0 works flawlessly). Some switches, like HP ProCurve, do not allow having the same MAC address on multiple VLANs. It's maybe your case. Regards, -- Jeremie LE HEN aka TtZ/TataZ [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New sys-altw patchset for FreeBSD 4.9-[PRE]RELEASE
Hi, I have rebuilt the sys-altq patches against the sources of FreeBSD 4.9-RC as of 9th October. As the RELENG_4 branch has entered the 4.9 pre-release stage, I assume that no critical changes will occur until official release time which would broke this patchset. You can download the patchsed from the FreeBSD/ALTQ's project page: http://www.rofug.ro/projects/freebsd-altq/ Or directly from here: http://www.rofug.ro/projects/freebsd-altq/sys-altq-freebsd-4.9-RELEASE.patch.gz Side-notes: * No major modifications, just driver updates * dev/em/if_em.c, dev/ie/if_ie.c fixups * pci/if_dc.c fixup which needs review * This patchsed has been used in production for about one week using the rl(4) newtork interface with no problems -- Adrian Penisoara Ady (@freebsd.ady.ro) www.rofug.ro ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLANs and bridging
On Thu, Oct 16, 2003 at 01:10:56PM +0200, Mark Daniel Reidel wrote: > Mark Daniel Reidel wrote: > > >ifconfig fxp0 up > > Just if someone is interested: The problem was this line. After changing > it to: > > ifconfig fxp0 link0 up > > everything worked fine. Bizarre. Why would uploading the interrupt coalescing microcode fix that problem? Hrrrm... Perhaps jmg or jlemon can shed light on this... BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
hi all, this is about the thread regarding the use of a freebsd bridge and tap(4) to change the contents of the frames. the solution proposed in the list was to use: net.link.ether.bridge_cfg=fxp0:0,tap0:0,tap1:1,fxp1:1 then you'd write and application to bridge between clusters 0 and 1. i have a couple of questions, hopefully you can help me: 1) wont the userland bridge kill your application because of all the context-switches and copies? 2) are you using any library to rebuild your frames (crc, etc)? i'm thinking about libnet. i'd be very glad if you could help me with these doubts. thanks, fernando. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Query.
Hi, Thanks for reading. I'm running FreeBSD 4.x. Basically, the problem i'm having - is that when I boot my Laptop - with the Netgear HA501 wireless card, all traffic on my FreeBSD box - which acts as the Gateway "stops". If I'm on IRC I ping timeout, browsing the net becomes impossible, etc. The setup of my LAN, is that my business cable modem (which uses DHCP) connects to sis0 ethernet, the Access point (netgear HE102) connects via crossover to sis1 ethernet, and then the HA501 works wirelessley to the HE102 AP. I set in config that it wouldnt use DHCP for the laptop, as hte laptop just uses the freebsd box as a gateway. My "ifconfig" output is: sis0: flags=8843 mtu 1500 inet6 fe80::209:5bff:fe22:47d4%sis0 prefixlen 64 scopeid 0x1 inet my.public.IP netmask 0xff00 broadcast 255.255.255.255 ether 00:09:5b:22:47:d4 media: Ethernet autoselect (100baseTX ) status: active sis1: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::240:f4ff:fe3b:ba91%sis1 prefixlen 64 scopeid 0x2 ether 00:40:f4:3b:ba:91 media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 I have in /etc/rc.conf the following (as I'm using NAT): ifconfig_sis0="DHCP" kern_securelevel_enable="NO" moused_enable="YES" nfs_reserved_port_only="YES" sshd_enable="NO" usbd_enable="YES" gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="sis0" natd_flags="" firewall_script="/etc/firewall/fwrules" SENDMAIL_ENABLE="NONE" ifconfig_sis1="inet 192.168.0.1 netmask 255.255.255.0" To make sure NAT was running, before, the "ps" output is: $ ps -auxw | grep natd root 77 0.0 0.7 1976 1716 ?? Ss3:02PM 50:24.68 /sbin/natd -n sis0 To setup my FreeBSD box as a gateway, i did these steps: I loaded IPFIREWALL and IPIDIVERT modules, to the Kernel, and recompiled it. I added the stuff I pasted to rc.conf and on the laptop (running WinXP) I put the following as the Network options: IP address: 192.168.0.2 Subnet mask: 255.255.255.0 Default gateway: 192.168.0.1 and my ISP's nameservers. Some logging: Before turning laptop on: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default213.105.213.254UGSc 23 3088576 sis0 127.0.0.1 127.0.0.1 UH 7 6799lo0 192.168.0 link#2 UC 00 sis1 213.105.213link#1 UC 10 sis0 213.105.213.213127.0.0.1 UGHS00lo0 213.105.213.25400:05:74:f7:58:70 UHLW 230 sis0 1200 After turning laptop on, before requesting a website etc (when the problems begin to occur) Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default213.105.213.254UGSc 25 3089500 sis0 127.0.0.1 127.0.0.1 UH 7 6826lo0 192.168.0 link#2 UC 10 sis1 192.168.0.200:09:5b:30:71:0a UHLW05 sis1 1193 213.105.213link#1 UC 10 sis0 213.105.213.213127.0.0.1 UGHS00lo0 213.105.213.25400:05:74:f7:58:70 UHLW 230 sis0 1199 Problem time: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default213.105.213.254UGSc 24 3095736 sis0 127.0.0.1 127.0.0.1 UH 7 6832lo0 192.168.0 link#2 UC 10 sis1 192.168.0.200:09:5b:30:71:0a UHLW06 sis1 1161 213.105.213link#1 UC 10 sis0 213.105.213.213127.0.0.1 UGHS00lo0 213.105.213.25400:05:74:f7:58:70 UHLW 220 sis0 1199 Finally, my FWRULES: #!/bin/sh # Copyright (c) 1996 Poul-Henning Kamp # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright #notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions and the following disclaimer in the #documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
Re: Question about bridging code
this is a really complicatged way of doing this.. why not just use divert sockets, like natd? or, altenatively, if you must do it at link layer, use netgraph to directly deliver the packets to your daemon.. as to packet delay, if the daemon has a high priority then, no, it shouldn't slow it down much.. (natd does this and doesn't make a huge difference..) it may even be easier to write a netgraph in-kernel kernel module to do the munging.. see one of the many sample netgraph modules... On Thu, 16 Oct 2003, Fernando A. Paulo wrote: > > hi all, > > this is about the thread regarding the use of a > freebsd bridge and tap(4) to change the contents > of the frames. > > the solution proposed in the list was to use: > > net.link.ether.bridge_cfg=fxp0:0,tap0:0,tap1:1,fxp1:1 > > then you'd write and application to bridge between > clusters 0 and 1. > > i have a couple of questions, hopefully you can help > me: > > 1) wont the userland bridge kill your application > because of all the context-switches and copies? > > 2) are you using any library to rebuild your frames > (crc, etc)? i'm thinking about libnet. > > i'd be very glad if you could help me with these > doubts. > > thanks, > fernando. > > > > > > __ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
On Thu, 16 Oct 2003, Fernando A. Paulo wrote: > this is about the thread regarding the use of a freebsd bridge and > tap(4) to change the contents of the frames. > > the solution proposed in the list was to use: > > net.link.ether.bridge_cfg=fxp0:0,tap0:0,tap1:1,fxp1:1 > > then you'd write and application to bridge between clusters 0 and 1. > > i have a couple of questions, hopefully you can help me: > > 1) wont the userland bridge kill your application because of all the > context-switches and copies? > > 2) are you using any library to rebuild your frames (crc, etc)? i'm > thinking about libnet. > > i'd be very glad if you could help me with these doubts. I've done something very like this before for some research I did a few years ago. We built a user process ethernet bridge using BPF -- the process opened a BPF descriptor per interface that needed to be bridged, and then read/write frames using them, rewriting as needed. We implemented both link layer and IP-layer filtering. Because you have to copy every packet in and out of the kernel, it is fairly expensive -- however, if you just have a single process running on the system most of the time, there isn't a lot of context switching going on. The same is true of natd: natd hurts a lot worse from being in userspace if you simultaneously run tcpdump or trafshow on the host, since you force frequent context switches. My conclusion from my BPF bridge experience was that prototyping in userspace made it a lot easier to experiment with changes, and dramatically reduced the development time. On the other hand, it did terrible things to performance on high bandwidth tests, and because we weren't using mbufs in userspace, made it harder to port to the kernel. One nice benefit, though, was that we had TCP/IP people programming TCP/IP stuff without having to teach them about mbuf semantics or kernel debugging :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Connecting to Cisco VPN concentrator
Here's an interesting problem that I'm not sure how to solve. A user, whose machine runs Windows, connects to his ISP via PPTP (he can also use PPPoE, but there's no change in what happens). Once on the Internet, he wants to use the Cisco VPN client software to tunnel into a LAN at the office. Trouble is, as soon as the Cisco VPN client fires up on his Windows machine, it blocks the PPTP or PPPoE connection. In short, it strangles itself by cutting off the link over which it must connect. With the machine no longer able to reach the Internet, the VPN connection can't work, and everything falls apart. Cisco's literature hints that the Cisco VPN client contains a built-in firewall which downloads rules from the Cisco VPN router (which Cisco calls a "concentrator") as it connects. But I've explored the configuration of the concentrator, and the rules appear to allow pretty much everything through, including GRE and PPTP. I've also tried to see if the user can connect to the VPN concentrator using the built-in VPN software in Windows rather than the special Cisco VPN client software. So far, the answer is "Yes, but not in a way that's useful." I can only connect to the VPN concentrator via PPTP when encryption is turned off, thus defeating the purpose of having a VPN in the first place. When I tell the Windows system to require encryption, the connection fails. Does anyone have experience with connecting to Cisco VPN concentrators -- using either Cisco's VPN client software for Windows or a the PPTP or L2TP client software built into Windows? --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
On Thu, Oct 16, 2003 at 05:18:24PM -0400, Robert Watson wrote: > > My conclusion from my BPF bridge experience was that prototyping in > userspace made it a lot easier to experiment with changes, and > dramatically reduced the development time. On the other hand, it did > terrible things to performance on high bandwidth tests, and because we > weren't using mbufs in userspace, made it harder to port to the kernel. > One nice benefit, though, was that we had TCP/IP people programming TCP/IP > stuff without having to teach them about mbuf semantics or kernel > debugging :-). It's actually not so hard to get kernel mbuf-oriented code running in userspace. I did a userspace PPP implementation in 1994, and when it came time to do VJ compression I took the BSD kernel VJ code (from lbl.gov, if I recall correctly), defined some of the mbuf fields in my own structs, and it compiled and worked correctly without changing a single line of the VJ code. That project would never have survived if every bug had caused a kernel panic. The code is still running in commercial service today. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
On Thu, 16 Oct 2003, Barney Wolff wrote: > On Thu, Oct 16, 2003 at 05:18:24PM -0400, Robert Watson wrote: > > > > My conclusion from my BPF bridge experience was that prototyping in > > userspace made it a lot easier to experiment with changes, and > > dramatically reduced the development time. On the other hand, it did > > terrible things to performance on high bandwidth tests, and because we > > weren't using mbufs in userspace, made it harder to port to the kernel. > > One nice benefit, though, was that we had TCP/IP people programming TCP/IP > > stuff without having to teach them about mbuf semantics or kernel > > debugging :-). > > It's actually not so hard to get kernel mbuf-oriented code running in > userspace. I did a userspace PPP implementation in 1994, and when it > came time to do VJ compression I took the BSD kernel VJ code (from > lbl.gov, if I recall correctly), defined some of the mbuf fields in my > own structs, and it compiled and worked correctly without changing a > single line of the VJ code. > > That project would never have survived if every bug had caused a kernel > panic. The code is still running in commercial service today. There are also at least a couple of implementations of a full BSD network stack in userspace (Alpine being one, I believe), as well as the Linux network stack. A number of pretty large product companies also ship network appliances and related products based on userspace network stacks optimized for what they're doing, using the OS basically as a device driver and development framework. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Connecting to Cisco VPN concentrator
That's rude, Bill. It is, indeed, relevant. The PPTP/PPPoE server through which the client is connecting is running FreeBSD. --Brett Glass At 05:16 PM 10/16/2003, Bill Fumerola wrote: >[ moved off of -net ] > >On Thu, Oct 16, 2003 at 04:13:19PM -0600, Brett Glass wrote: >> [...] > >i ran your mail through the FreeBSD Relevance Algorithm[1] and these >were my results: > >---Attachment: text/plain-- (all) >Pipe to: grep -v freebsd-net | grep -ci freebsd >0 >Press any key to continue... > >perhaps you were looking for a cisco, windows, or ipsec forum. in the >mean time, i've moved this thread to the general discussion list. > >-- >- bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] > >1. patent pending ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Connecting to Cisco VPN concentrator
On Thu, 16 Oct 2003, Brett Glass wrote: > That's rude, Bill. > > It is, indeed, relevant. The PPTP/PPPoE server through > which the client is connecting is running FreeBSD. A fact that you completely failed to mention.. > > --Brett Glass > > At 05:16 PM 10/16/2003, Bill Fumerola wrote: > > >[ moved off of -net ] > > > >On Thu, Oct 16, 2003 at 04:13:19PM -0600, Brett Glass wrote: > >> [...] > > > >i ran your mail through the FreeBSD Relevance Algorithm[1] and these > >were my results: > > > >---Attachment: text/plain-- (all) > >Pipe to: grep -v freebsd-net | grep -ci freebsd > >0 > >Press any key to continue... > > > >perhaps you were looking for a cisco, windows, or ipsec forum. in the > >mean time, i've moved this thread to the general discussion list. > > > >-- > >- bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] > > > >1. patent pending > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Connecting to Cisco VPN concentrator
In any event, if I can't get the client to connect, guess which piece of equipment goes bye-bye? (Hint: It won't be the Cisco.) --Brett At 08:21 PM 10/16/2003, Julian Elischer wrote: >On Thu, 16 Oct 2003, Brett Glass wrote: > >> That's rude, Bill. >> >> It is, indeed, relevant. The PPTP/PPPoE server through >> which the client is connecting is running FreeBSD. > >A fact that you completely failed to mention.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Connecting to Cisco VPN concentrator
Hi, On Thu, 16 Oct 2003, Brett Glass wrote: > Trouble is, as soon as the Cisco VPN client fires up on his Windows > machine, it blocks the PPTP or PPPoE connection. In short, it strangles > itself by cutting off the link over which it must connect. With the > machine no longer able to reach the Internet, the VPN connection can't > work, and everything falls apart. > maybe the Cisco client is disabling IP-Forwarding on the Windows machine, I've seen this with a similar client software from Checkpoint (it refuses the installation if IP-Fowarding is enabled). One of my customers is using such client software from cisco, but there were no problems, I just had to open UDP port 500 (isakmp), but this customer has a leased line with a router and no PPTP/PPPoE connection must be established when connecting to the internet. sorry, bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
